From nobody Fri Oct 2 05:31:04 2026 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C54153C4557 for ; Wed, 5 Aug 2026 03:09:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.51 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785899396; cv=none; b=HKGef22tEpQmH0BaqgAOXvwMRjS1SgP7Zz3+q/H1QLuxgm/D8/Ps1AJk+fg9tnJ1ZQENL3nOxO0V4vFReIcJ9KqUeO2IFOzlB0AyiPB9gMYF/y60aBDOwYd4R8MtTlvqKIfH/KQh7r8MZk5dYJq4wGhjUYPNq1TGij8Csv7mH84= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785899396; c=relaxed/simple; bh=C/woTRWmGUonXtCdsEp+mRp7+8ZFj9uoVoZRMKxOzn8=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=O0NCIMCMZAlZG+6TCC6MNFrYgXuDl0qdBPvSvw/MKLKwCvyGQzkRbxee1lDd3WTzkXQP2+bNLw27qXWsLPdzg5rG9O32bYWtOWxqi/tRxDzsDi7YEENnJyjZHF+es9v+9leszzUBinqzQ5sMvaJC16me7lKxZZD6L9Q05LsBGLo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=evkqbPmC; arc=none smtp.client-ip=209.85.216.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="evkqbPmC" Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-38f0f132f56so1296675a91.0 for ; Tue, 04 Aug 2026 20:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785899393; x=1786504193; darn=vger.kernel.org; h=cc:to:message-id:content-transfer-encoding:content-type :mime-version:subject:date:from:from:to:cc:subject:date:message-id :reply-to:content-type; bh=l+BRPIV4ca41fzTyiQodU57f74PmSZTMdFIXc0/UZDc=; b=evkqbPmCU/w86Iid2p8p+/PlebTWFx4wbD8dr6ZLvT1vPy+va4IXDhK8mwayY1vkkw CJaEr12NSN5hmMKJpr4QtHfLgWTHL4SnA8lWeE8z7UlP14cx1pI2bwHz1yDE4lls2uVT GUPVYEqs22ZHdFGVYsXimYYx0q+LiDFvB+VprmQQPNcVlSxv0kA6tbnTEgR8l2EjX34c 5nPSeYKwMsG6VGGqoMPrkRLIFy0maUfXtp1Nf5baAz0C+sM9SwKC/2dQOF/GQz6l8dtu 10VhX6dw3GwMD92BgnWARzJJlIPx4R87/kVJsfglPupnW+LO0CV4ffnjUUxJmhG1TCCK b58Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785899393; x=1786504193; h=cc:to:message-id:content-transfer-encoding:content-type :mime-version:subject:date:from:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to:content-type; bh=l+BRPIV4ca41fzTyiQodU57f74PmSZTMdFIXc0/UZDc=; b=V34IA41vmhdw2937FSU5sdPzo2Mns3by2ximVO7SJeEmGCjVonRm74iHyyMt3Xb0kT obic02+xJisOeSb8o7o5bMc0DLlk+mhtCNOB/lg/PhEpjuHZglujdnY6sYfsI9fsF2Q1 g6YXn9gNP5l20+Q8IB1dlnNnk8/gRDmg0yt+pzmZoPI++Erdmrd7zuXkLyjvVv4qQAHe 7DqoNz/Y8vIkUTAWYoEPZzu4PtTwSBchVVHwU8KCKVNfv+zxPdpKjUQLls7HdkJry9ha WFGd/flZsMbXhcaE1UZPlxkEJIL9nrnwxjygSOYpLAi9WikMf3+jlWPICX8+Osf1DEjq IJUw== X-Forwarded-Encrypted: i=1; AHgh+RoshgsHdj0L/hXGRD9G/qLZ69OsUZKSG8VuoJ1+ShFWYJuJp5tDo0nUtaD+mS2zDKBt7mPm7WHfCjNvTxg=@vger.kernel.org X-Gm-Message-State: AOJu0Yy50JV3bh4gsDPf0QMLYVsyDPZww6nd+ie8SCWwIE2xgDlBrARI MgoPkqabtNyhJMUntwVhW1xx9/jvMkiZvHE5GwMxhQs1d+hyv2PZPRH6 X-Gm-Gg: AR+sD10vdh6nQVGcQtCVsivStMIS7BnS1FIvSDSL1ccDgTCeiDGgL4R1fqEtUO4SBNA EKaf/8lsYeqw20nyg1gm/aKfOp2xWJOlIy+2RVwArZ5hh5YbSkCQoAfSZ16ybNNvDDBhALiIsCS fKPu0iSkcBRJHTiSZ9rYnSk5Y5FkGcUVSHgyZQVQN16btf2ftjlGk5+hpwXHaEdNWYhSmZ1IFHU eO5kDn8DaLjTX+HkfD+2brV9yNRpjKSgfx0G8xBSpIrXnyCbY16IAqbkf32y1spV1mAL1+PIiqz yG7r3/CMqy+6FX7LPJdLSoHH5P2iNSolNgTkqD55qdPtZMSDM1chBYq76YMEgEtRU/eFUJzEPOy /GS77Y72Fz3vPZstkcR/LVyqxPmQxnyKXnS6/8N4nXNW6Jn+YcKA4SrJmNsHqNQkqXljZPccWCN llOilx/YzEEJtNSfVnM5KOhPLRR4f/uUvchcBr8yMt5PvijW5BUpkYjl4ADTtYJNs0iKQBwA== X-Received: by 2002:a17:90b:1652:b0:38e:7f22:f674 with SMTP id 98e67ed59e1d1-3903c628796mr1489226a91.11.1785899392717; Tue, 04 Aug 2026 20:09:52 -0700 (PDT) Received: from [192.168.110.119] ([203.175.12.242]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3903f5fdfe5sm667822a91.4.2026.08.04.20.09.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Aug 2026 20:09:51 -0700 (PDT) From: Hangbin Liu Date: Wed, 05 Aug 2026 11:09:41 +0800 Subject: [PATCH net] hsr: Avoid holding seqnr_lock while transmitting packets Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260805-hsr_deadlock-v1-1-d8a6f06fc5a8@kylinos.cn> X-B4-Tracking: v=1; b=H4sIAAAAAAAC/x3MQQqAIBBA0avErBOmsoiuEhGmUw6FhUYE4t2Tl m/xf4RAninAUETw9HDg02VUZQHaKreRYJMNNdYd9iiFDX42pMxx6l1IXI3EpemqVkJOLk8rv/9 uBEc3TCl9/w7OtWMAAAA= X-Change-ID: 20260804-hsr_deadlock-40fd40b36154 To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Sebastian Andrzej Siewior , Lukasz Majewski Cc: Felix Maurer , Hangbin Liu , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Hangbin Liu , syzbot+fbf74291c3b7e753b481@syzkaller.appspotmail.com X-Mailer: b4 0.14.3 From: Hangbin Liu Commit 06afd2c31d33 ("hsr: Synchronize sending frames to have always incremented outgoing seq nr.") added spin lock around the whole hsr_forward_skb() path to synchronize outgoing sequence number handling. Commit 430d67bdcb04 ("net: hsr: Use the seqnr lock for frames received via interlink port.") also use the same approach. However, holding seqnr_lock while transmitting packets can cause lock dependency issues when HSR devices are stacked with other net devices. For example, when an HSR device is enslaved to a bridge and the bridge is enslaved to another HSR device, hsr_dev_xmit() can be called recursively through the networking stack. Although the two seqnr_lock instances are different in this case, the same lock class can trigger a lockdep warning, and more complex stacking topologies could lead to a real deadlock. Since commit aae9d6b616b5 ("hsr: Implement more robust duplicate discard for HSR"), sequence numbers are stored in an array and no longer require linear comparison. Protecting only the sequence number update is sufficient. There is no need to hold seqnr_lock during the whole forwarding operation. Revert commit 06afd2c31d33 ("hsr: Synchronize sending frames to have always incremented outgoing seq nr.") and commit 430d67bdcb04 ("net: hsr: Use the seqnr lock for frames received via interlink port.") to avoid holding seqnr_lock while transmitting packets. Fixes: 06afd2c31d33 ("hsr: Synchronize sending frames to have always increm= ented outgoing seq nr.") Fixes: 430d67bdcb04 ("net: hsr: Use the seqnr lock for frames received via = interlink port.") Reported-by: syzbot+fbf74291c3b7e753b481@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=3Dfbf74291c3b7e753b481 Signed-off-by: Hangbin Liu --- I'm not sure if I should add these 2 fixes as this patch is depend on Felix's aae9d6b616b5 ("hsr: Implement more robust duplicate discard for HSR"). Please correct me if I need a change. --- net/hsr/hsr_device.c | 12 +++++------- net/hsr/hsr_forward.c | 3 ++- net/hsr/hsr_slave.c | 11 +---------- 3 files changed, 8 insertions(+), 18 deletions(-) diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c index 5555b71ab19b..14e8d0676229 100644 --- a/net/hsr/hsr_device.c +++ b/net/hsr/hsr_device.c @@ -232,9 +232,7 @@ static netdev_tx_t hsr_dev_xmit(struct sk_buff *skb, st= ruct net_device *dev) skb->dev =3D master->dev; skb_reset_mac_header(skb); skb_reset_mac_len(skb); - spin_lock_bh(&hsr->seqnr_lock); hsr_forward_skb(skb, master); - spin_unlock_bh(&hsr->seqnr_lock); } else { dev_core_stats_tx_dropped_inc(dev); dev_kfree_skb_any(skb); @@ -335,6 +333,7 @@ static void send_hsr_supervision_frame(struct hsr_port = *port, hsr_stag->sequence_nr =3D htons(hsr->sequence_nr); hsr->sequence_nr++; } + spin_unlock_bh(&hsr->seqnr_lock); =20 hsr_stag->tlv.HSR_TLV_type =3D type; /* HSRv0 has 6 unused bytes after the MAC */ @@ -356,13 +355,11 @@ static void send_hsr_supervision_frame(struct hsr_por= t *port, ether_addr_copy(hsr_sp->macaddress_A, hsr->macaddress_redbox); } =20 - if (skb_put_padto(skb, ETH_ZLEN)) { - spin_unlock_bh(&hsr->seqnr_lock); + if (skb_put_padto(skb, ETH_ZLEN)) return; - } =20 hsr_forward_skb(skb, port); - spin_unlock_bh(&hsr->seqnr_lock); + return; } =20 @@ -402,8 +399,9 @@ static void send_prp_supervision_frame(struct hsr_port = *master, return; } =20 - hsr_forward_skb(skb, master); spin_unlock_bh(&hsr->seqnr_lock); + + hsr_forward_skb(skb, master); } =20 /* Announce (supervision frame) timer function diff --git a/net/hsr/hsr_forward.c b/net/hsr/hsr_forward.c index 0774981a65c1..8e4158a9b57c 100644 --- a/net/hsr/hsr_forward.c +++ b/net/hsr/hsr_forward.c @@ -621,9 +621,10 @@ static void handle_std_frame(struct sk_buff *skb, if (port->type =3D=3D HSR_PT_MASTER || port->type =3D=3D HSR_PT_INTERLINK) { /* Sequence nr for the master/interlink node */ - lockdep_assert_held(&hsr->seqnr_lock); + spin_lock_bh(&hsr->seqnr_lock); frame->sequence_nr =3D hsr->sequence_nr; hsr->sequence_nr++; + spin_unlock_bh(&hsr->seqnr_lock); } } =20 diff --git a/net/hsr/hsr_slave.c b/net/hsr/hsr_slave.c index 01c73b4b50dd..267ffbd3c838 100644 --- a/net/hsr/hsr_slave.c +++ b/net/hsr/hsr_slave.c @@ -73,16 +73,7 @@ static rx_handler_result_t hsr_handle_frame(struct sk_bu= ff **pskb) } skb_reset_mac_len(skb); =20 - /* Only the frames received over the interlink port will assign a - * sequence number and require synchronisation vs other sender. - */ - if (port->type =3D=3D HSR_PT_INTERLINK) { - spin_lock_bh(&hsr->seqnr_lock); - hsr_forward_skb(skb, port); - spin_unlock_bh(&hsr->seqnr_lock); - } else { - hsr_forward_skb(skb, port); - } + hsr_forward_skb(skb, port); =20 finish_consume: return RX_HANDLER_CONSUMED; --- base-commit: 2a33516f9ef59ad11844d4fc152f889449b5daf3 change-id: 20260804-hsr_deadlock-40fd40b36154 Best regards, --=20 Hangbin Liu