> > > So the cleanest solution I currently see is > > > to come up with helpers like "fsnotify_lock_group() & > > > fsnotify_unlock_group()" which will lock/unlock mark_mutex and also do > > > memalloc_nofs_save / restore magic. > > > > > > > Sounds good. Won't this cause a regression - more failures to setup new mark > > under memory pressure? > > Well, yes, the chances of hitting ENOMEM under heavy memory pressure are > higher. But I don't think that much memory is consumed by connectors or > marks that the reduced chances for direct reclaim would really > substantially matter for the system as a whole. > > > Should we maintain a flag in the group FSNOTIFY_GROUP_SHRINKABLE? > > and set NOFS state only in that case, so at least we don't cause regression > > for existing applications? > > So that's a possibility I've left in my sleeve ;). We could do it but then > we'd also have to tell lockdep that there are two kinds of mark_mutex locks > so that it does not complain about possible reclaim deadlocks. Doable but > at this point I didn't consider it worth it unless someone comes with a bug > report from a real user scenario. Are you sure about that? Note that fsnotify_destroy_mark() and friends already use lockdep class SINGLE_DEPTH_NESTING, so I think the lockdep annotation already assumes that deadlock from direct reclaim cannot happen and it is that assumption that was nearly broken by evictable inode marks. IIUC that means that we only need to wrap the fanotify allocations with GFP_NOFS (technically only after the first evictable mark)? Thanks, Amir.
