Re: [syzbot] [rdma?] WARNING in ib_dealloc_device

Leon Romanovsky
2026-04-14T10:47:05Z

On Mon, Apr 13, 2026 at 02:42:28PM -0300, Jason Gunthorpe wrote:
> On Mon, Apr 13, 2026 at 04:12:09PM +0000, Jiri Pirko wrote:
> > Will check it tmrw
>
> I fed it to Claude and after 40 mins it is stumped too.. It should not
> be possible for this to happen.

Interesting, I used Chris's prompts for this debug and got the following
suggestions (CONFIG_PREEMPT_RT=y in this .config):

------------------------------------------------------------------------
REMAINING HYPOTHESES
------------------------------------------------------------------------

1. PREEMPT_RT rwsem behavior (most likely for syzkaller SOFTLOCKUP trigger):
Under PREEMPT_RT, down_write/down_read use rt_mutex internally. Priority
inheritance and preemption semantics differ from non-RT. There may be a
window in the rwsem downgrade path inside enable_device_and_get (which
downgrades from WRITE to READ after setting DEVICE_REGISTERED) that allows
a concurrent disable_device to observe an inconsistent state.

Specifically: enable_device_and_get does:
down_write(devices_rwsem)
xa_set_mark(DEVICE_REGISTERED)
downgrade_write(devices_rwsem) [WRITE -> READ]
add_compat_devs()
up_read(devices_rwsem)

Under PREEMPT_RT, could disable_device acquire WRITE between the xa_set_mark
and downgrade_write? If so, it would clear DEVICE_REGISTERED while
add_compat_devs is about to run (but hasn't yet seen the mark cleared).

2. xa_for_each skipping entries during concurrent xa_erase restructuring:
If rdma_dev_exit_net's remove_one_compat_dev erases an entry concurrently
with remove_compat_devs iterating, xas_shrink (called inside xa_erase) could
restructure the xarray tree. If xa_find_after then traverses a restructured
tree and skips a subsequent entry, that entry remains in compat_devs.

This is subtle: xa_erase takes the xarray spinlock (or rt_mutex), but
xa_for_each calls xa_find_after under RCU. The RCU read side might see a
partially-restructured tree that looks different from the spinlock-visible
view. Under PREEMPT_RT, RCU critical sections can be longer.

3. rdma_compatdev_set (ib_devices_shared_netns sysctl) race:
add_all_compat_devs() is guarded by DEVICE_REGISTERED + devices_rwsem, so
the same analysis as T3a applies and the race is eliminated. However, if
there is a remove_all_compat_devs() implementation, its interaction with
the unregistration flow deserves verification.

------------------------------------------------------------------------
RECOMMENDED NEXT STEPS
------------------------------------------------------------------------

1. Add WARN_ON with stack trace inside add_one_compat_dev (compat_devs_mutex
held) that fires if DEVICE_REGISTERED is not set. If this never fires, the
insertion is always properly gated. If it fires, the unmarked insertion path
is identified.

2. Add ftrace or kprobe on remove_compat_devs and add_one_compat_dev to
capture the exact sequence of events. The key question: does any
add_one_compat_dev call happen AFTER remove_compat_devs for the same device?

3. Check whether the bug exists on non-PREEMPT_RT kernels. If only PREEMPT_RT
is affected, hypothesis 1 (rwsem downgrade race) or hypothesis 2 (RCU/xarray
interaction) is more likely.

4. Look at the kernel version of the syzkaller report. Check git log for any
changes to drivers/infiniband/core/device.c around the report date that may
have introduced or fixed the issue.

5. Investigate enable_device_and_get's downgrade_write() path -- specifically
whether a concurrent disable_device can observe DEVICE_REGISTERED set between
xa_set_mark and the downgrade, then fail to clear it before add_compat_devs runs.

------------------------------------------------------------------------