public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/2] btrfs: fixes for the new fd-based API
Date: Wed, 30 Oct 2024 11:25:46 +1030	[thread overview]
Message-ID: <cover.1730249396.git.wqu@suse.com> (raw)

There are two critical bugs, all introduced by the same new fd-based
mount API migration.

The first one will break the per-subvolume RW/RO mount, if using the
new fd-based mount API.
This is caused by the untrue promise that the new API will not set the
RO flag for the fsconfig() call (which sets the super flags), but only
set RO attribute for the mount point.

Based on the bad promise, we skip the RO->RW reconfiguration for the new
API based mount call. But since the new fd-based mount is already
rolling out to the end users, and it still sets RO flags for both super
and mount point.

So we should still do the same RO->RW reconfiguration, no matter the
API.


The second one is a long existing problem related the RO->RW
reconfiguration itself, where we retry without any lock, resulting race
between reconfiguration and RO/RW mounts.

This will leads to a failure to mount, exposed by SLE-micro bug report.


Those two bugs are all small but critical to the core function of btrfs,
thus should be queued for -rc kernels.

Qu Wenruo (2):
  btrfs: fix per-subvolume RO/RW flags with new mount API
  btrfs: fix mount failure due to remount races

 fs/btrfs/super.c | 88 +++++++++++++++++-------------------------------
 1 file changed, 31 insertions(+), 57 deletions(-)

-- 
2.47.0


             reply	other threads:[~2024-10-30  0:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-30  0:55 Qu Wenruo [this message]
2024-10-30  0:55 ` [PATCH 1/2] btrfs: fix per-subvolume RO/RW flags with new mount API Qu Wenruo
2024-10-30  0:55 ` [PATCH 2/2] btrfs: fix mount failure due to remount races Qu Wenruo
2024-11-26 15:50 ` [PATCH 0/2] btrfs: fixes for the new fd-based API David Sterba

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=cover.1730249396.git.wqu@suse.com \
    --to=wqu@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox