On Thu 29-06-23 15:51:58, Amir Goldstein wrote: > On Thu, Jun 29, 2023 at 3:20 PM Amir Goldstein <amir73il@xxxxxxxxx> 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@xxxxxxxxxxxxxx/ > > 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@xxxxxxxx> SUSE Labs, CR
