[PATCH v2 0/2] fsnotify: drop SRCU across inotify event delivery

[Jia Zhu]

We observed fsnotify teardown stalls in production. NMI backtraces
showed inotify_handle_inode_event() in memcg reclaim, and the mark
reaper, inotifywait and a systemd process were reported blocked for more
than 327 seconds.

We checked upstream and found the same issue: inotify allocates events
under fsnotify_mark_srcu, and the global mark reaper waits in
synchronize_srcu().

The production report shows multiple inotify release paths blocked
behind the global mark reaper. Because SRCU and the reaper are shared
across groups, a stalled delivery can delay other groups' close() and
exit paths.

Patch 1 pins the iterator marks and drops SRCU around inotify delivery.
It retains fanotify's pinning semantics and preserves event delivery to
a surviving inotify watch when another watch is removed. This leaves the
reclaim stall itself unchanged.

Patch 2 skips the global reaper flush when only the closing group
reference remains. As Jan noted on the earlier patch [1], this only
helps groups with no outstanding marks. It is optional and can be
dropped.

The teardown fast path was checked in QEMU with a test-only SRCU holder.

[1] https://lore.kernel.org/all/4467cbj7eivubtdwcawvr7mhrb7armgoc4xfqjjnncrbkxxag6@3mmou6nhviao/

Jia Zhu (2):
  inotify: drop fsnotify SRCU protection during event delivery
  fsnotify: avoid unrelated mark reaper waits during group teardown

 fs/notify/fsnotify.c             | 15 ++++++++++++---
 fs/notify/group.c                | 26 +++++++++++++++-----------
 fs/notify/inotify/inotify_user.c |  3 ++-
 fs/notify/mark.c                 | 26 ++++++++++++++++++++++----
 include/linux/fsnotify_backend.h |  2 ++
 5 files changed, 53 insertions(+), 19 deletions(-)


base-commit: df2908090cda368b01ff43709f51890076c56157
-- 
2.20.1