Re: [PATCH RFC] nfsd: avoid recursive locking through fsnotify

[Jan Kara <jack@suse.cz>]

On Wed 23-03-22 16:00:30, Amir Goldstein wrote:
> > Well, but reclaim from kswapd is always the main and preferred source of
> > memory reclaim. And we will kick kswapd to do work if we are running out of
> > memory. Doing direct filesystem slab reclaim from mark allocation is useful
> > only to throttle possibly aggressive mark allocations to the speed of
> > reclaim (instead of getting ENOMEM). So I'm still not convinced this is a
> > big issue but I certainly won't stop you from implementing more fine
> > grained GFP mode selection and lockdep annotations if you want to go that
> > way :).
> 
> Well it was just two lines of code to annotate the fanotify mutex as its own
> class, so I just did that:
> 
> https://github.com/amir73il/linux/commit/7b4b6e2c0bd1942cd130e9202c4b187a8fb468c6

But this implicitely assumes there isn't any allocation under mark_mutex
anywhere else where it is held. Which is likely true (I didn't check) but
it is kind of fragile. So I was rather imagining we would have per-group
"NOFS" flag and fsnotify_group_lock/unlock() would call
memalloc_nofs_save() based on the flag. And we would use
fsnotify_group_lock/unlock() uniformly across the whole fsnotify codebase.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR