All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandra Winter <wintera@linux.ibm.com>
To: "D. Wythe" <alibuda@linux.alibaba.com>,
	Dust Li <dust.li@linux.alibaba.com>,
	Sidraya Jayagond <sidraya@linux.ibm.com>,
	Mahanta Jambigi <mjambigi@linux.ibm.com>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Eric Dumazet <edumazet@google.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>
Cc: Tony Lu <tonylu@linux.alibaba.com>,
	Wen Gu <guwen@linux.alibaba.com>,
	netdev@vger.kernel.org, linux-s390@vger.kernel.org,
	linux-kernel@vger.kernel.org, Heiko Carstens <hca@linux.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Alexander Gordeev <agordeev@linux.ibm.com>,
	Christian Borntraeger <borntraeger@linux.ibm.com>,
	Sven Schnelle <svens@linux.ibm.com>,
	Simon Horman <horms@kernel.org>
Subject: [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data()
Date: Fri,  4 Sep 2026 11:44:46 +0200	[thread overview]
Message-ID: <20260904094446.1342654-1-wintera@linux.ibm.com> (raw)

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


             reply	other threads:[~2026-09-04  9:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04  9:44 Alexandra Winter [this message]
2026-09-05  0:42 ` [PATCH net-next] dibs: Avoid inconsistent lockstate warning in dibs_lo_move_data() Dust Li
2026-09-05  9:45 ` sashiko-bot
2026-09-08  9:55   ` Alexandra Winter
2026-09-07  6:26 ` Sidraya Jayagond
2026-09-08 12:45 ` netdev-bot+sashiko
2026-09-08 17:04   ` Alexandra Winter
2026-09-09  8:04     ` Paolo Abeni
2026-09-08 13:10 ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260904094446.1342654-1-wintera@linux.ibm.com \
    --to=wintera@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=alibuda@linux.alibaba.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=borntraeger@linux.ibm.com \
    --cc=davem@davemloft.net \
    --cc=dust.li@linux.alibaba.com \
    --cc=edumazet@google.com \
    --cc=gor@linux.ibm.com \
    --cc=guwen@linux.alibaba.com \
    --cc=hca@linux.ibm.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=mjambigi@linux.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sidraya@linux.ibm.com \
    --cc=svens@linux.ibm.com \
    --cc=tonylu@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.