Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue, Mar 21, 2017 at 05:41:22PM +0100, Jan Kara wrote: > On Tue 21-03-17 11:38:49, J. Bruce Fields wrote: > > On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > > > On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > > > > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue, Mar 21, 2017 at 05:41:22PM +0100, Jan Kara wrote: > On Tue 21-03-17 11:38:49, J. Bruce Fields wrote: > > On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > > > On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > > > > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský > > > >

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue 21-03-17 11:38:49, J. Bruce Fields wrote: > On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > > On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > > > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský > > > wrote: > > > > Besause fanotify requires `struct

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue 21-03-17 11:38:49, J. Bruce Fields wrote: > On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > > On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > > > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský > > > wrote: > > > > Besause fanotify requires `struct path`, the event cannot

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský wrote: > > > Besause fanotify requires `struct path`, the event cannot be generated > > > directly in

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský wrote: > > > Besause fanotify requires `struct path`, the event cannot be generated > > > directly in `fsnotify_move` and friends

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

Hi, On Sun, Mar 19, 2017 at 07:04:13PM +0100, Jan Kara wrote: > How come? In current kernel the call looks like: > > vfs_mknod(d_inode(path.dentry), dentry, mode, dev->devt); > > so the path is available there... I've actually quickly checked all > vfs_mknod() callers and they all seem to have

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

Hi, On Sun, Mar 19, 2017 at 07:04:13PM +0100, Jan Kara wrote: > How come? In current kernel the call looks like: > > vfs_mknod(d_inode(path.dentry), dentry, mode, dev->devt); > > so the path is available there... I've actually quickly checked all > vfs_mknod() callers and they all seem to have

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun, Mar 19, 2017 at 2:04 PM, Jan Kara wrote: > On Sun 19-03-17 11:37:39, Filip Štědronský wrote: >> On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: >> > However if you can really call fsnotify hooks with 'path' available in all >> > the places, it should be equally

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun, Mar 19, 2017 at 2:04 PM, Jan Kara wrote: > On Sun 19-03-17 11:37:39, Filip Štědronský wrote: >> On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: >> > However if you can really call fsnotify hooks with 'path' available in all >> > the places, it should be equally hard to just pass

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun 19-03-17 11:37:39, Filip Štědronský wrote: > On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > > However if you can really call fsnotify hooks with 'path' available in all > > the places, it should be equally hard to just pass 'path' to > > vfs_(create|mkdir|...) and that way we

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun 19-03-17 11:37:39, Filip Štědronský wrote: > On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > > However if you can really call fsnotify hooks with 'path' available in all > > the places, it should be equally hard to just pass 'path' to > > vfs_(create|mkdir|...) and that way we

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > However if you can really call fsnotify hooks with 'path' available in all > the places, it should be equally hard to just pass 'path' to > vfs_(create|mkdir|...) and that way we don't have to sprinkle fsnotify > calls into several call

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Sun, Mar 19, 2017 at 11:19:43AM +0100, Jan Kara wrote: > However if you can really call fsnotify hooks with 'path' available in all > the places, it should be equally hard to just pass 'path' to > vfs_(create|mkdir|...) and that way we don't have to sprinkle fsnotify > calls into several call

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský wrote: > > Besause fanotify requires `struct path`, the event cannot be generated > > directly in `fsnotify_move` and friends because they only get the inode > > (and their

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue 14-03-17 13:18:01, Amir Goldstein wrote: > On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský wrote: > > Besause fanotify requires `struct path`, the event cannot be generated > > directly in `fsnotify_move` and friends because they only get the inode > > (and their callers, `vfs_rename`

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Wed, Mar 15, 2017 at 3:39 PM, Jan Kara wrote: > On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote: >> Filip Štědronský : >> >> > there are basically two classes of uses for a fantotify-like >> > interface: >> > >> > (1) Keeping an up-to-date representation of the

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Wed, Mar 15, 2017 at 3:39 PM, Jan Kara wrote: > On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote: >> Filip Štědronský : >> >> > there are basically two classes of uses for a fantotify-like >> > interface: >> > >> > (1) Keeping an up-to-date representation of the file system. For this, >> >

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

Jan Kara : > On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote: >> As for "who (user/process/...) did what", the fanotify API is flawed >> in that we don't have a CLOSE_WRITE_PERM event. The hit-and-run >> process is long gone by the time we receive the event. That's more of >> a rule

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

Jan Kara : > On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote: >> As for "who (user/process/...) did what", the fanotify API is flawed >> in that we don't have a CLOSE_WRITE_PERM event. The hit-and-run >> process is long gone by the time we receive the event. That's more of >> a rule than an

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote: > Filip Štědronský : > > > there are basically two classes of uses for a fantotify-like > > interface: > > > > (1) Keeping an up-to-date representation of the file system. For this, > > superblock watches are clearly what you

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Wed 15-03-17 10:19:52, Marko Rauhamaa wrote: > Filip Štědronský : > > > there are basically two classes of uses for a fantotify-like > > interface: > > > > (1) Keeping an up-to-date representation of the file system. For this, > > superblock watches are clearly what you want. > > > >

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

Filip Štědronský : > there are basically two classes of uses for a fantotify-like > interface: > > (1) Keeping an up-to-date representation of the file system. For this, > superblock watches are clearly what you want. > > [...] > > All those factors speak greatly in

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

Filip Štědronský : > there are basically two classes of uses for a fantotify-like > interface: > > (1) Keeping an up-to-date representation of the file system. For this, > superblock watches are clearly what you want. > > [...] > > All those factors speak greatly in favour of

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue, Mar 14, 2017 at 4:58 PM, Filip Štědronský wrote: > Hi, > > On Tue, Mar 14, 2017 at 01:18:01PM +0200, Amir Goldstein wrote: >> I claim that fanotify filters event by mount not because it >> was a requirement, but because it was an implementation challenge >> to do

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue, Mar 14, 2017 at 4:58 PM, Filip Štědronský wrote: > Hi, > > On Tue, Mar 14, 2017 at 01:18:01PM +0200, Amir Goldstein wrote: >> I claim that fanotify filters event by mount not because it >> was a requirement, but because it was an implementation challenge >> to do otherwise. >> >> And I

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

Hi, On Tue, Mar 14, 2017 at 01:18:01PM +0200, Amir Goldstein wrote: > I claim that fanotify filters event by mount not because it > was a requirement, but because it was an implementation challenge > to do otherwise. > > And I claim that what mount watchers are really interested in is > "all the

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

Hi, On Tue, Mar 14, 2017 at 01:18:01PM +0200, Amir Goldstein wrote: > I claim that fanotify filters event by mount not because it > was a requirement, but because it was an implementation challenge > to do otherwise. > > And I claim that what mount watchers are really interested in is > "all the

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský wrote: > Besause fanotify requires `struct path`, the event cannot be generated > directly in `fsnotify_move` and friends because they only get the inode > (and their callers, `vfs_rename` cannot supply any better info). > So

Re: [RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

On Tue, Mar 14, 2017 at 1:03 AM, Filip Štědronský wrote: > Besause fanotify requires `struct path`, the event cannot be generated > directly in `fsnotify_move` and friends because they only get the inode > (and their callers, `vfs_rename` cannot supply any better info). > So instead it needs to

[RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

Besause fanotify requires `struct path`, the event cannot be generated directly in `fsnotify_move` and friends because they only get the inode (and their callers, `vfs_rename` cannot supply any better info). So instead it needs to be generated higher in the call chain, i.e. in the callers of

[RFC 2/2] fanotify: emit FAN_MODIFY_DIR on filesystem changes

Besause fanotify requires `struct path`, the event cannot be generated directly in `fsnotify_move` and friends because they only get the inode (and their callers, `vfs_rename` cannot supply any better info). So instead it needs to be generated higher in the call chain, i.e. in the callers of