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

[Leon Romanovsky <leon@kernel.org>]

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.

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