[PATCH] ublk: hold RCU read lock in ublk_try_buf_match()

Paolo Bertinetti posted 1 patch 1 day, 20 hours ago
drivers/block/ublk_drv.c | 2 ++
1 file changed, 2 insertions(+)
[PATCH] ublk: hold RCU read lock in ublk_try_buf_match()
Posted by Paolo Bertinetti 1 day, 20 hours ago
syzbot reports a lockdep splat when I/O is dispatched to a ublk device
with UBLK_F_SHMEM_ZC enabled:

  WARNING: suspicious RCU usage
  lib/maple_tree.c:720 suspicious rcu_dereference_check() usage!
  ...
  Call Trace:
   mas_root lib/maple_tree.c:720 [inline]
   mas_start+0x3cc/0x640 lib/maple_tree.c:1250
   mas_state_walk lib/maple_tree.c:3006 [inline]
   mas_walk+0x1db/0x490 lib/maple_tree.c:4458
   ublk_try_buf_match drivers/block/ublk_drv.c:5639 [inline]
   ublk_init_iod+0x5d2/0x1120 drivers/block/ublk_drv.c:521
   ublk_dispatch_req+0x97/0x9c0 drivers/block/ublk_drv.c:1776
   tctx_task_work_run+0x73d/0xa80 io_uring/tw.c:96

ublk_try_buf_match() calls mas_walk() on the buffer tree without
holding the RCU read lock or the tree lock. Writers are already
excluded because ublk_lock_buf_tree() freezes the queue, so there is
no real race, but maple tree readers must still hold one of the two.

Take the RCU read lock around the walk.

Fixes: 4d4a512a1f87 ("ublk: add PFN-based buffer matching in I/O path")
Reported-by: syzbot+b48868c46e62c1c4cb2c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=b48868c46e62c1c4cb2c
Assisted-by: LLM
Signed-off-by: Paolo Bertinetti <paolobertinetti200f4@proton.me>
---
syzbot tested this patch [1]: the RCU splat is gone, but the reproducer
then hits the already open "WARNING in io_wq_put_and_exit (2)" [2],
which syzbot has been reporting since May on kernels without this change.

[1] https://lore.kernel.org/all/6ab1eabe.71f81b7d.15fa6d.003b.GAE@google.com/
[2] https://syzkaller.appspot.com/bug?extid=b0d54b9e81de55179e47

 drivers/block/ublk_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
index 66eb55e71..7a64745e1 100644
--- a/drivers/block/ublk_drv.c
+++ b/drivers/block/ublk_drv.c
@@ -5628,6 +5628,8 @@ static bool ublk_try_buf_match(struct ublk_device *ub,
 	unsigned long expected_offset = 0;
 	bool first = true;
 
+	guard(rcu)();
+
 	rq_for_each_bvec(bv, rq, iter) {
 		unsigned long pfn = page_to_pfn(bv.bv_page);
 		unsigned long end_pfn = pfn +

base-commit: 93f51579e7df248780214094418f205253383cc5
-- 
2.55.0
Re: [PATCH] ublk: hold RCU read lock in ublk_try_buf_match()
Posted by Ming Lei 11 hours ago
On Tue, Sep 22, 2026 at 1:17 PM Paolo Bertinetti
<paolobertinetti200f4@proton.me> wrote:
>
> syzbot reports a lockdep splat when I/O is dispatched to a ublk device
> with UBLK_F_SHMEM_ZC enabled:
>
>   WARNING: suspicious RCU usage
>   lib/maple_tree.c:720 suspicious rcu_dereference_check() usage!
>   ...
>   Call Trace:
>    mas_root lib/maple_tree.c:720 [inline]
>    mas_start+0x3cc/0x640 lib/maple_tree.c:1250
>    mas_state_walk lib/maple_tree.c:3006 [inline]
>    mas_walk+0x1db/0x490 lib/maple_tree.c:4458
>    ublk_try_buf_match drivers/block/ublk_drv.c:5639 [inline]
>    ublk_init_iod+0x5d2/0x1120 drivers/block/ublk_drv.c:521
>    ublk_dispatch_req+0x97/0x9c0 drivers/block/ublk_drv.c:1776
>    tctx_task_work_run+0x73d/0xa80 io_uring/tw.c:96
>
> ublk_try_buf_match() calls mas_walk() on the buffer tree without
> holding the RCU read lock or the tree lock. Writers are already
> excluded because ublk_lock_buf_tree() freezes the queue, so there is
> no real race, but maple tree readers must still hold one of the two.
>
> Take the RCU read lock around the walk.
>
> Fixes: 4d4a512a1f87 ("ublk: add PFN-based buffer matching in I/O path")
> Reported-by: syzbot+b48868c46e62c1c4cb2c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=b48868c46e62c1c4cb2c
> Assisted-by: LLM
> Signed-off-by: Paolo Bertinetti <paolobertinetti200f4@proton.me>
> ---
> syzbot tested this patch [1]: the RCU splat is gone, but the reproducer
> then hits the already open "WARNING in io_wq_put_and_exit (2)" [2],
> which syzbot has been reporting since May on kernels without this change.
>
> [1] https://lore.kernel.org/all/6ab1eabe.71f81b7d.15fa6d.003b.GAE@google.com/
> [2] https://syzkaller.appspot.com/bug?extid=b0d54b9e81de55179e47
>
>  drivers/block/ublk_drv.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/block/ublk_drv.c b/drivers/block/ublk_drv.c
> index 66eb55e71..7a64745e1 100644
> --- a/drivers/block/ublk_drv.c
> +++ b/drivers/block/ublk_drv.c
> @@ -5628,6 +5628,8 @@ static bool ublk_try_buf_match(struct ublk_device *ub,
>         unsigned long expected_offset = 0;
>         bool first = true;
>
> +       guard(rcu)();
> +

Reviewed-by: Ming Lei <tom.leiming@gmail.com>

Thanks
Ming Lei