[PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[Alexandra Winter]

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

Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[Dust Li]

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

Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[sashiko-bot]

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

Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[Sidraya Jayagond]

On 04/09/26 3:14 pm, 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>
> ---
>  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;
>  }
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>

Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[Alexandra Winter]

On 05.09.26 11:45, sashiko-bot@kernel.org wrote:
> 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?
> 

Fix for this is is already in netdev:
 https://git.kernel.org/netdev/net/c/907a56ab3eb8

Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 1 · Low: 0

- [Medium] The patch fixes an observable lockdep "inconsistent lock
  state" splat produced by the plain spin_lock(&dibs->lock) in…

--

Here is the report.

dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

This converts the plain spin_lock()/spin_unlock() around the
dibs->subs[]->ops->handle_irq() call in dibs_lo_move_data() to
spin_lock_irqsave()/spin_unlock_irqrestore(), because the same lock is
also taken from hardirq context in ism_handle_irq().  The commit message
notes this is not a real deadlock since dibs_lo devices have no 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

[ ... ]

> @@ -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);

[Severity: Medium]
Should this carry a Fixes: tag?  The lockdep splat quoted in the commit
message is reproducible on shipped kernels, and git blame attributes the
converted spin_lock()/spin_unlock() pair in dibs_lo_move_data() to:

cc21191b584c6f ("dibs: Move data path to dibs layer")

The hardirq-side acquisition of the same lock is in ism_handle_irq()
(drivers/s390/net/ism_drv.c):

	spin_lock(&dibs->lock);

which matches the {IN-HARDIRQ-W} registration in the report, so the
warning can be hit by ordinary SMC traffic through
smc_close_active()->smcd_cdc_msg_send()->smcd_tx_ism_write()->dibs_lo_move_data()
on a lockdep-enabled kernel.

The splat also ends with "INFO: lockdep is turned off", so further lock
checking is lost for the rest of that boot on affected kernels.

Would adding the following help backporters and stable tooling identify
which trees need this change?

Fixes: cc21191b584c6f ("dibs: Move data path to dibs layer")

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260904094446.1342654-1-wintera%40linux.ibm.com

Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:

On Fri,  4 Sep 2026 11:44:46 +0200 you 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:
> 
> [...]

Here is the summary with links:
  - [net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()
    https://git.kernel.org/netdev/net-next/c/73db35350c5e

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[Alexandra Winter]

On 08.09.26 14:45, netdev-bot+sashiko@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> 
> Critical: 0 · High: 0 · Medium: 1 · Low: 0
> 
> - [Medium] The patch fixes an observable lockdep "inconsistent lock
>   state" splat produced by the plain spin_lock(&dibs->lock) in…
> 
> --
> 
> Here is the report.
> 
> dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()
> 
> This converts the plain spin_lock()/spin_unlock() around the
> dibs->subs[]->ops->handle_irq() call in dibs_lo_move_data() to
> spin_lock_irqsave()/spin_unlock_irqrestore(), because the same lock is
> also taken from hardirq context in ism_handle_irq().  The commit message
> notes this is not a real deadlock since dibs_lo devices have no 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
> 
> [ ... ]
> 
>> @@ -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);
> 
> [Severity: Medium]
> Should this carry a Fixes: tag?  The lockdep splat quoted in the commit
> message is reproducible on shipped kernels, and git blame attributes the
> converted spin_lock()/spin_unlock() pair in dibs_lo_move_data() to:
> 
> cc21191b584c6f ("dibs: Move data path to dibs layer")
> 
> The hardirq-side acquisition of the same lock is in ism_handle_irq()
> (drivers/s390/net/ism_drv.c):
> 
> 	spin_lock(&dibs->lock);
> 
> which matches the {IN-HARDIRQ-W} registration in the report, so the
> warning can be hit by ordinary SMC traffic through
> smc_close_active()->smcd_cdc_msg_send()->smcd_tx_ism_write()->dibs_lo_move_data()
> on a lockdep-enabled kernel.
> 
> The splat also ends with "INFO: lockdep is turned off", so further lock
> checking is lost for the rest of that boot on affected kernels.
> 
> Would adding the following help backporters and stable tooling identify
> which trees need this change?
> 
> Fixes: cc21191b584c6f ("dibs: Move data path to dibs layer")
> 


As mentioned in the commit message the paths reported by lockdep belong to two
different device types (dibs-lo and ism). So not a real deadlock.
So unless lockdep-warnings by themselves warrant a Fixes-tag (?), I think net-next is correct here.

Paolo applied this already to net-next.
For the records: Sahiko identified the right patch to blame.

Re: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()

[Paolo Abeni]

On 9/8/26 7:04 PM, Alexandra Winter wrote:
> On 08.09.26 14:45, netdev-bot+sashiko@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 1 potential
>> issue(s) to consider:
>>
>> Critical: 0 · High: 0 · Medium: 1 · Low: 0
>>
>> - [Medium] The patch fixes an observable lockdep "inconsistent lock
>>   state" splat produced by the plain spin_lock(&dibs->lock) in…
>>
>> --
>>
>> Here is the report.
>>
>> dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()
>>
>> This converts the plain spin_lock()/spin_unlock() around the
>> dibs->subs[]->ops->handle_irq() call in dibs_lo_move_data() to
>> spin_lock_irqsave()/spin_unlock_irqrestore(), because the same lock is
>> also taken from hardirq context in ism_handle_irq().  The commit message
>> notes this is not a real deadlock since dibs_lo devices have no 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
>>
>> [ ... ]
>>
>>> @@ -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);
>>
>> [Severity: Medium]
>> Should this carry a Fixes: tag?  The lockdep splat quoted in the commit
>> message is reproducible on shipped kernels, and git blame attributes the
>> converted spin_lock()/spin_unlock() pair in dibs_lo_move_data() to:
>>
>> cc21191b584c6f ("dibs: Move data path to dibs layer")
>>
>> The hardirq-side acquisition of the same lock is in ism_handle_irq()
>> (drivers/s390/net/ism_drv.c):
>>
>> 	spin_lock(&dibs->lock);
>>
>> which matches the {IN-HARDIRQ-W} registration in the report, so the
>> warning can be hit by ordinary SMC traffic through
>> smc_close_active()->smcd_cdc_msg_send()->smcd_tx_ism_write()->dibs_lo_move_data()
>> on a lockdep-enabled kernel.
>>
>> The splat also ends with "INFO: lockdep is turned off", so further lock
>> checking is lost for the rest of that boot on affected kernels.
>>
>> Would adding the following help backporters and stable tooling identify
>> which trees need this change?
>>
>> Fixes: cc21191b584c6f ("dibs: Move data path to dibs layer")
>>
> 
> 
> As mentioned in the commit message the paths reported by lockdep belong to two
> different device types (dibs-lo and ism). So not a real deadlock.
> So unless lockdep-warnings by themselves warrant a Fixes-tag (?), I think net-next is correct here.
> 
> Paolo applied this already to net-next.
> For the records: Sahiko identified the right patch to blame.
The current guidance is no fixes tag for net-next patches address old
'issues'. Since this is a false positive, I deemed it as a 'non issue',
hence I agreed with the net-next target (and thus no fixes tag).

/P