diff options
| author | Abhijit Gangurde <abhijit.gangurde@amd.com> | 2026-09-25 15:06:37 +0530 |
|---|---|---|
| committer | Leon Romanovsky <leon@kernel.org> | 2026-09-29 14:45:33 -0400 |
| commit | 2eca9c14e66a1f71c089fe5c3afb2d339da3023a (patch) | |
| tree | 75f2d5c81c1a3ff1796f1c42715dc72a2d844c07 /tools/lib/python/kdoc/python_version.py | |
| parent | ad91fd9e9440ab23b3716aaac332e5d237535afb (diff) | |
RDMA/ionic: Fix XArray initialization to use XArray flags
xa_init_flags() takes XArray flags (XA_FLAGS_*), not gfp flags, even
though the parameter is typed gfp_t. Passing GFP_ATOMIC leaves both
lock-type bits clear, so xa_lock_type() resolves to XA_LOCK_NORMAL for
qp_tbl and cq_tbl.
Both tables are used with the IRQ-safe accessors: xa_store_irq() with
GFP_KERNEL from process context, and xa_lock_irqsave() from the event
queue path. When a store needs to grow the tree, __xas_nomem() drops
the lock using the recorded lock type before allocating:
if (gfpflags_allow_blocking(gfp)) {
xas_unlock_type(xas, lock_type);
xas->xa_alloc = kmem_cache_alloc_lru(...);
xas_lock_type(xas, lock_type);
}
With XA_LOCK_NORMAL that is a plain spin_unlock(), so the sleeping
GFP_KERNEL allocation runs with interrupts still disabled by
xa_store_irq(), and lockdep annotates the lock with the wrong class.
GFP_ATOMIC also happens to set __GFP_HIGH (0x20), which collides with
XA_FLAGS_ACCOUNT (32U) and silently enables memcg accounting of the
XArray nodes.
Use XA_FLAGS_LOCK_IRQ so the lock type matches how the tables are
actually accessed.
Fixes: e8521822c733 ("RDMA/ionic: Register device ops for control path")
Signed-off-by: Abhijit Gangurde <abhijit.gangurde@amd.com>
Link: https://patch.msgid.link/20260925093638.3032149-1-abhijit.gangurde@amd.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions
