All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Anand Jain <anand.jain@oracle.com>
Cc: stable@vger.kernel.org, linux-btrfs@vger.kernel.org,
	Sherry Yang <sherry.yang@oracle.com>,
	kernel test robot <oliver.sang@intel.com>,
	David Sterba <dsterba@suse.com>
Subject: Re: [PATCH stable-5.4.y stable-5.10.y] btrfs: scan device in non-exclusive mode
Date: Mon, 3 Apr 2023 15:02:12 +0200	[thread overview]
Message-ID: <2023040302-schnapps-egging-77d7@gregkh> (raw)
In-Reply-To: <de2889bd0a9ea5446c3473fe7b2086fbd954b9ab.1680496851.git.anand.jain@oracle.com>

On Mon, Apr 03, 2023 at 01:46:08PM +0800, Anand Jain wrote:
> commit 50d281fc434cb8e2497f5e70a309ccca6b1a09f0 upstream.
> 
> This fixes mkfs/mount/check failures due to race with systemd-udevd
> scan.
> 
> During the device scan initiated by systemd-udevd, other user space
> EXCL operations such as mkfs, mount, or check may get blocked and result
> in a "Device or resource busy" error. This is because the device
> scan process opens the device with the EXCL flag in the kernel.
> 
> Two reports were received:
> 
>  - btrfs/179 test case, where the fsck command failed with the -EBUSY
>    error
> 
>  - LTP pwritev03 test case, where mkfs.vfs failed with
>    the -EBUSY error, when mkfs.vfs tried to overwrite old btrfs filesystem
>    on the device.
> 
> In both cases, fsck and mkfs (respectively) were racing with a
> systemd-udevd device scan, and systemd-udevd won, resulting in the
> -EBUSY error for fsck and mkfs.
> 
> Reproducing the problem has been difficult because there is a very
> small window during which these userspace threads can race to
> acquire the exclusive device open. Even on the system where the problem
> was observed, the problem occurrences were anywhere between 10 to 400
> iterations and chances of reproducing decreases with debug printk()s.
> 
> However, an exclusive device open is unnecessary for the scan process,
> as there are no write operations on the device during scan. Furthermore,
> during the mount process, the superblock is re-read in the below
> function call chain:
> 
>   btrfs_mount_root
>    btrfs_open_devices
>     open_fs_devices
>      btrfs_open_one_device
>        btrfs_get_bdev_and_sb
> 
> So, to fix this issue, removes the FMODE_EXCL flag from the scan
> operation, and add a comment.
> 
> The case where mkfs may still write to the device and a scan is running,
> the btrfs signature is not written at that time so scan will not
> recognize such device.
> 
> Reported-by: Sherry Yang <sherry.yang@oracle.com>
> Reported-by: kernel test robot <oliver.sang@intel.com>
> Link: https://lore.kernel.org/oe-lkp/202303170839.fdf23068-oliver.sang@intel.com
> CC: stable@vger.kernel.org # 5.4+
> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> Reviewed-by: David Sterba <dsterba@suse.com>
> Signed-off-by: David Sterba <dsterba@suse.com>
> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> ---
> 
> The upstream commit 50d281fc434cb8e2497f5e70a309ccca6b1a09f0 can be
> applied without conflict to LTS stable-5.15.y and stable-6.1.y. However,
> on LTS stable-5.4.y and stable-5.15.y, a conflict fix is required since
> the zoned device support commits are not present in these versions. This
> patch resolves the conflicts.

Now queued up, thanks.

greg k-h

      reply	other threads:[~2023-04-03 13:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-03  5:46 [PATCH stable-5.4.y stable-5.10.y] btrfs: scan device in non-exclusive mode Anand Jain
2023-04-03 13:02 ` Greg KH [this message]

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=2023040302-schnapps-egging-77d7@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=anand.jain@oracle.com \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=oliver.sang@intel.com \
    --cc=sherry.yang@oracle.com \
    --cc=stable@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 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.