Eric Ren 079d37df33 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 49d200deaa ("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>		2016-08-26 13:22:14 -05:00
..
ast.c
ast.h
config.c	dlm: add log_info config option	2016-06-21 09:04:24 -05:00
config.h	dlm: add log_info config option	2016-06-21 09:04:24 -05:00
debug_fs.c	dlm: fix malfunction of dlm_tool caused by debugfs changes	2016-08-26 13:22:14 -05:00
dir.c
dir.h
dlm_internal.h	dlm: add log_info config option	2016-06-21 09:04:24 -05:00
Kconfig
lock.c
lock.h
lockspace.c
lockspace.h
lowcomms.c	dlm: Use kmemdup instead of kmalloc and memcpy	2016-06-23 11:55:58 -05:00
lowcomms.h
lvb_table.h
main.c
Makefile
member.c
member.h
memory.c
memory.h
midcomms.c
midcomms.h
netlink.c
plock.c
rcom.c
rcom.h
recover.c
recover.h
recoverd.c
recoverd.h
requestqueue.c
requestqueue.h
user.c
user.h
util.c
util.h