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/3] btrfs-progs: hunt down the stray fd close causing race with udev scan
Date: Fri,  2 Feb 2024 11:29:18 +1030	[thread overview]
Message-ID: <cover.1706827356.git.wqu@suse.com> (raw)

Although my previous flock() based solution is preventing udev scan to
get pre-mature super blocks, it in fact masks the root problem:

  There is a stray close() on writeable fd.

Commit b2a1be83b85f ("btrfs-progs: mkfs: keep file descriptors open
during whole time") tries to solve the problem by extending the lifespan
of writeable fds, so that when the fds are closed, the fs is ensured to
be properly populated.

The problem is, that patch is not covering all cases, there is a stray
fd close just under our noses: open_ctree_fs_info().

The function would open the initial device, then use that initial fd to
open the btrfs, then we immediately close the initial fd, as later IO
would all go with the device fd.

That close() call is causing problem, especially for mkfs, as at that
stage the fs is still using a temporary super block, not using the valid
btrfs super magic number.

Thus udev scan would race with mkfs, and if udev wins the race, it would
get the temporary super block, making libblk not to detect the new
btrfs.

This patchset would address the problem by:

- Make sure open_ctree*() calls all have corresponding close_ctree()
  The first patch, as later we will only close the initial fd caused by
  open_ctree_fs_info() during close_ctree().

- Save the initial fd into btrfs_fs_info for open_ctree_fs_info()
  And later close the initial fd during close_ctree().

- Make sure open_ctree_fd() callers to properly close the fd
  Just an extra cleanup.

This patchset would work even without the usage of flock() to block udev
scan, and since without flock() calls, the procedure is much simpler.

Qu Wenruo (3):
  btrfs-progs: rescue: properly close the fs for clear-ino-cache
  btrfs-progs: tune: fix the missing close()
  btrfs-progs: fix the stray fd close in open_ctree_fs_info()

 cmds/rescue.c           | 1 +
 kernel-shared/ctree.h   | 9 +++++++++
 kernel-shared/disk-io.c | 8 +++++++-
 tune/main.c             | 1 +
 4 files changed, 18 insertions(+), 1 deletion(-)

--
2.43.0


             reply	other threads:[~2024-02-02  0:59 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-02  0:59 Qu Wenruo [this message]
2024-02-02  0:59 ` [PATCH 1/3] btrfs-progs: rescue: properly close the fs for clear-ino-cache Qu Wenruo
2024-02-02  8:48   ` Anand Jain
2024-02-02  0:59 ` [PATCH 2/3] btrfs-progs: tune: fix the missing close() Qu Wenruo
2024-02-02  9:01   ` Anand Jain
2024-02-02  0:59 ` [PATCH 3/3] btrfs-progs: fix the stray fd close in open_ctree_fs_info() Qu Wenruo
2024-02-07 16:36   ` Anand Jain
2024-02-07 21:05     ` Qu Wenruo
2024-02-08  2:53       ` Anand Jain
2024-02-07  9:52 ` [PATCH 0/3] btrfs-progs: hunt down the stray fd close causing race with udev scan 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.1706827356.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