All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Jan Kara <jack@suse.cz>
Cc: Jens Axboe <axboe@kernel.dk>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	 linux-btrfs@vger.kernel.org, linux-erofs@lists.ozlabs.org,
	 linux-fsdevel@vger.kernel.org,
	 "Christian Brauner (Amutable)" <brauner@kernel.org>
Subject: [PATCH 0/2] super: convert to a plain hashtable
Date: Mon, 12 Oct 2026 14:31:17 +0200	[thread overview]
Message-ID: <20261012-work-super-dev_hash-v1-0-305cf71cd334@kernel.org> (raw)

This sits on top of the superblock fixes for v7.3.

Convert the rhltable to a plain hashtable under a spinlock. The walks
keep their place with a cursor entry in the chain. A claim is unhashed
the moment it's dropped and a walk that finds a superblock that isn't
born yet waits for it to be born or to die and looks again. Since
hashing can't fail anymore the entry for the superblock's own s_dev is
embedded in struct super_block and the preallocation in alloc_super()
goes away. This all simplifies things quite a lot.

It also fixes a btrfs bug where fs_bdev_freeze() ended up freezing a
btrfs filesystem through a stale member that open_ctree() had already
released while the freeze was waiting for SB_BORN. The resume doesn't
find a holder for that device anymore so the filesystem stays frozen
for good.

The selftest freezes a device that several erofs superblocks share.
That's the one case where a device legitimately carries claims from more
than one superblock and it checks that a suspend freezes each of them
exactly once and that mounts coming and going under a suspended device
leave nothing frozen behind.

I modeled the table in TLA+ and checked the real list code with CBMC.
Both agree with the design.

Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
---
Christian Brauner (2):
      selftests/filesystems: add a test for freezing a shared block device
      super: convert to plain hashtable

 block/bdev.c                                       |   2 +-
 fs/internal.h                                      |   1 -
 fs/namespace.c                                     |   2 -
 fs/super.c                                         | 332 ++++++--------
 include/linux/fs/super_types.h                     |  11 +-
 .../selftests/filesystems/freeze/.gitignore        |   1 +
 .../testing/selftests/filesystems/freeze/Makefile  |   2 +-
 tools/testing/selftests/filesystems/freeze/config  |   1 +
 .../filesystems/freeze/shared_bdev_test.c          | 479 +++++++++++++++++++++
 9 files changed, 627 insertions(+), 204 deletions(-)
---
base-commit: 16efce55f70b6093dbe53bffb8e79fb0e08a95b6
change-id: 20261011-work-super-dev_hash-e30f79361408


             reply	other threads:[~2026-10-12 12:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-12 12:31 Christian Brauner [this message]
2026-10-12 12:31 ` [PATCH 1/2] selftests/filesystems: add a test for freezing a shared block device Christian Brauner
2026-10-12 12:31 ` [PATCH 2/2] super: convert to plain hashtable Christian Brauner
2026-10-12 16:16   ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261012-work-super-dev_hash-v1-0-305cf71cd334@kernel.org \
    --to=brauner@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=jack@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.