Re: [PATCH 0/5] super: rework super_lock()

[Josef Bacik]

On Fri, Oct 23, 2026 at 5:42 AM Christian Brauner <brauner@xxxxxxxxxx> wrote:
>
> Josef's two series (cf. [1], [2]) left us with four ways to lock a
> superblock and two ways to wait for one that's being shut down.
> super_lock(), super_lock_shared() and super_lock_excl() return true on
> success while super_lock_killable() returns 0. And callers that need an
> unmount to be over pair super_lock() with super_wait_shutdown() or
> super_wait_shutdown_killable() and have to pick the one that matches
> the lock they took. Jan pointed out the bool vs int mess (cf. [3]).
>
> So fold it all into a single super_lock() that takes SUPER_LOCK_EXCL,
> SUPER_LOCK_KILLABLE and SUPER_LOCK_WAIT_SHUTDOWN and returns 0 with
> s_umount held or a negative error code. The first three patches don't
> change behavior.
>
> The fourth patch makes sync(2) killable while it waits for s_umount of
> a live superblock. Right now a freeze or remount that's stuck under
> s_umount hangs every sync(2) on the machine and nobody can kill it.
> fs_bdev_sync() already works that way.
>
> The last patch adds a guard for super_lock() for the callers that take
> and drop s_umount in the same scope.
>
> This sits on top of vfs-7.5.super which carries Josef's series.
>
> [1]: https://lore.kernel.org/20261021-b4-super-lock-dying-v1-0-2b35e86706ff@xxxxxxxxxxxxxx
> [2]: https://lore.kernel.org/20261021-b4-super-lock-unborn-v1-0-0265eddb6dee@xxxxxxxxxxxxxx
> [3]: https://lore.kernel.org/tmw22jj2hn6g6lklme2j3rsfjvmstzpoicvibvmmv6sivd66oj@nhc4lng25gti
>
> Signed-off-by: Christian Brauner (Amutable) <brauner@xxxxxxxxxx>

Reviewed-by: Josef Bacik <josef@xxxxxxxxxxxxxx>

Thanks,

Josef