Re: [PATCHES][RFC][CFT] debugfs cleanups

[Al Viro <viro@zeniv.linux.org.uk>]

On Sun, Dec 29, 2024 at 08:09:48AM +0000, Al Viro wrote:

> 	All of that could be avoided if we augmented debugfs inodes with
> a couple of pointers - no more stashing crap in ->d_fsdata, etc.
> And it's really not hard to do.  The series below attempts to untangle
> that mess; it can be found in
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.debugfs
> 
> 	It's very lightly tested; review and more testing would be
> very welcome.

BTW, looking through debugfs-related stuff...

arch/x86/kernel/cpu/resctrl/pseudo_lock.c:pseudo_lock_measure_trigger()
	debugfs_file_get()/debugfs_file_put() pair inside, even though the
	only use of that sucker is ->write() of file_operations fed
	to debugfs_create_file().  In other words, it's going to be
	called only by full_proxy_write(), which already has such a pair
	around that...
drivers/base/regmap/regmap-debugfs.c:regmap_cache_{only,bypass}_write_file()
	ditto
drivers/gpu/drm/xlnx/zynqmp_dp.c:zynqmp_dp_{pattern,custom}_write()
	ditto
drivers/gpu/drm/xlnx/zynqmp_dp.c:zynqmp_dp_{pattern,custom}_read()
	similar, except that it's ->read() rather than ->write()
drivers/infiniband/hw/hfi1/debugfs.c:hfi1_seq_read()
	ditto, AFAICS.  Verifying that is not pleasant (use of ## in
	that forest of macros is seriously grep-hostile), but...
drivers/infiniband/hw/hfi1/debugfs.c:hfi1_seq_lseek()
	same story for ->llseek()
drivers/infiniband/hw/hfi1/fault.c:fault_opcodes_{read,write}()
	same story
drivers/thermal/testing/command.c:tt_command_write()
	same, but debugfs_file_put() is apparently lost.
	Attempt to rmmod that sucker ought to deadlock if there had
	been a call of that...
sound/soc/sof/ipc4-mtrace.c:sof_ipc4_mtrace_dfs_open()
	->open() calling debugfs_file_get(), with matching debugfs_file_put()
	only in ->release().  Again, that's debugfs_create_file() fodder -
	with nothing to trigger removal in sight.  Fortunately, since had
	that been triggerable from userland, you could get a nice deadlock
	by opening that file and triggering removal...
sound/soc/sof/sof-client-ipc-flood-test.c:sof_ipc_flood_dfs_open()
	same, except that here removal *is* triggerable.  Do rmmod with
	e.g. stdin redirected from that file and you are screwed.
sound/soc/sof/sof-client-ipc-kernel-injector.c:sof_msg_inject_dfs_open()
	same, complete with deadlock on rmmod...
sound/soc/sof/sof-client-ipc-msg-injector.c:sof_msg_inject_dfs_open()
	... and here as well.


As far as I can see, there's not a single legitimate caller of
debugfs_file_{get,put}() outside of fs/debugfs/file.c.  Is there any
reason to keep that stuff non-static, let alone exported?