linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Wang Yugui <wangyugui@e16-tech.com>
Cc: David Sterba <dsterba@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH v2 1/2] btrfs: open code RCU for device name
Date: Fri, 4 Jul 2025 05:14:39 +0200	[thread overview]
Message-ID: <20250704031439.GA31241@suse.cz> (raw)
In-Reply-To: <20250702072946.6BE5.409509F4@e16-tech.com>

On Wed, Jul 02, 2025 at 07:29:47AM +0800, Wang Yugui wrote:
> > I can't seem to reproduce the warning with the command, I'm going to apply this
> > fixup:
> 
> steps to reproduce the warning:
> 1) install https://kojipkgs.fedoraproject.org/packages/sparse/0.6.4/
> 2) make btrfs module(kernel 6.16) with the commands
> #uname_r=$(uname -r)
> uname_r=$(ls /boot/vmlinuz-6.16.* 2>/dev/null)
> uname_r=${uname_r##/boot/vmlinuz-}
> pwd_dir=$(pwd)
> make -C /lib/modules/${uname_r}/build M=${pwd_dir} modules -j 20 W=1 C=1 CF="-Wnocontext"

I did try the W=1 C=1 build but there were no reports, even with update
sparse (which is what is run with bare C=1 I believe).

> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index bb91a7b..5080ab2 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -699,7 +699,7 @@ static int btrfs_open_one_device(struct btrfs_fs_devices *fs_devices,
>  	if (!device->name)
>  		return -EINVAL;
>  
> -	ret = btrfs_get_bdev_and_sb(device->name, flags, holder, 1,
> +	ret = btrfs_get_bdev_and_sb(rcu_dereference(device->name), flags, holder, 1,
>  				    &bdev_file, &disk_super);
>  	if (ret)
>  		return ret;
> @@ -1061,7 +1061,7 @@ static struct btrfs_fs_devices *clone_fs_devices(struct btrfs_fs_devices *orig)
>  		 * uuid mutex so nothing we touch in here is going to disappear.
>  		 */
>  		if (orig_dev->name)
> -			dev_path = orig_dev->name;
> +			dev_path = rcu_dereference(orig_dev->name);
>  
>  		device = btrfs_alloc_device(NULL, &orig_dev->devid,
>  					    orig_dev->uuid, dev_path);
> @@ -1436,7 +1436,7 @@ static bool btrfs_skip_registration(struct btrfs_super_block *disk_super,
>  
>  		list_for_each_entry(device, &fs_devices->devices, dev_list) {
>  			if (device->bdev && (device->bdev->bd_dev == devt) &&
> -			    strcmp(device->name, path) != 0) {
> +			    strcmp(rcu_dereference(device->name), path) != 0) {
>  				mutex_unlock(&fs_devices->device_list_mutex);
>  
>  				/* Do not skip registration. */
> @@ -2197,7 +2197,7 @@ void btrfs_scratch_superblocks(struct btrfs_fs_info *fs_info, struct btrfs_devic
>  	btrfs_kobject_uevent(bdev, KOBJ_CHANGE);
>  
>  	/* Update ctime/mtime for device path for libblkid */
> -	update_dev_time(device->name);
> +	update_dev_time(rcu_dereference(device->name));
>  }

I've updated the patch, this is basically equivalent to the same
expression but does not report any RCU violation. This should be safe in
all cases so the _raw's are justified for this patchset. The handling of
device->name perhaps does not fit any common pattern for RCU so we can't
avoid it. The protection involves no mounted filesystem (the scanning
ioctl) and then access when the filesystem is mounted. We have the
uuid_mutex for serializing everything.

For linux-next, I've updated the patch to use rcu_dereference_raw(),
depending on when the branch is picked for merge there should be no
warnings anymore.

  reply	other threads:[~2025-07-04  3:14 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-25 13:37 [PATCH v2 0/2] Device name and RCU string David Sterba
2025-06-25 13:37 ` [PATCH v2 1/2] btrfs: open code RCU for device name David Sterba
2025-06-30  2:24   ` Wang Yugui
2025-06-30 16:21     ` David Sterba
2025-06-30 16:43       ` David Sterba
2025-06-30 17:07         ` Alan Huang
2025-07-01 14:47           ` David Sterba
2025-07-01 23:29         ` Wang Yugui
2025-07-04  3:14           ` David Sterba [this message]
2025-07-07 14:28             ` David Sterba
2025-06-25 13:37 ` [PATCH v2 2/2] btrfs: remove struct rcu_string David Sterba
2025-06-26 14:46 ` [PATCH v2 0/2] Device name and RCU string Daniel Vacek

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=20250704031439.GA31241@suse.cz \
    --to=dsterba@suse.cz \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).