[PATCH 0/5] fs: make the system calls waiting for s_umount killable

[Josef Bacik]

Hello,

This is the next step after the stuck unmount and stuck mount series,
and it applies on top of them (vfs-7.5.super).

Those two took care of the two ends of a super block's life, this one is
about a live one. s_umount can be held for a very long time. syncfs()
holds it shared for as long as it takes to write the file system out,
and on a slow or dead device that's forever. That by itself doesn't keep
other readers out, but as soon as somebody wants the lock exclusively, a
remount for example, that writer queues up, and every reader that comes
after it queues up behind the writer. None of them can be killed.

This converts the system calls that take s_umount themselves: syncfs(),
quotactl_fd(), mount() with MS_REMOUNT, fsconfig() with
FSCONFIG_CMD_RECONFIGURE and umount() of the root. They all take the
lock early and can already fail, so a killed wait just turns into an
error return. There are two things that happen before the lock.
quotactl_fd() has write access to the mount by then and drops it on the
way out, and a forced umount() of the root has called ->umount_begin(),
same as when the remount fails today. Killing the queued writer also
lets the readers behind it go.

This doesn't touch the super_lock() helpers. The walkers, sync(),
drop_caches and friends, have the same problem on a live super block,
but I'll do those once Christian's rework of the helpers is in.

It also doesn't make syncfs() killable once it has the lock, it still
waits for writeback uninterruptibly. That's a bigger job.

For testing I put ext4 on a dm-linear device, dirtied 64M, suspended the
device underneath it and called syncfs(), which leaves it sitting in
sync_filesystem() with s_umount held shared. Then I queued a remount
behind it. Without the series another syncfs(), quotactl_fd() and a bind
remount all pile up behind that remount, fsconfig() reconfigure, turning
quota off and umount() of the root pile up as well, and none of them,
the remount included, reacts to SIGKILL. With it they all go away on
SIGKILL, and once the queued remount is killed a new reader gets the
lock right away while the first syncfs() is still stuck. On both kernels
the syncfs() finishes once the device is resumed and all the data is
there, and nothing hangs in 200 rounds of all of them running against
each other. This was with KASAN and lockdep on, neither had anything to
say.

fstests on ext4, xfs and btrfs gives the same results with and without
the series. Thanks,

Josef

---
Josef Bacik (5):
      fs: make syncfs(2) killable on s_umount
      quota: make quotactl_fd(2) killable on s_umount
      fs: make mount(2) remounts killable on s_umount
      fs: make FSCONFIG_CMD_RECONFIGURE killable on s_umount
      fs: make umount(2) of the root killable on s_umount

 fs/fsopen.c      |  8 +++++---
 fs/namespace.c   | 13 +++++++++----
 fs/quota/quota.c |  8 +++++---
 fs/sync.c        |  4 +++-
 4 files changed, 22 insertions(+), 11 deletions(-)
---
base-commit: e6d8f4efc8e2301e15de7bcf9e8d3a2134fb058a
change-id: 20261022-b4-s-umount-killable-4c6379bec3ef