Re: [RFC][PATCH] fanotify: disallow mount/sb marks on kernel internal pseudo fs

[Jan Kara <jack@suse.cz>]

On Thu 29-06-23 15:51:58, Amir Goldstein wrote:
> On Thu, Jun 29, 2023 at 3:20 PM Amir Goldstein <amir73il@gmail.com> wrote:
> > > > The tricky point in banning anonymous pipes from inotify, which
> > > > could have existing users (?), but maybe not, so maybe this is
> > > > something that we need to try out.
> > > >
> > > > I think we can easily get away with banning anonymous pipes from
> > > > fanotify altogeter, but I would not like to get to into a situation
> > > > where new applications will be written to rely on inotify for
> > > > functionaly that fanotify is never going to have.
> > >
> > > Yeah, so didn't we try to already disable inotify on some virtual inodes
> > > and didn't it break something? I have a vague feeling we've already tried
> > > that in the past and it didn't quite fly but searching the history didn't
> > > reveal anything so maybe I'm mistaking it with something else.
> > >
> >
> > I do have the same memory now that you mention it.
> > I will try to track it down.
> >
> 
> Here it is:
> https://lore.kernel.org/linux-fsdevel/20200629130915.GF26507@quack2.suse.cz/
> 
> A regression report on Mel's patch:
> e9c15badbb7b ("fs: Do not check if there is a fsnotify watcher on
> pseudo inodes")
> 
> Chromium needs IN_OPEN/IN_CLOSE on anon pipes.
> It does not need IN_ACCESS/IN_MODIFY, but the value of eliminating
> those was deemed as marginal after the alternative optimizations by Mel:
> 
> 71d734103edf ("fsnotify: Rearrange fast path to minimise overhead when
> there is no watcher")

Ah, yes. Thanks for the history digging! My grep-foo over the changelogs
was not good enough to find it :)

> The reason I would like to ban the "global" watch on all anon inodes
> is because it is just wrong and an oversight of sb/mount marks that
> needs to be fixed.
> 
> The SB_NOUSER optimization is something that we can consider later.
> It's not critical, but just a very low hanging fruit to pick.
> 
> Based on this finding, I would go with this RFC patch as is.
> I will let you decide how to CC stable and about the timing
> of sending this to Linus.

Yes, let's go with the patch as is. Currently I have pull request pending
with Linus so I won't merge the patch yet but I plan on merging it early
next week and then sending it to Linus towards the end of the next week.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR