* [PATCH v1] btrfs: wait for a grace period before freeing a new device
@ 2026-09-29 12:36 Binbin Deng
2026-09-29 23:28 ` Qu Wenruo
0 siblings, 1 reply; 6+ messages in thread
From: Binbin Deng @ 2026-09-29 12:36 UTC (permalink / raw)
To: dsterba; +Cc: linux-btrfs, linux-kernel, Binbin Deng
KASAN reports a slab-use-after-free in btrfs_statfs() walking
fs_devices->devices. btrfs_init_new_device() publishes the new device
with list_add_rcu() and can fail afterwards, for example with -ENOSPC
in init_first_rw_device() when a user with CAP_SYS_ADMIN adds a device
that is too small to a seeding filesystem mounted read-only. The error
path removes the entry with list_del_rcu() and frees the object in
btrfs_free_device() without waiting for a grace period, while
btrfs_calc_avail_data_space() and btrfs_ioctl_fs_info() keep reading
the device list under rcu_read_lock().
BUG: KASAN: slab-use-after-free in btrfs_statfs+0x11af/0x14a0
Read of size 8 at addr ffff8880096be858 by task poc/252
Call Trace:
<TASK>
dump_stack_lvl+0x53/0x70
print_report+0xd0/0x630
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? filename_lookup+0x1a9/0x540
? btrfs_statfs+0x11af/0x14a0
kasan_report+0xce/0x100
? btrfs_statfs+0x11af/0x14a0
btrfs_statfs+0x11af/0x14a0
statfs_by_dentry+0x117/0x1e0
user_statfs+0xac/0x130
? __pfx_user_statfs+0x10/0x10
__do_sys_statfs+0x80/0xe0
? __pfx___do_sys_statfs+0x10/0x10
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Allocated by task 256:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x8f/0xa0
__kmalloc_cache_noprof+0x158/0x370
btrfs_alloc_device+0xad/0x3e0
btrfs_init_new_device+0x3e8/0x36e0
btrfs_ioctl+0x150d/0x6c20
__x64_sys_ioctl+0x134/0x1c0
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 256:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x43/0x70
kfree+0x121/0x380
btrfs_init_new_device+0x4a0/0x36e0
btrfs_ioctl+0x150d/0x6c20
__x64_sys_ioctl+0x134/0x1c0
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix by waiting for an RCU grace period after the device is removed
from the list and before it is freed.
Fixes: 1f78160ce1b1 ("Btrfs: using rcu lock in the reader side of devices list")
Signed-off-by: Binbin Deng <18983559317@163.com>
---
fs/btrfs/volumes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 85ea9c5d4536..2693dacd1da7 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3168,6 +3168,7 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
btrfs_update_per_profile_avail(fs_info);
mutex_unlock(&fs_info->chunk_mutex);
mutex_unlock(&fs_info->fs_devices->device_list_mutex);
+ synchronize_rcu();
error_trans:
if (trans)
btrfs_end_transaction(trans);
--
2.43.0
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1] btrfs: wait for a grace period before freeing a new device
2026-09-29 12:36 [PATCH v1] btrfs: wait for a grace period before freeing a new device Binbin Deng
@ 2026-09-29 23:28 ` Qu Wenruo
2026-09-30 13:58 ` [PATCH v2] " Binbin Deng
2026-09-30 15:12 ` [PATCH v1] " Daniel Vacek
0 siblings, 2 replies; 6+ messages in thread
From: Qu Wenruo @ 2026-09-29 23:28 UTC (permalink / raw)
To: Binbin Deng, dsterba; +Cc: linux-btrfs, linux-kernel
在 2026/9/29 22:06, Binbin Deng 写道:
> KASAN reports a slab-use-after-free in btrfs_statfs() walking
> fs_devices->devices. btrfs_init_new_device() publishes the new device
> with list_add_rcu() and can fail afterwards, for example with -ENOSPC
> in init_first_rw_device() when a user with CAP_SYS_ADMIN adds a device
> that is too small to a seeding filesystem mounted read-only. The error
> path removes the entry with list_del_rcu() and frees the object in
> btrfs_free_device() without waiting for a grace period, while
> btrfs_calc_avail_data_space() and btrfs_ioctl_fs_info() keep reading
> the device list under rcu_read_lock().
>
> BUG: KASAN: slab-use-after-free in btrfs_statfs+0x11af/0x14a0
> Read of size 8 at addr ffff8880096be858 by task poc/252
> Call Trace:
> <TASK>
> dump_stack_lvl+0x53/0x70
> print_report+0xd0/0x630
> ? __pfx__raw_spin_lock_irqsave+0x10/0x10
> ? filename_lookup+0x1a9/0x540
> ? btrfs_statfs+0x11af/0x14a0
> kasan_report+0xce/0x100
> ? btrfs_statfs+0x11af/0x14a0
> btrfs_statfs+0x11af/0x14a0
> statfs_by_dentry+0x117/0x1e0
> user_statfs+0xac/0x130
> ? __pfx_user_statfs+0x10/0x10
> __do_sys_statfs+0x80/0xe0
> ? __pfx___do_sys_statfs+0x10/0x10
> do_syscall_64+0xf9/0x540
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Allocated by task 256:
> kasan_save_stack+0x33/0x60
> kasan_save_track+0x14/0x30
> __kasan_kmalloc+0x8f/0xa0
> __kmalloc_cache_noprof+0x158/0x370
> btrfs_alloc_device+0xad/0x3e0
> btrfs_init_new_device+0x3e8/0x36e0
> btrfs_ioctl+0x150d/0x6c20
> __x64_sys_ioctl+0x134/0x1c0
> do_syscall_64+0xf9/0x540
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Freed by task 256:
> kasan_save_stack+0x33/0x60
> kasan_save_track+0x14/0x30
> kasan_save_free_info+0x3b/0x60
> __kasan_slab_free+0x43/0x70
> kfree+0x121/0x380
> btrfs_init_new_device+0x4a0/0x36e0
> btrfs_ioctl+0x150d/0x6c20
> __x64_sys_ioctl+0x134/0x1c0
> do_syscall_64+0xf9/0x540
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Fix by waiting for an RCU grace period after the device is removed
> from the list and before it is freed.
>
> Fixes: 1f78160ce1b1 ("Btrfs: using rcu lock in the reader side of devices list")
> Signed-off-by: Binbin Deng <18983559317@163.com>
> ---
> fs/btrfs/volumes.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 85ea9c5d4536..2693dacd1da7 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -3168,6 +3168,7 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
> btrfs_update_per_profile_avail(fs_info);
> mutex_unlock(&fs_info->chunk_mutex);
> mutex_unlock(&fs_info->fs_devices->device_list_mutex);
> + synchronize_rcu();
Please follow all other call sites where synchronize_rcu() is called
just before btrfs_free_device().
> error_trans:
> if (trans)
> btrfs_end_transaction(trans);
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] btrfs: wait for a grace period before freeing a new device
2026-09-29 23:28 ` Qu Wenruo
@ 2026-09-30 13:58 ` Binbin Deng
2026-09-30 15:12 ` [PATCH v1] " Daniel Vacek
1 sibling, 0 replies; 6+ messages in thread
From: Binbin Deng @ 2026-09-30 13:58 UTC (permalink / raw)
To: dsterba; +Cc: linux-btrfs, linux-kernel, Binbin Deng, Qu Wenruo
KASAN reports a slab-use-after-free in btrfs_statfs() walking
fs_devices->devices. btrfs_init_new_device() publishes the new device
with list_add_rcu() and can fail afterwards, for example with -ENOSPC
in init_first_rw_device() when a user with CAP_SYS_ADMIN adds a device
that is too small to a seeding filesystem mounted read-only. The error
path removes the entry with list_del_rcu() and frees the object in
btrfs_free_device() without waiting for a grace period, while
btrfs_calc_avail_data_space() and btrfs_ioctl_fs_info() keep reading
the device list under rcu_read_lock().
BUG: KASAN: slab-use-after-free in btrfs_statfs+0x11af/0x14a0
Read of size 8 at addr ffff8880096be858 by task poc/252
Call Trace:
<TASK>
dump_stack_lvl+0x53/0x70
print_report+0xd0/0x630
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? filename_lookup+0x1a9/0x540
? btrfs_statfs+0x11af/0x14a0
kasan_report+0xce/0x100
? btrfs_statfs+0x11af/0x14a0
btrfs_statfs+0x11af/0x14a0
statfs_by_dentry+0x117/0x1e0
user_statfs+0xac/0x130
? __pfx_user_statfs+0x10/0x10
__do_sys_statfs+0x80/0xe0
? __pfx___do_sys_statfs+0x10/0x10
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Allocated by task 256:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x8f/0xa0
__kmalloc_cache_noprof+0x158/0x370
btrfs_alloc_device+0xad/0x3e0
btrfs_init_new_device+0x3e8/0x36e0
btrfs_ioctl+0x150d/0x6c20
__x64_sys_ioctl+0x134/0x1c0
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 256:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x43/0x70
kfree+0x121/0x380
btrfs_init_new_device+0x4a0/0x36e0
btrfs_ioctl+0x150d/0x6c20
__x64_sys_ioctl+0x134/0x1c0
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix by waiting for an RCU grace period after the device is removed
from the list and before it is freed.
Suggested-by: Qu Wenruo<quwenruo.btrfs@gmx.com>
Fixes: 1f78160ce1b1 ("Btrfs: using rcu lock in the reader side of devices list")
Signed-off-by: Binbin Deng <18983559317@163.com>
---
Changes in v2:
- Move synchronize_rcu() just before btrfs_free_device(), following the
other call sites in volumes.c, as suggested by the reviewer.
fs/btrfs/volumes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 85ea9c5d4536..ec89dc3dc4cd 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3174,6 +3174,7 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
error_free_zone:
btrfs_destroy_dev_zone_info(device);
error_free_device:
+ synchronize_rcu();
btrfs_free_device(device);
error:
btrfs_release_device_allow_freeze(bdev_file);
--
2.43.0
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1] btrfs: wait for a grace period before freeing a new device
2026-09-29 23:28 ` Qu Wenruo
2026-09-30 13:58 ` [PATCH v2] " Binbin Deng
@ 2026-09-30 15:12 ` Daniel Vacek
1 sibling, 0 replies; 6+ messages in thread
From: Daniel Vacek @ 2026-09-30 15:12 UTC (permalink / raw)
To: Qu Wenruo; +Cc: Binbin Deng, dsterba, linux-btrfs, linux-kernel
On Wed, 30 Sept 2026 at 01:29, Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
> 在 2026/9/29 22:06, Binbin Deng 写道:
> > KASAN reports a slab-use-after-free in btrfs_statfs() walking
> > fs_devices->devices. btrfs_init_new_device() publishes the new device
> > with list_add_rcu() and can fail afterwards, for example with -ENOSPC
> > in init_first_rw_device() when a user with CAP_SYS_ADMIN adds a device
> > that is too small to a seeding filesystem mounted read-only. The error
> > path removes the entry with list_del_rcu() and frees the object in
> > btrfs_free_device() without waiting for a grace period, while
> > btrfs_calc_avail_data_space() and btrfs_ioctl_fs_info() keep reading
> > the device list under rcu_read_lock().
> >
> > BUG: KASAN: slab-use-after-free in btrfs_statfs+0x11af/0x14a0
> > Read of size 8 at addr ffff8880096be858 by task poc/252
> > Call Trace:
> > <TASK>
> > dump_stack_lvl+0x53/0x70
> > print_report+0xd0/0x630
> > ? __pfx__raw_spin_lock_irqsave+0x10/0x10
> > ? filename_lookup+0x1a9/0x540
> > ? btrfs_statfs+0x11af/0x14a0
> > kasan_report+0xce/0x100
> > ? btrfs_statfs+0x11af/0x14a0
> > btrfs_statfs+0x11af/0x14a0
> > statfs_by_dentry+0x117/0x1e0
> > user_statfs+0xac/0x130
> > ? __pfx_user_statfs+0x10/0x10
> > __do_sys_statfs+0x80/0xe0
> > ? __pfx___do_sys_statfs+0x10/0x10
> > do_syscall_64+0xf9/0x540
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > Allocated by task 256:
> > kasan_save_stack+0x33/0x60
> > kasan_save_track+0x14/0x30
> > __kasan_kmalloc+0x8f/0xa0
> > __kmalloc_cache_noprof+0x158/0x370
> > btrfs_alloc_device+0xad/0x3e0
> > btrfs_init_new_device+0x3e8/0x36e0
> > btrfs_ioctl+0x150d/0x6c20
> > __x64_sys_ioctl+0x134/0x1c0
> > do_syscall_64+0xf9/0x540
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > Freed by task 256:
> > kasan_save_stack+0x33/0x60
> > kasan_save_track+0x14/0x30
> > kasan_save_free_info+0x3b/0x60
> > __kasan_slab_free+0x43/0x70
> > kfree+0x121/0x380
> > btrfs_init_new_device+0x4a0/0x36e0
> > btrfs_ioctl+0x150d/0x6c20
> > __x64_sys_ioctl+0x134/0x1c0
> > do_syscall_64+0xf9/0x540
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > Fix by waiting for an RCU grace period after the device is removed
> > from the list and before it is freed.
> >
> > Fixes: 1f78160ce1b1 ("Btrfs: using rcu lock in the reader side of devices list")
> > Signed-off-by: Binbin Deng <18983559317@163.com>
> > ---
> > fs/btrfs/volumes.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> > index 85ea9c5d4536..2693dacd1da7 100644
> > --- a/fs/btrfs/volumes.c
> > +++ b/fs/btrfs/volumes.c
> > @@ -3168,6 +3168,7 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
> > btrfs_update_per_profile_avail(fs_info);
> > mutex_unlock(&fs_info->chunk_mutex);
> > mutex_unlock(&fs_info->fs_devices->device_list_mutex);
> > + synchronize_rcu();
>
> Please follow all other call sites where synchronize_rcu() is called
> just before btrfs_free_device().
This call site is unlike the others. The device is allocated and
initialized here.
There's no need to sync with RCU until the device has been published;
i.e. the other error paths are perfectly fine to just free the device
right away.
Placing the synchronize_rcu() after dropping the mutexes and before
the `error_trans` label is exactly the right spot in this function.
We should really be serious about needless RCU syncs.
--nX
> > error_trans:
> > if (trans)
> > btrfs_end_transaction(trans);
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] btrfs: wait for a grace period before freeing a new device
2026-09-30 13:48 [PATCH v2] " Binbin Deng
@ 2026-09-30 15:15 ` Daniel Vacek
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Vacek @ 2026-09-30 15:15 UTC (permalink / raw)
To: Binbin Deng; +Cc: dsterba, linux-btrfs, linux-kernel
On Wed, 30 Sept 2026 at 16:09, Binbin Deng <18983559317@163.com> wrote:
> KASAN reports a slab-use-after-free in btrfs_statfs() walking
> fs_devices->devices. btrfs_init_new_device() publishes the new device
> with list_add_rcu() and can fail afterwards, for example with -ENOSPC
> in init_first_rw_device() when a user with CAP_SYS_ADMIN adds a device
> that is too small to a seeding filesystem mounted read-only. The error
> path removes the entry with list_del_rcu() and frees the object in
> btrfs_free_device() without waiting for a grace period, while
> btrfs_calc_avail_data_space() and btrfs_ioctl_fs_info() keep reading
> the device list under rcu_read_lock().
>
> BUG: KASAN: slab-use-after-free in btrfs_statfs+0x11af/0x14a0
> Read of size 8 at addr ffff8880096be858 by task poc/252
> Call Trace:
> <TASK>
> dump_stack_lvl+0x53/0x70
> print_report+0xd0/0x630
> ? __pfx__raw_spin_lock_irqsave+0x10/0x10
> ? filename_lookup+0x1a9/0x540
> ? btrfs_statfs+0x11af/0x14a0
> kasan_report+0xce/0x100
> ? btrfs_statfs+0x11af/0x14a0
> btrfs_statfs+0x11af/0x14a0
> statfs_by_dentry+0x117/0x1e0
> user_statfs+0xac/0x130
> ? __pfx_user_statfs+0x10/0x10
> __do_sys_statfs+0x80/0xe0
> ? __pfx___do_sys_statfs+0x10/0x10
> do_syscall_64+0xf9/0x540
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Allocated by task 256:
> kasan_save_stack+0x33/0x60
> kasan_save_track+0x14/0x30
> __kasan_kmalloc+0x8f/0xa0
> __kmalloc_cache_noprof+0x158/0x370
> btrfs_alloc_device+0xad/0x3e0
> btrfs_init_new_device+0x3e8/0x36e0
> btrfs_ioctl+0x150d/0x6c20
> __x64_sys_ioctl+0x134/0x1c0
> do_syscall_64+0xf9/0x540
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Freed by task 256:
> kasan_save_stack+0x33/0x60
> kasan_save_track+0x14/0x30
> kasan_save_free_info+0x3b/0x60
> __kasan_slab_free+0x43/0x70
> kfree+0x121/0x380
> btrfs_init_new_device+0x4a0/0x36e0
> btrfs_ioctl+0x150d/0x6c20
> __x64_sys_ioctl+0x134/0x1c0
> do_syscall_64+0xf9/0x540
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>
> Fix by waiting for an RCU grace period after the device is removed
> from the list and before it is freed.
>
> Fixes: 1f78160ce1b1 ("Btrfs: using rcu lock in the reader side of devices list")
> Signed-off-by: Binbin Deng <18983559317@163.com>
> ---
> fs/btrfs/volumes.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 85ea9c5d4536..ec89dc3dc4cd 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -3174,6 +3174,7 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
> error_free_zone:
> btrfs_destroy_dev_zone_info(device);
> error_free_device:
> + synchronize_rcu();
> btrfs_free_device(device);
I believe v1 was better regarding the RCU sync logic.
--nX
> error:
> btrfs_release_device_allow_freeze(bdev_file);
> --
> 2.43.0
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH v2] btrfs: wait for a grace period before freeing a new device
@ 2026-09-30 13:48 Binbin Deng
2026-09-30 15:15 ` Daniel Vacek
0 siblings, 1 reply; 6+ messages in thread
From: Binbin Deng @ 2026-09-30 13:48 UTC (permalink / raw)
To: dsterba; +Cc: linux-btrfs, linux-kernel, Binbin Deng
KASAN reports a slab-use-after-free in btrfs_statfs() walking
fs_devices->devices. btrfs_init_new_device() publishes the new device
with list_add_rcu() and can fail afterwards, for example with -ENOSPC
in init_first_rw_device() when a user with CAP_SYS_ADMIN adds a device
that is too small to a seeding filesystem mounted read-only. The error
path removes the entry with list_del_rcu() and frees the object in
btrfs_free_device() without waiting for a grace period, while
btrfs_calc_avail_data_space() and btrfs_ioctl_fs_info() keep reading
the device list under rcu_read_lock().
BUG: KASAN: slab-use-after-free in btrfs_statfs+0x11af/0x14a0
Read of size 8 at addr ffff8880096be858 by task poc/252
Call Trace:
<TASK>
dump_stack_lvl+0x53/0x70
print_report+0xd0/0x630
? __pfx__raw_spin_lock_irqsave+0x10/0x10
? filename_lookup+0x1a9/0x540
? btrfs_statfs+0x11af/0x14a0
kasan_report+0xce/0x100
? btrfs_statfs+0x11af/0x14a0
btrfs_statfs+0x11af/0x14a0
statfs_by_dentry+0x117/0x1e0
user_statfs+0xac/0x130
? __pfx_user_statfs+0x10/0x10
__do_sys_statfs+0x80/0xe0
? __pfx___do_sys_statfs+0x10/0x10
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Allocated by task 256:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
__kasan_kmalloc+0x8f/0xa0
__kmalloc_cache_noprof+0x158/0x370
btrfs_alloc_device+0xad/0x3e0
btrfs_init_new_device+0x3e8/0x36e0
btrfs_ioctl+0x150d/0x6c20
__x64_sys_ioctl+0x134/0x1c0
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 256:
kasan_save_stack+0x33/0x60
kasan_save_track+0x14/0x30
kasan_save_free_info+0x3b/0x60
__kasan_slab_free+0x43/0x70
kfree+0x121/0x380
btrfs_init_new_device+0x4a0/0x36e0
btrfs_ioctl+0x150d/0x6c20
__x64_sys_ioctl+0x134/0x1c0
do_syscall_64+0xf9/0x540
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix by waiting for an RCU grace period after the device is removed
from the list and before it is freed.
Fixes: 1f78160ce1b1 ("Btrfs: using rcu lock in the reader side of devices list")
Signed-off-by: Binbin Deng <18983559317@163.com>
---
fs/btrfs/volumes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 85ea9c5d4536..ec89dc3dc4cd 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -3174,6 +3174,7 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
error_free_zone:
btrfs_destroy_dev_zone_info(device);
error_free_device:
+ synchronize_rcu();
btrfs_free_device(device);
error:
btrfs_release_device_allow_freeze(bdev_file);
--
2.43.0
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-30 15:15 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-09-29 12:36 [PATCH v1] btrfs: wait for a grace period before freeing a new device Binbin Deng
2026-09-29 23:28 ` Qu Wenruo
2026-09-30 13:58 ` [PATCH v2] " Binbin Deng
2026-09-30 15:12 ` [PATCH v1] " Daniel Vacek
2026-09-30 13:48 [PATCH v2] " Binbin Deng
2026-09-30 15:15 ` Daniel Vacek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®