diff options
| author | Eric Ren <zren@suse.com> | 2016-08-25 11:20:59 +0200 |
|---|---|---|
| committer | David Teigland <teigland@redhat.com> | 2016-08-26 20:22:14 +0200 |
| commit | 079d37df3397d48aab0f014986c1b0a1ca6256aa (patch) | |
| tree | ee64358c7af2b4a5ffab8206ad41760ca5e829dc /fs/btrfs/tree-log.c | |
| parent | Linux 4.8-rc3 (diff) | |
| download | linux-079d37df3397d48aab0f014986c1b0a1ca6256aa.tar.xz linux-079d37df3397d48aab0f014986c1b0a1ca6256aa.zip | |
dlm: fix malfunction of dlm_tool caused by debugfs changes
With the current kernel, `dlm_tool lockdebug` fails as below:
"dlm_tool lockdebug ED0BD86DCE724393918A1AE8FDBF1EE3
can't open /sys/kernel/debug/dlm/ED0BD86DCE724393918A1AE8FDBF1EE3:
Operation not permitted"
This is because table_open() depends on file->f_op to tell which
seq_file ops should be passed down. But, the original file ops in
file->f_op is replaced by "debugfs_full_proxy_file_operations" with
commit 49d200deaa68 ("debugfs: prevent access to removed files'
private data").
Currently, I can think up 2 solutions: 1st, replace
debugfs_create_file() with debugfs_create_file_unsafe();
2nd, make different table_open#() accordingly. The 1st one
is neat, but I don't thoroughly understand its risk. Maybe
someone has a better one.
Signed-off-by: Eric Ren <zren@suse.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Diffstat (limited to 'fs/btrfs/tree-log.c')
0 files changed, 0 insertions, 0 deletions