* [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()
@ 2026-09-04 9:44 Alexandra Winter
2026-09-05 0:42 ` Dust Li
2026-09-05 9:45 ` sashiko-bot
0 siblings, 2 replies; 3+ messages in thread
From: Alexandra Winter @ 2026-09-04 9:44 UTC (permalink / raw)
To: D. Wythe, Dust Li, Sidraya Jayagond, Mahanta Jambigi,
David Miller, Jakub Kicinski, Paolo Abeni, Eric Dumazet,
Andrew Lunn
Cc: Tony Lu, Wen Gu, netdev, linux-s390, linux-kernel, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Simon Horman
dibs->lock is acquired in process context and interrupt context
(ism_handle_irq()). So always use spin_lock_irqsave() in process context.
Note that this is not a real deadlock, as dibs_lo devices don't have
any interrupt context.
Example warning:
[ 153.760872] ================================
[ 153.760878] WARNING: inconsistent lock state
[ 153.760885] 7.2.0-15871-g544d85de4dc2 #16 Not tainted
[ 153.760891] --------------------------------
[ 153.760896] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[ 153.760901] python3/5134 [HC0[0]:SC0[2]:HE1:SE0] takes:
[ 153.760909] 0001222c0fe72428 (&dibs->lock){?...}-{2:2}, at: dibs_lo_move_data+0x1ce/0x380
[ 153.760932] {IN-HARDIRQ-W} state was registered at:
[ 153.760937] __lock_acquire+0x59c/0x15d0
[ 153.760947] lock_acquire.part.0+0x11c/0x290
[ 153.760953] lock_acquire+0xb4/0x1e0
[ 153.760959] _raw_spin_lock+0x58/0xb0
[ 153.760966] ism_handle_irq+0x80/0x3f0 [ism]
[ 153.760974] __handle_irq_event_percpu+0x282/0x920
[ 153.760983] handle_irq_event_percpu+0x26/0xe0
[ 153.760989] handle_percpu_irq+0x10e/0x1a0
[ 153.760997] handle_irq_desc+0xa6/0x100
[ 153.761003] zpci_floating_irq_handler+0x3ca/0x610
[ 153.761011] do_airq_interrupt+0x206/0x500
[ 153.761018] __handle_irq_event_percpu+0x282/0x920
[ 153.761025] handle_irq_event_percpu+0x26/0xe0
[ 153.761031] handle_percpu_irq+0x10e/0x1a0
[ 153.761039] handle_irq_desc+0xa6/0x100
[ 153.761045] do_irq_async+0xec/0x150
[ 153.761052] do_io_irq+0x150/0x2e0
[ 153.761060] io_int_handler+0xec/0x118
[ 153.761066] arch_cpu_idle+0x120/0x130
[ 153.761118] arch_cpu_idle+0xbe/0x130
[ 153.761124] s390_enter_idle+0x20/0x30
[ 153.761131] cpuidle_enter_state+0xb6/0x440
[ 153.761138] cpuidle_enter+0x64/0xb0
[ 153.761144] cpuidle_idle_call+0x174/0x380
[ 153.761151] do_idle+0x16e/0x250
[ 153.761157] cpu_startup_entry+0x70/0x80
[ 153.761163] smp_start_secondary+0x36e/0x440
[ 153.761171] restart_int_handler+0x72/0x88
[ 153.761178] irq event stamp: 46536
[ 153.761182] hardirqs last enabled at (46536): [<000127b697450a90>] __local_bh_enable_ip+0x140/0x270
[ 153.761193] hardirqs last disabled at (46535): [<000127b697450b20>] __local_bh_enable_ip+0x1d0/0x270
[ 153.761202] softirqs last enabled at (46532): [<000127b6185f82c8>] smc_close_active+0x438/0xba0 [smc]
[ 153.761232] softirqs last disabled at (46534): [<000127b6185ee998>] smc_cdc_get_slot_and_msg_send+0x218/0x370 [smc]
[ 153.761257]
other info that might help us debug this:
[ 153.761262] Possible unsafe locking scenario:
[ 153.761267] CPU0
[ 153.761271] ----
[ 153.761274] lock(&dibs->lock);
[ 153.761282] <Interrupt>
[ 153.761286] lock(&dibs->lock);
[ 153.761294]
*** DEADLOCK ***
[ 153.761299] locks held by python3/5134: 3, last CPU#1:
[ 153.761305] #0: 0001222bab975f50 (&sb->s_type->i_mutex_key#11){+.+.}-{3:3}, at: __sock_release+0x7e/0x230
[ 153.761329] #1: 0001222ba5450378 (sk_lock-AF_SMC){+.+.}-{0:0}, at: smc_close_active+0x438/0xba0 [smc]
[ 153.761360] #2: 0001222ba54508a0 (&smc->conn.send_lock){+...}-{2:2}, at: smc_cdc_get_slot_and_msg_send+0x218/0x370 [smc]
[ 153.761394]
stack backtrace:
[ 153.761400] CPU: 1 UID: 0 PID: 5134 Comm: python3 Not tainted 7.2.0-15871-g544d85de4dc2 #16 PREEMPT
[ 153.761406] Hardware name: IBM 3931 A01 703 (LPAR)
[ 153.761408] Call Trace:
[ 153.761409] [<000127b697366190>] dump_stack_lvl+0xe8/0x140
[ 153.761415] [<000127b6975ccc8c>] print_usage_bug.part.0+0x2ec/0x3a0
[ 153.761419] [<000127b6975cd454>] mark_lock_irq+0x714/0xa20
[ 153.761422] [<000127b6975cda52>] mark_lock+0x2f2/0x790
[ 153.761426] [<000127b6975ce2e6>] mark_usage+0x136/0x1c0
[ 153.761430] [<000127b6975ce90c>] __lock_acquire+0x59c/0x15d0
[ 153.761433] [<000127b6975cfa5c>] lock_acquire.part.0+0x11c/0x290
[ 153.761437] [<000127b6975cfc84>] lock_acquire+0xb4/0x1e0
[ 153.761441] [<000127b699d02a98>] _raw_spin_lock+0x58/0xb0
[ 153.761444] [<000127b6992ca4fe>] dibs_lo_move_data+0x1ce/0x380
[ 153.761449] [<000127b6185f0912>] smcd_tx_ism_write+0x182/0x250 [smc]
[ 153.761469] [<000127b6185ee4c6>] smcd_cdc_msg_send+0x156/0x410 [smc]
[ 153.761487] [<000127b6185ee9a2>] smc_cdc_get_slot_and_msg_send+0x222/0x370 [smc]
[ 153.761507] [<000127b6185f8370>] smc_close_active+0x4e0/0xba0 [smc]
[ 153.761526] [<000127b6185a293c>] __smc_release+0x4ac/0x6a0 [smc]
[ 153.761546] [<000127b6185a2c6e>] smc_release+0x13e/0x480 [smc]
[ 153.761565] [<000127b6994544d4>] __sock_release+0xa4/0x230
[ 153.761569] [<000127b69945468c>] sock_close+0x2c/0x40
[ 153.761573] [<000127b697e57180>] __fput+0x2f0/0x880
[ 153.761579] [<000127b697e58440>] fput_close_sync+0xd0/0x1c0
[ 153.761583] [<000127b697e4b3f0>] __s390x_sys_close+0x90/0xf0
[ 153.761586] [<000127b699cdc19e>] __do_syscall+0x1be/0x5a0
[ 153.761590] [<000127b699d04c7a>] system_call+0x72/0x90
[ 153.761594] INFO: lockdep is turned off.
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
---
drivers/dibs/dibs_loopback.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dibs/dibs_loopback.c b/drivers/dibs/dibs_loopback.c
index 649e4e375be3..44a2e74c2efc 100644
--- a/drivers/dibs/dibs_loopback.c
+++ b/drivers/dibs/dibs_loopback.c
@@ -238,6 +238,7 @@ static int dibs_lo_move_data(struct dibs_dev *dibs, u64 dmb_tok,
{
struct dibs_lo_dmb_node *rmb_node = NULL, *tmp_node;
struct dibs_lo_dev *ldev;
+ unsigned long flags;
u16 s_mask;
u8 client_id;
u32 sba_idx;
@@ -267,12 +268,12 @@ static int dibs_lo_move_data(struct dibs_dev *dibs, u64 dmb_tok,
if (!sf)
return 0;
- spin_lock(&dibs->lock);
+ spin_lock_irqsave(&dibs->lock, flags);
client_id = dibs->dmb_clientid_arr[sba_idx];
s_mask = ror16(0x1000, idx);
if (likely(client_id != NO_DIBS_CLIENT && dibs->subs[client_id]))
dibs->subs[client_id]->ops->handle_irq(dibs, sba_idx, s_mask);
- spin_unlock(&dibs->lock);
+ spin_unlock_irqrestore(&dibs->lock, flags);
return 0;
}
--
2.53.0
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()
2026-09-04 9:44 [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data() Alexandra Winter
@ 2026-09-05 0:42 ` Dust Li
2026-09-05 9:45 ` sashiko-bot
1 sibling, 0 replies; 3+ messages in thread
From: Dust Li @ 2026-09-05 0:42 UTC (permalink / raw)
To: Alexandra Winter, D. Wythe, Sidraya Jayagond, Mahanta Jambigi,
David Miller, Jakub Kicinski, Paolo Abeni, Eric Dumazet,
Andrew Lunn
Cc: Tony Lu, Wen Gu, netdev, linux-s390, linux-kernel, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Simon Horman
On 2026-09-04 11:44:46, Alexandra Winter wrote:
>dibs->lock is acquired in process context and interrupt context
>(ism_handle_irq()). So always use spin_lock_irqsave() in process context.
>
>Note that this is not a real deadlock, as dibs_lo devices don't have
>any interrupt context.
>
>Example warning:
>[ 153.760872] ================================
>[ 153.760878] WARNING: inconsistent lock state
>[ 153.760885] 7.2.0-15871-g544d85de4dc2 #16 Not tainted
>[ 153.760891] --------------------------------
>[ 153.760896] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
>[ 153.760901] python3/5134 [HC0[0]:SC0[2]:HE1:SE0] takes:
>[ 153.760909] 0001222c0fe72428 (&dibs->lock){?...}-{2:2}, at: dibs_lo_move_data+0x1ce/0x380
>[ 153.760932] {IN-HARDIRQ-W} state was registered at:
>[ 153.760937] __lock_acquire+0x59c/0x15d0
>[ 153.760947] lock_acquire.part.0+0x11c/0x290
>[ 153.760953] lock_acquire+0xb4/0x1e0
>[ 153.760959] _raw_spin_lock+0x58/0xb0
>[ 153.760966] ism_handle_irq+0x80/0x3f0 [ism]
>[ 153.760974] __handle_irq_event_percpu+0x282/0x920
>[ 153.760983] handle_irq_event_percpu+0x26/0xe0
>[ 153.760989] handle_percpu_irq+0x10e/0x1a0
>[ 153.760997] handle_irq_desc+0xa6/0x100
>[ 153.761003] zpci_floating_irq_handler+0x3ca/0x610
>[ 153.761011] do_airq_interrupt+0x206/0x500
>[ 153.761018] __handle_irq_event_percpu+0x282/0x920
>[ 153.761025] handle_irq_event_percpu+0x26/0xe0
>[ 153.761031] handle_percpu_irq+0x10e/0x1a0
>[ 153.761039] handle_irq_desc+0xa6/0x100
>[ 153.761045] do_irq_async+0xec/0x150
>[ 153.761052] do_io_irq+0x150/0x2e0
>[ 153.761060] io_int_handler+0xec/0x118
>[ 153.761066] arch_cpu_idle+0x120/0x130
>[ 153.761118] arch_cpu_idle+0xbe/0x130
>[ 153.761124] s390_enter_idle+0x20/0x30
>[ 153.761131] cpuidle_enter_state+0xb6/0x440
>[ 153.761138] cpuidle_enter+0x64/0xb0
>[ 153.761144] cpuidle_idle_call+0x174/0x380
>[ 153.761151] do_idle+0x16e/0x250
>[ 153.761157] cpu_startup_entry+0x70/0x80
>[ 153.761163] smp_start_secondary+0x36e/0x440
>[ 153.761171] restart_int_handler+0x72/0x88
>[ 153.761178] irq event stamp: 46536
>[ 153.761182] hardirqs last enabled at (46536): [<000127b697450a90>] __local_bh_enable_ip+0x140/0x270
>[ 153.761193] hardirqs last disabled at (46535): [<000127b697450b20>] __local_bh_enable_ip+0x1d0/0x270
>[ 153.761202] softirqs last enabled at (46532): [<000127b6185f82c8>] smc_close_active+0x438/0xba0 [smc]
>[ 153.761232] softirqs last disabled at (46534): [<000127b6185ee998>] smc_cdc_get_slot_and_msg_send+0x218/0x370 [smc]
>[ 153.761257]
> other info that might help us debug this:
>[ 153.761262] Possible unsafe locking scenario:
>
>[ 153.761267] CPU0
>[ 153.761271] ----
>[ 153.761274] lock(&dibs->lock);
>[ 153.761282] <Interrupt>
>[ 153.761286] lock(&dibs->lock);
>[ 153.761294]
> *** DEADLOCK ***
>
>[ 153.761299] locks held by python3/5134: 3, last CPU#1:
>[ 153.761305] #0: 0001222bab975f50 (&sb->s_type->i_mutex_key#11){+.+.}-{3:3}, at: __sock_release+0x7e/0x230
>[ 153.761329] #1: 0001222ba5450378 (sk_lock-AF_SMC){+.+.}-{0:0}, at: smc_close_active+0x438/0xba0 [smc]
>[ 153.761360] #2: 0001222ba54508a0 (&smc->conn.send_lock){+...}-{2:2}, at: smc_cdc_get_slot_and_msg_send+0x218/0x370 [smc]
>[ 153.761394]
> stack backtrace:
>[ 153.761400] CPU: 1 UID: 0 PID: 5134 Comm: python3 Not tainted 7.2.0-15871-g544d85de4dc2 #16 PREEMPT
>[ 153.761406] Hardware name: IBM 3931 A01 703 (LPAR)
>[ 153.761408] Call Trace:
>[ 153.761409] [<000127b697366190>] dump_stack_lvl+0xe8/0x140
>[ 153.761415] [<000127b6975ccc8c>] print_usage_bug.part.0+0x2ec/0x3a0
>[ 153.761419] [<000127b6975cd454>] mark_lock_irq+0x714/0xa20
>[ 153.761422] [<000127b6975cda52>] mark_lock+0x2f2/0x790
>[ 153.761426] [<000127b6975ce2e6>] mark_usage+0x136/0x1c0
>[ 153.761430] [<000127b6975ce90c>] __lock_acquire+0x59c/0x15d0
>[ 153.761433] [<000127b6975cfa5c>] lock_acquire.part.0+0x11c/0x290
>[ 153.761437] [<000127b6975cfc84>] lock_acquire+0xb4/0x1e0
>[ 153.761441] [<000127b699d02a98>] _raw_spin_lock+0x58/0xb0
>[ 153.761444] [<000127b6992ca4fe>] dibs_lo_move_data+0x1ce/0x380
>[ 153.761449] [<000127b6185f0912>] smcd_tx_ism_write+0x182/0x250 [smc]
>[ 153.761469] [<000127b6185ee4c6>] smcd_cdc_msg_send+0x156/0x410 [smc]
>[ 153.761487] [<000127b6185ee9a2>] smc_cdc_get_slot_and_msg_send+0x222/0x370 [smc]
>[ 153.761507] [<000127b6185f8370>] smc_close_active+0x4e0/0xba0 [smc]
>[ 153.761526] [<000127b6185a293c>] __smc_release+0x4ac/0x6a0 [smc]
>[ 153.761546] [<000127b6185a2c6e>] smc_release+0x13e/0x480 [smc]
>[ 153.761565] [<000127b6994544d4>] __sock_release+0xa4/0x230
>[ 153.761569] [<000127b69945468c>] sock_close+0x2c/0x40
>[ 153.761573] [<000127b697e57180>] __fput+0x2f0/0x880
>[ 153.761579] [<000127b697e58440>] fput_close_sync+0xd0/0x1c0
>[ 153.761583] [<000127b697e4b3f0>] __s390x_sys_close+0x90/0xf0
>[ 153.761586] [<000127b699cdc19e>] __do_syscall+0x1be/0x5a0
>[ 153.761590] [<000127b699d04c7a>] system_call+0x72/0x90
>[ 153.761594] INFO: lockdep is turned off.
>
>Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Dust Li <dust.li@linux.alibaba.com>
Best regards,
Dust
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()
2026-09-04 9:44 [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data() Alexandra Winter
2026-09-05 0:42 ` Dust Li
@ 2026-09-05 9:45 ` sashiko-bot
1 sibling, 0 replies; 3+ messages in thread
From: sashiko-bot @ 2026-09-05 9:45 UTC (permalink / raw)
To: Alexandra Winter
Cc: Alexander Gordeev, Heiko Carstens, linux-s390, Vasily Gorbik,
Christian Borntraeger
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Unsafe error path calling kfree() on memory allocated via folio_alloc().
--
commit 71f881ca9b5f87a2235598ada197106f8482dccb
Author: Alexandra Winter <wintera@linux.ibm.com>
dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()
dibs->lock is acquired in process context and interrupt context
(ism_handle_irq()). So always use spin_lock_irqsave() in process context.
Note that this is not a real deadlock, as dibs_lo devices don't have
any interrupt context.
[ ... ]
> diff --git a/drivers/dibs/dibs_loopback.c b/drivers/dibs/dibs_loopback.c
> index 649e4e375be33..44a2e74c2efcb 100644
> --- a/drivers/dibs/dibs_loopback.c
> +++ b/drivers/dibs/dibs_loopback.c
[ ... ]
While reviewing this commit, I noticed a pre-existing issue in the related
ism_alloc_dmb() function:
drivers/s390/net/ism_drv.c:ism_alloc_dmb() {
[ ... ]
folio = folio_alloc(GFP_KERNEL | __GFP_NOWARN | __GFP_NOMEMALLOC |
__GFP_NORETRY, get_order(dmb->dmb_len));
if (!folio) {
rc = -ENOMEM;
goto out_bit;
}
dmb->cpu_addr = folio_address(folio);
dmb->dma_addr = dma_map_page(&ism->pdev->dev,
virt_to_page(dmb->cpu_addr), 0,
dmb->dmb_len, DMA_FROM_DEVICE);
if (dma_mapping_error(&ism->pdev->dev, dmb->dma_addr)) {
rc = -ENOMEM;
goto out_free;
}
return 0;
out_free:
kfree(dmb->cpu_addr);
[ ... ]
}
[Severity: High]
This is a pre-existing issue, but does calling kfree() on memory directly
allocated by folio_alloc() cause a kernel panic due to invalid slab metadata?
When dma_map_page() fails, the execution jumps to the out_free label, which
incorrectly calls kfree(dmb->cpu_addr) instead of using folio_put() as seen
in ism_free_dmb().
If a user exhausts DMA mapping space (e.g., filling up the IOMMU or exhausting
bounce buffers), could this error path be triggered resulting in a denial of
service?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904094446.1342654-1-wintera@linux.ibm.com?part=1
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-09-05 9:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-04 9:44 [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data() Alexandra Winter
2026-09-05 0:42 ` Dust Li
2026-09-05 9:45 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox