On Mon, Jan 15, 2018 at 02:50:12PM -0500, David Miller wrote:
> From: Alexey Dobriyan <adobri...@gmail.com>
> Date: Sat, 13 Jan 2018 20:11:52 +0300
>
> > /proc has been ignoring struct file_operations::owner field for ages.
> >
> > Signed-off-by: Alexey Dobriyan <adobri...@gmail.com>
>
> What, then, makes sure that the procfs files are unregistered before the
> referencing module is unloaded?
Procfs interposes a bunch of wrappers for file_operations methods.
Attempt to remove proc_dir_entry marks it as going down and waits for
use count to reach 0. Wrappers check if it's marked and bump the
use count for the duration of actual method call otherwise. IOW,
removal prevents any subsequent method calls and waits for all
calls currently in progress to finish...
> Please explain the situation, and add a reference to the commit that
> made procfs stop using the fops owner field. That commit and it's
> commit message may help explain why all of this is fine.
Umm... It got started in
commit 786d7e1612f0b0adb6046f19b906609e4fe8b1ba
Author: Alexey Dobriyan <adobri...@sw.ru>
Date: Sun Jul 15 23:39:00 2007 -0700
Fix rmmod/read/write races in /proc entries
Bugger if I remember how long did it take for the dust to settle - there
had been bugs in the original, and it took some time to fix. I think
the last straggler had been
commit 7e0e953bb0cf649f93277ac8fb67ecbb7f7b04a9
Author: Al Viro <v...@zeniv.linux.org.uk>
Date: Sat Feb 21 22:16:11 2015 -0500
procfs: fix race between symlink removals and traversals
and it had been a while between that and the previous one. Of course,
we still might have bugs there, but that's not different from anywhere
else in the kernel...
Procfs file_operations had not been supposed to need ->owner for at least
a decade...
