From: David Sterba <dsterba@suse.cz>
To: Wang Yugui <wangyugui@e16-tech.com>
Cc: Anand Jain <anand.jain@oracle.com>,
linux-btrfs@vger.kernel.org, Sherry Yang <sherry.yang@oracle.com>,
kernel test robot <oliver.sang@intel.com>
Subject: Re: [PATCH] btrfs: fix mkfs/mount/check failures due to race with systemd-udevd scan
Date: Thu, 23 Mar 2023 19:27:55 +0100 [thread overview]
Message-ID: <20230323182755.GX10580@twin.jikos.cz> (raw)
In-Reply-To: <20230323212745.4342.409509F4@e16-tech.com>
On Thu, Mar 23, 2023 at 09:27:46PM +0800, Wang Yugui wrote:
> > >> --- a/fs/btrfs/volumes.c
> > >> +++ b/fs/btrfs/volumes.c
> > >> @@ -1366,8 +1366,17 @@ struct btrfs_device *btrfs_scan_one_device(const char *path, fmode_t flags,
> > >> * So, we need to add a special mount option to scan for
> > >> * later supers, using BTRFS_SUPER_MIRROR_MAX instead
> > >> */
> > >> - flags |= FMODE_EXCL;
> > >> >> + /*
> > >> + * Avoid using flag |= FMODE_EXCL here, as the systemd-udev may
> > >> + * initiate the device scan which may race with the user's mount
> > >> + * or mkfs command, resulting in failure.
> > >
> > > for FMODE_READ | FMODE_EXCL, we need some sleep/retry,
> > > for FMODE_WRITE | FMODE_EXCL, we should fail immediately?
> >
> > Sorry I don't understand the context here what represents the we here?
> >
> > In the LTP testcase the two sides are
> > mkfs.<vfs|btrfs> side (FMODE_WRITE|FMODE_EXCL) and
> > device-scan side (now: FMODE_READ, before: FMODE_READ|FMODE_EXCL)
> >
> > > scan race with with mkfs may result worse?
> >
> > In the above example, the mkfs.<vfs|btrfs> failed immediately without
> > the patch and with the patch it is successful.
>
> With the patch, when mkfs.<vfs|btrfs> is still running,
> device-scan can read, but the read data is meaningless, so it is worse?
With running mkfs the scan will not recognize the device as btrfs due to
lack of signature. Once mkfs ends the scan event gets triggered again
and this is the safe case when concurrent read access does not need to
be exclusive.
next prev parent reply other threads:[~2023-03-23 18:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-23 7:56 [PATCH] btrfs: fix mkfs/mount/check failures due to race with systemd-udevd scan Anand Jain
2023-03-23 11:57 ` Wang Yugui
2023-03-23 13:14 ` Anand Jain
2023-03-23 13:27 ` Wang Yugui
2023-03-23 18:27 ` David Sterba [this message]
2023-03-23 18:24 ` 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=20230323182755.GX10580@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=anand.jain@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=oliver.sang@intel.com \
--cc=sherry.yang@oracle.com \
--cc=wangyugui@e16-tech.com \
/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.