On Tue 07-05-19 22:12:57, Amir Goldstein wrote: > On Tue, May 7, 2019 at 7:19 PM Jan Kara <jack@xxxxxxx> wrote: > > So I'd rather move the fsnotify call to vfs_unlink(), > > vfs_rmdir(), simple_unlink(), simple_rmdir(), and then those few callers of > > d_delete() that remain as you suggest elsewhere in this thread. And then we > > get more consistent context for fsnotify_nameremove() and could just use > > fsnotify_dirent(). > > > > Yes, I much prefer this solution myself and I will follow up with it, > but it would not be honest to suggest said solution as a stable fix > to the performance regression that was introduced in v5.1. > I think is it better if you choose between lesser evil: > v1 with ifdef CONFIG_FSNOTIFY to fix build issue > v2 as subtle as it is > OR another obviously safe stable fix that you can think of OK, fair enough. I'll go with v1 + build fix for current merge window + stable as it's local to fsnotify_nameremove(). > The change of cleansing d_delete() from fsnotify_nameremove() > requires more research and is anyway not stable tree material - > if not for the level of complexity, then because all the users of > FS_DELETE from pseudo and clustered filesystems need more time > to find regressions (we do not have test coverage for those in LTP). Agreed. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
