Linux s390 Architecture development
 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: 2+ 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

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox