On Thu, Apr 21, 2022 at 5:35 PM Jan Kara <jack@xxxxxxx> wrote: > > On Wed 13-04-22 12:09:23, Amir Goldstein wrote: > > Instead of passing the allow_dups argument to fsnotify_add_mark() > > as an argument, define the mark flag FSNOTIFY_MARK_FLAG_ALLOW_DUPS > > to express the old allow_dups meaning and pass this information on the > > mark itself. > > > > We use mark->flags to pass inotify control flags and will pass more > > control flags in the future so let's make this the standard. > > > > Although the FSNOTIFY_MARK_FLAG_ALLOW_DUPS flag is not used after the > > call to fsnotify_add_mark(), it does not hurt to leave this information > > on the mark for future use. > > > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > > I wanted to comment on this already last time but forgot: > FSNOTIFY_MARK_FLAG_ALLOW_DUPS is IMO more a property of fsnotify_group > than a particular mark (or a particular call to fsnotify_add_mark()). As > such it would make more sense to me to have is as "feature" similarly to > fs-reclaim restrictions you introduce later in the series. That's a good idea. I'll do that. > > As a bonus, no need for 'flags' argument to > fsnotify_add_inode_mark_locked() or fsnotify_add_inode_mark(). I prefer to avoid collecting this bonus and leave a flags argument for future use. The reason is that I intend to try and convince you to take the patch for FSNOTIFY_ADD_MARK_UPDATE_MASKS in a future patch set, so for the chance that I am able to convince you, let's avoid the churn for now. We can always cleanup the unneeded flags argument later. Thanks, Amir.
