Re: fsnotify path hooks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Apr 09, 2021 at 04:39:01PM +0200, Christian Brauner wrote:
> On Fri, Apr 09, 2021 at 02:30:13PM +0000, Al Viro wrote:
> > On Fri, Apr 09, 2021 at 04:22:58PM +0300, Amir Goldstein wrote:
> > 
> > > But we are actually going in cycles around the solution that we all want,
> > > but fear of rejection. It's time to try and solicit direct feedback from Al.
> > > 
> > > Al,
> > > 
> > > would you be ok with passing mnt arg to vfs_create() and friends,
> > > so that we can pass that to fsnotify_create() (and friends) in order to
> > > be able to report FAN_CREATE events to FAN_MARK_MOUNT listeners?
> > 
> > I would very much prefer to avoid going that way.
> 
> Fwif and if I understand this correctly then this would mostly matter
> for stacking filesystems or filesystems that already have access to the
> relevant struct vfsmount they need to talk about anyway. It's not about
> passing struct vfsmount into inode methods themselves which would be a
> bad idea.  Meaning Amir's change would not require or cause vfsmounts
> to be made accessible where they arent't already.

AFAICS, you are getting caught on mount marks semantics (or lack thereof).
It's _not_ "event happened to something visible here"; it's "event had
been requested by way that explicitly refers to that mount".

And that, IMO, pushes that crap from the places where the work is done
to the places where it had been requested.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux