On Thu 05-08-21 17:14:26, Amir Goldstein wrote: > > 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. I see, thanks for explanation. I forgot that NULL 'inode' argument from fsnotify_name() is actually needed for this to work. > 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. Yeah. I'll think a bit more if we could simplify this but now I don't see anything obvious. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
