Re: [PATCH v5 10/23] fsnotify: Allow events reported with an empty inode

On Thu, Aug 5, 2021 at 1:24 PM Jan Kara [off-list ref] wrote:

On Wed 04-08-21 12:05:59, Gabriel Krisman Bertazi wrote:

quoted

Some file system events (i.e. FS_ERROR) might not be associated with an
inode.  For these, it makes sense to associate them directly with the
super block of the file system they apply to.  This patch allows the
event to be reported directly against the super block instead of an
inode.

Signed-off-by: Gabriel Krisman Bertazi <redacted>

There's a comment before fsnotify() declaration that states that 'either
@dir or @inode must be non-NULL' - in this patch it would be good time to
update that comment.

quoted

@@ -459,12 +460,13 @@ static void fsnotify_iter_next(struct fsnotify_iter_info *iter_info)
  *           if both are non-NULL event may be reported to both.
  * @cookie:  inotify rename cookie
  */
-int fsnotify(__u32 mask, const void *data, int data_type, struct inode *dir,
-          const struct qstr *file_name, struct inode *inode, u32 cookie)
+int fsnotify(__u32 mask, const void *data, int data_type,
+          struct super_block *sb, struct inode *dir,
+          const struct qstr *file_name, struct inode *inode,
+          u32 cookie)
 {

Two notes as ideas for consideration:

1) We could derive 'sb' from 'data'. I.e., have a helper like
fsnotify_data_sb(data, data_type). For FSNOTIFY_EVENT_PATH and
FSNOTIFY_EVENT_INODE this is easy to provide, for FSNOTIFY_EVENT_ERROR we
would have to add sb pointer to the structure but I guess that's easy. That
way we'd avoid the mostly NULL 'sb' argument. What do you guys think?

I think that's a great and simple idea that escaped me.

2) AFAICS 'inode' can be always derived from 'data' as well. So maybe we
can drop it Amir?

If only we could. The reason that we pass the allegedly redundant inode
argument is because there are two different distinguished inode
arguments:

1. The inode event happened on, which can be referenced from data
2. Inode that may be marked, which is passed in the inode argument

Particularly, dirent events carry the inode of the child as data, but
intentionally pass NULL inode arguments, because mark on inode
itself should not be getting e.g. FAN_DELETE event, but
audit_mark_handle_event() uses the child inode data.

If we wanted to, we could pass report_mask arg to fsnotify()
instead of inode arg and then fsnotify() will build iter_info
accordingly, but that sounds very complicated and doesn't gain
much.

There could be a simpler solution that I am missing...

Thanks,
Amir.