drivers/dibs/dibs_loopback.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
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.0Thank 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
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.
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
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>
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
© 2016 - 2026 Red Hat, Inc.