From: Jens Axboe <axboe@kernel.dk>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>
Cc: Ming Lei <tom.leiming@gmail.com>,
io-uring <io-uring@vger.kernel.org>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: RCU warning off ublk_buf_cleanup() -> mas_for_each()
Date: Tue, 21 Apr 2026 15:41:06 -0600 [thread overview]
Message-ID: <6c1eaf1c-5c1e-4ca3-a9b6-b0305fcce588@kernel.dk> (raw)
In-Reply-To: <qyob3dbqkicviyjs77q6mmxldtwm6qdpgwznzw6ulipztphlbl@nb4bzctzlsnw>
On 4/21/26 2:28 PM, Liam R. Howlett wrote:
> * Jens Axboe <axboe@kernel.dk> [260421 13:47]:
>> Hi Ming,
>>
>> Ran into the below running tests on the current tree:
>>
>> =============================
>> WARNING: suspicious RCU usage
>> 7.0.0+ #16 Tainted: G N
>> -----------------------------
>> lib/maple_tree.c:759 suspicious rcu_dereference_check() usage!
>>
>> other info that might help us debug this:
>>
>>
>> rcu_scheduler_active = 2, debug_locks = 1
>> 1 lock held by iou-wrk-55535/55536:
>> #0: ffff800085a451a0 (ublk_ctl_mutex){+.+.}-{4:4}, at: ublk_ctrl_del_dev+0xdc/0x2f8
>>
>> stack backtrace:
>> CPU: 4 UID: 0 PID: 55536 Comm: iou-wrk-55535 Tainted: G N 7.0.0+ #16 PREEMPT
>> Tainted: [N]=TEST
>> Hardware name: linux,dummy-virt (DT)
>> Call trace:
>> show_stack+0x1c/0x30 (C)
>> dump_stack_lvl+0x68/0x90
>> dump_stack+0x18/0x20
>> lockdep_rcu_suspicious+0x170/0x200
>> mas_walk+0x3f0/0x6a0
>> mas_find+0x1b4/0x6b0
>> ublk_buf_cleanup+0xe0/0x240
>> ublk_cdev_rel+0x34/0x1b0
>> device_release+0xa4/0x350
>> kobject_put+0x138/0x250
>> put_device+0x18/0x30
>> ublk_put_device+0x18/0x28
>> ublk_ctrl_del_dev+0x120/0x2f8
>> ublk_ctrl_uring_cmd+0x598/0x29b8
>> io_uring_cmd+0x1e0/0x468
>> __io_issue_sqe+0xa4/0x748
>> io_issue_sqe+0x80/0xf68
>> io_wq_submit_work+0x26c/0xdc8
>> io_worker_handle_work+0x334/0xf20
>> io_wq_worker+0x278/0x9e8
>> ret_from_fork+0x10/0x20
>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>> ublkb0: unable to read partition table
>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>> Buffer I/O error on dev ublkb0, logical block 512, async page read
>> Buffer I/O error on dev ublkb0, logical block 512, async page read
>> Buffer I/O error on dev ublkb0, logical block 0, async page read
>> Buffer I/O error on dev ublkb0, logical block 512, async page read
>>
>> and I briefly looked at it, but then just gave up as a) the maple tree
>> documentation is not that detailed,
>
> Which documentation is lacking? I will fix it.
>
> I have user documentation in the Documentation directory while
> technical details are in the code.
I went into the core-api/ and leafed through that, didn't have anything
on mas_for_each() that pertained to locking. Was hoping I'd find a table
of which parts of the API requires what in terms of locking or RCU.
There arent a whole lot of in-kernel users of it yet, so looking at
other places in the kernel wasn't very useful.
Since this is a merge window regression, I really just passed it to Ming
with you on the CC just in case, and didn't spend any more time on it.
I'm not the one that's supposed to be finding issues like this...
>> and b) other in-tree users also just
>> call mas_for_each() without either a lock held or RCU read side locked.
>
> mas_for_each() must hold a lock of some type.
That's what I assumed. I missed that the rcu dereference check
checks for an external lock too, which I guess you can register
with the maple tree. Funky... I guess it's just for lockdep
purposes, makes sense then.
Presumably the current use case is fine, as it's serialized
teardown. It just ends up triggering the rcu sanity checks.
--
Jens Axboe
next prev parent reply other threads:[~2026-04-21 21:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-21 17:47 RCU warning off ublk_buf_cleanup() -> mas_for_each() Jens Axboe
2026-04-21 18:04 ` Jens Axboe
2026-04-21 20:28 ` Liam R. Howlett
2026-04-21 21:41 ` Jens Axboe [this message]
2026-04-21 21:56 ` Liam R. Howlett
2026-04-21 22:03 ` Jens Axboe
2026-04-23 21:45 ` Bernd Schubert
2026-04-23 21:48 ` Jens Axboe
2026-04-23 21:51 ` Bernd Schubert
2026-04-23 22:02 ` Jens Axboe
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=6c1eaf1c-5c1e-4ca3-a9b6-b0305fcce588@kernel.dk \
--to=axboe@kernel.dk \
--cc=Liam.Howlett@oracle.com \
--cc=io-uring@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=tom.leiming@gmail.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