From: Tom Herbert To: davem@davemloft.net, kuba@kernel.org, jesse.brandeburg@intel.com, anthony.l.nguyen@intel.com, cai.huoqing@linux.dev, netdev@vger.kernel.org, felipe@sipanda.io Cc: Tom Herbert Subject: [RFC net-next 00/10] crc-offload: Split RX CRC offload from csum offload Date: Wed, 3 Jul 2024 15:48:40 -0700 Message-Id: <20240703224850.1226697-1-tom@herbertland.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.netdev:355603 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail In this patch set we create csum_valid_crc32 flag in the skbuff. This is used by drivers to report a valid offloaded CRC, in lieu of setting CHECKSUM_UNNECESSARY. The benefits of this are: 1) It's compatible with checksum-complete. We can do checksum- complete with a validate CRC at the same time 2) Checksum-unnecessary conversion may erase the indication of the offloaded CRC. For instance in a SCTP/UDP packet where the driver reports both the non-zero UDP checksum and the CRC have been validate (i.e. csum_level is set to 1), then checksum- complete conversion erases the indication and the host has to compute the CRC again 3) It just seems awkward in general to be mixing fundamentally different verifications, and wouldn't be surprising if there are more bugs lurking in this area Additionally, some helper functions are added: - skb_csum_crc32_unnecessary - skb_reset_csum_crc32_unnecessary - skb_set_csum_crc32_unnecessary Changed FCOE and SCTP input to call skb_csum_crc32_unnecessary and skb_reset_csum_crc32_unnecessary Call the helper function skb_set_csum_crc32_unnecessary from drivers instead of setting CHECKSUM_UNNECESSARY. This includes cavium thunder, gve, hisilicon, hns3, idpf, ixgbe, wangxun. If I missed any please let me know. The change was fairly simple, just need to identify that the SCTP or FCOE CRC was validated and call the function. Tom Herbert (10): skbuff: Rename csum_not_inet to csum_is_crc32 skbuff: Add csum_valid_crc32 flag sctp: Call skb_csum_crc32_unnecessary fcoe: Call skb_csum_crc32_unnecessary cavium_thunder: Call skb_set_csum_crc32_unnecessary gve: Call skb_set_csum_crc32_unnecessary hisilicon: Call skb_set_csum_crc32_unnecessary idpf: Call skb_set_csum_crc32_unnecessary ixgbe: Call skb_set_csum_crc32_unnecessary wangxun: Call skb_set_csum_crc32_unnecessary .../net/ethernet/cavium/thunder/nicvf_main.c | 5 +- drivers/net/ethernet/google/gve/gve_rx_dqo.c | 4 +- drivers/net/ethernet/hisilicon/hns/hns_enet.c | 5 +- .../net/ethernet/hisilicon/hns3/hns3_enet.c | 18 ++++-- .../ethernet/intel/idpf/idpf_singleq_txrx.c | 4 +- drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 2 +- drivers/net/ethernet/wangxun/libwx/wx_lib.c | 5 +- drivers/scsi/fcoe/fcoe.c | 6 +- include/linux/skbuff.h | 58 +++++++++++++++---- net/core/dev.c | 2 +- net/sched/act_csum.c | 2 +- net/sctp/input.c | 6 +- net/sctp/offload.c | 2 +- net/sctp/output.c | 2 +- 15 files changed, 89 insertions(+), 34 deletions(-) -- 2.34.1 . From: Kuniyuki Iwashima To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , David Ahern CC: Lawrence Brakmo , Kuniyuki Iwashima , Kuniyuki Iwashima , Subject: [PATCH v1 net] tcp: Don't drop SYN+ACK for simultaneous connect(). Date: Wed, 3 Jul 2024 20:57:03 -0700 Message-ID: <20240704035703.95065-1-kuniyu@amazon.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain Xref: photonic.trudheim.com org.kernel.vger.netdev:355616 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail RFC 9293 states that in the case of simultaneous connect(), the connection gets established when SYN+ACK is received. [0] TCP Peer A TCP Peer B 1. CLOSED CLOSED 2. SYN-SENT --> ... 3. SYN-RECEIVED <-- <-- SYN-SENT 4. ... --> SYN-RECEIVED 5. SYN-RECEIVED --> ... 6. ESTABLISHED <-- <-- SYN-RECEIVED 7. ... --> ESTABLISHED However, since commit 0c24604b68fc ("tcp: implement RFC 5961 4.2"), such a SYN+ACK is dropped in tcp_validate_incoming() and responded with Challenge ACK. For example, the write() syscall in the following packetdrill script fails with -EAGAIN, and wrong SNMP stats get incremented. 0 socket(..., SOCK_STREAM|SOCK_NONBLOCK, IPPROTO_TCP) = 3 +0 connect(3, ..., ...) = -1 EINPROGRESS (Operation now in progress) +0 > S 0:0(0) +0 < S 0:0(0) win 1000 +0 > S. 0:0(0) ack 1 +0 < S. 0:0(0) ack 1 win 1000 +0 write(3, ..., 100) = 100 +0 > P. 1:101(100) ack 1 -- # packetdrill cross-synack.pkt cross-synack.pkt:13: runtime error in write call: Expected result 100 but got -1 with errno 11 (Resource temporarily unavailable) # nstat ... TcpExtTCPChallengeACK 1 0.0 TcpExtTCPSYNChallenge 1 0.0 That said, this is no big deal because the Challenge ACK finally let the connection state transition to TCP_ESTABLISHED in both directions. If the peer is not using Linux, there might be a small latency before ACK though. The problem is that bpf_skops_established() is triggered by the Challenge ACK instead of SYN+ACK. This causes the bpf prog to miss the chance to check if the peer supports a TCP option that is expected to be exchanged in SYN and SYN+ACK. Let's accept a bare SYN+ACK for non-TFO TCP_SYN_RECV sockets to avoid such a situation. Link: https://www.rfc-editor.org/rfc/rfc9293.html#section-3.5-7 [0] Fixes: 9872a4bde31b ("bpf: Add TCP connection BPF callbacks") Signed-off-by: Kuniyuki Iwashima --- net/ipv4/tcp_input.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index 77294fd5fd3e..70595009bb58 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -5980,6 +5980,11 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb, * RFC 5961 4.2 : Send a challenge ack */ if (th->syn) { + if (sk->sk_state == TCP_SYN_RECV && !tp->syn_fastopen && th->ack && + TCP_SKB_CB(skb)->seq + 1 == TCP_SKB_CB(skb)->end_seq && + TCP_SKB_CB(skb)->seq + 1 == tp->rcv_nxt && + TCP_SKB_CB(skb)->ack_seq == tp->snd_nxt) + goto pass; syn_challenge: if (syn_inerr) TCP_INC_STATS(sock_net(sk), TCP_MIB_INERRS); @@ -5990,7 +5995,7 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb, } bpf_skops_parse_hdr(sk, skb); - +pass: return true; discard: -- 2.30.2 . From: Kory Maincent Subject: [PATCH net-next v6 0/7] net: pse-pd: Add new PSE c33 features Date: Thu, 04 Jul 2024 10:11:55 +0200 Message-Id: <20240704-feature_poe_power_cap-v6-0-320003204264@bootlin.com> 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: 8bit To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Donald Hunter , Oleksij Rempel , Jonathan Corbet Cc: Thomas Petazzoni , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Dent Project , kernel@pengutronix.de, linux-doc@vger.kernel.org, Kory Maincent , Sai Krishna Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1267621 org.kernel.vger.netdev:355619 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.linux-doc,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail From: Kory Maincent (Dent Project) This patch series adds new c33 features to the PSE API. - Expand the PSE PI informations status with power, class and failure reason - Add the possibility to get and set the PSE PIs power limit Changes in v6: - Rebase on top of net-next - Link to v5: https://lore.kernel.org/r/20240628-feature_poe_power_cap-v5-0-5e1375d3817a@bootlin.com Changes in v5: - Fix few nitpick. - Link to v4: https://lore.kernel.org/r/20240625-feature_poe_power_cap-v4-0-b0813aad57d5@bootlin.com Changes in v4: - Made few update in PSE extended state an substate. - Add support for c33 pse power limit ranges. - Few changes in the specs and the documentation. - Link to v3: https://lore.kernel.org/r/20240614-feature_poe_power_cap-v3-0-a26784e78311@bootlin.com Changes in v3: - Use u32 instead of u8 size for c33 pse extended state and substate. - Reformat the state and substate enumeration to follow Oleksij proposal which is more IEEE 802.3 standard compliant - Sent the first patch standalone in net. - Link to v2: https://lore.kernel.org/r/20240607-feature_poe_power_cap-v2-0-c03c2deb83ab@bootlin.com Changes in v2: - Use uA and uV instead of mA and mV to have more precision in the power calculation. Need to use 64bit variables for the calculation. - Modify the pd-92x0behavior in case of setting the current out of the available ranges. Report an error now. - Link to v1: https://lore.kernel.org/r/20240529-feature_poe_power_cap-v1-0-0c4b1d5953b8@bootlin.com Signed-off-by: Kory Maincent --- Kory Maincent (7): net: ethtool: pse-pd: Expand C33 PSE status with class, power and extended state netlink: specs: Expand the PSE netlink command with C33 new features net: pse-pd: pd692x0: Expand ethtool status message net: pse-pd: Add new power limit get and set c33 features net: ethtool: Add new power limit get and set features netlink: specs: Expand the PSE netlink command with C33 pw-limit attributes net: pse-pd: pd692x0: Enhance with new current limit and voltage read callbacks Documentation/netlink/specs/ethtool.yaml | 58 +++++ Documentation/networking/ethtool-netlink.rst | 87 +++++++- drivers/net/pse-pd/pd692x0.c | 317 ++++++++++++++++++++++++++- drivers/net/pse-pd/pse_core.c | 172 ++++++++++++++- include/linux/ethtool.h | 20 ++ include/linux/pse-pd/pse.h | 51 +++++ include/uapi/linux/ethtool.h | 191 ++++++++++++++++ include/uapi/linux/ethtool_netlink.h | 12 + net/ethtool/pse-pd.c | 119 +++++++++- 9 files changed, 997 insertions(+), 30 deletions(-) --- base-commit: 2b117c82eb31424d12326707ba9085dd31fb193b change-id: 20240425-feature_poe_power_cap-18e90ba7294b Best regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com . From: Oleksij Rempel To: "David S. Miller" , Andrew Lunn , Eric Dumazet , Florian Fainelli , Jakub Kicinski , Paolo Abeni , Woojung Huh , Arun Ramadoss , Heiner Kallweit , Russell King , Yuiko Oshino Cc: Oleksij Rempel , kernel@pengutronix.de, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, UNGLinuxDriver@microchip.com Subject: [PATCH net-next v1 1/1] net: phy: microchip: lan937x: add support for 100BaseTX PHY Date: Thu, 4 Jul 2024 15:58:50 +0200 Message-Id: <20240704135850.3939342-1-o.rempel@pengutronix.de> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1268006 org.kernel.vger.netdev:355651 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Add support of 100BaseTX PHY build in to LAN9371 and LAN9372 switches. Signed-off-by: Oleksij Rempel --- drivers/net/phy/microchip_t1.c | 74 ++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) diff --git a/drivers/net/phy/microchip_t1.c b/drivers/net/phy/microchip_t1.c index a35528497a576..c7ca0d04b9e1b 100644 --- a/drivers/net/phy/microchip_t1.c +++ b/drivers/net/phy/microchip_t1.c @@ -12,6 +12,7 @@ #define PHY_ID_LAN87XX 0x0007c150 #define PHY_ID_LAN937X 0x0007c180 +#define PHY_ID_LAN937X_TX 0x0007c190 /* External Register Control Register */ #define LAN87XX_EXT_REG_CTL (0x14) @@ -94,6 +95,10 @@ /* SQI defines */ #define LAN87XX_MAX_SQI 0x07 +#define LAN937X_MODE_CTRL_STATUS_REG 0x11 +#define LAN937X_AUTOMDIX_EN BIT(7) +#define LAN937X_MDI_MODE BIT(6) + #define DRIVER_AUTHOR "Nisar Sayed " #define DRIVER_DESC "Microchip LAN87XX/LAN937x T1 PHY driver" @@ -860,6 +865,66 @@ static int lan87xx_get_sqi_max(struct phy_device *phydev) return LAN87XX_MAX_SQI; } +static int lan937x_tx_read_status(struct phy_device *phydev) +{ + int ret; + + ret = genphy_read_status(phydev); + if (ret < 0) + return ret; + + ret = phy_read(phydev, LAN937X_MODE_CTRL_STATUS_REG); + if (ret < 0) + return ret; + + if (ret & LAN937X_AUTOMDIX_EN) { + phydev->mdix_ctrl = ETH_TP_MDI_AUTO; + /* MDI/MDIX status is unknown */ + phydev->mdix = ETH_TP_MDI_INVALID; + } else if (ret & LAN937X_MDI_MODE) { + phydev->mdix_ctrl = ETH_TP_MDI_X; + phydev->mdix = ETH_TP_MDI_X; + } else { + phydev->mdix_ctrl = ETH_TP_MDI; + phydev->mdix = ETH_TP_MDI; + } + + return 0; +} + +static int lan937x_tx_config_mdix(struct phy_device *phydev, u8 ctrl) +{ + u16 val; + + switch (ctrl) { + case ETH_TP_MDI: + val = 0; + break; + case ETH_TP_MDI_X: + val = LAN937X_MDI_MODE; + break; + case ETH_TP_MDI_AUTO: + val = LAN937X_AUTOMDIX_EN; + break; + default: + return 0; + } + + return phy_modify(phydev, LAN937X_MODE_CTRL_STATUS_REG, + LAN937X_AUTOMDIX_EN | LAN937X_MDI_MODE, val); +} + +static int lan937x_tx_config_aneg(struct phy_device *phydev) +{ + int ret; + + ret = genphy_config_aneg(phydev); + if (ret) + return ret; + + return lan937x_tx_config_mdix(phydev, phydev->mdix_ctrl); +} + static struct phy_driver microchip_t1_phy_driver[] = { { PHY_ID_MATCH_MODEL(PHY_ID_LAN87XX), @@ -894,6 +959,14 @@ static struct phy_driver microchip_t1_phy_driver[] = { .get_sqi_max = lan87xx_get_sqi_max, .cable_test_start = lan87xx_cable_test_start, .cable_test_get_status = lan87xx_cable_test_get_status, + }, + { + PHY_ID_MATCH_MODEL(PHY_ID_LAN937X_TX), + .name = "Microchip LAN937x TX", + .suspend = genphy_suspend, + .resume = genphy_resume, + .config_aneg = lan937x_tx_config_aneg, + .read_status = lan937x_tx_read_status, } }; @@ -902,6 +975,7 @@ module_phy_driver(microchip_t1_phy_driver); static struct mdio_device_id __maybe_unused microchip_t1_tbl[] = { { PHY_ID_MATCH_MODEL(PHY_ID_LAN87XX) }, { PHY_ID_MATCH_MODEL(PHY_ID_LAN937X) }, + { PHY_ID_MATCH_MODEL(PHY_ID_LAN937X_TX) }, { } }; -- 2.39.2 . From: =?UTF-8?q?Kamil=20Hor=C3=A1k=20=282N=29?= To: , , , , , , , , , , , CC: , , , Subject: [PATCH v10 0/4] net: phy: bcm5481x: add support for BroadR-Reach mode Date: Thu, 4 Jul 2024 16:04:09 +0200 Message-ID: <20240704140413.2797199-1-kamilh@axis.com> 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: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1268020 org.kernel.vger.netdev:355656 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail PATCH 1 - Add the 10baseT1BRR_Full link mode PATCH 2 - Add the definitions of LRE registers, necessary to use BroadR-Reach modes on the BCM5481x PHY PATCH 3 - Add brr-mode flag to switch between IEEE802.3 and BroadR-Reach PATCH 4 - Implementation of the BroadR-Reach modes for the Broadcom PHYs Changes in v2: - Divided into multiple patches, removed useless link modes Changes in v3: - Fixed uninitialized variable in bcm5481x_config_delay_swap function Changes in v4: - Improved the division of functions between bcm-phy library and broadcom.c - Changed the BroadR-Reach / IEEE mode switching to device tree boolean as these modes are mutually exclusive and barely could coexist in one hardware - Made the link mode selection compatible with current ethtool (i.e. the linkmode is selected by choosing speed and master-slave) Changes in v5: - Fixed the operator precedence as reported by the kernel test robot - Fixed doc of bcm_linkmode_adv_to_mii_adv_t function Changes in v6: - Moved the brr-mode flag to separate commit as required by the rules for DT binding patches - Renamed some functions to make clear they handle LRE-related stuff - Reordered variable definitions to match the coding style requirements Changes in v7: - Fixed the changes distribution into patches (first one was not buildable) Changes in v8: - Fixed coding style and did other changes on behalf of the reviewers Changes in v9: - Applied reviewed tags to unchanged commits, reformatted the submitter's address Changes in v10: - Fixed minor CR issues, clarified the embedded documentation and the commit message Kamil Horák (2N) (4): net: phy: bcm54811: New link mode for BroadR-Reach net: phy: bcm54811: Add LRE registers definitions dt-bindings: ethernet-phy: add optional brr-mode flag net: phy: bcm-phy-lib: Implement BroadR-Reach link modes .../devicetree/bindings/net/ethernet-phy.yaml | 8 + drivers/net/phy/bcm-phy-lib.c | 115 +++++ drivers/net/phy/bcm-phy-lib.h | 4 + drivers/net/phy/broadcom.c | 405 +++++++++++++++++- drivers/net/phy/phy-core.c | 3 +- include/linux/brcmphy.h | 88 ++++ include/uapi/linux/ethtool.h | 1 + net/ethtool/common.c | 3 + 8 files changed, 608 insertions(+), 19 deletions(-) -- 2.39.2 . From: Oleksij Rempel To: "David S. Miller" , Andrew Lunn , Eric Dumazet , Florian Fainelli , Jakub Kicinski , Paolo Abeni , Vladimir Oltean , Woojung Huh , Arun Ramadoss Cc: Oleksij Rempel , kernel@pengutronix.de, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, UNGLinuxDriver@microchip.com Subject: [PATCH net-next v1 1/1] net: dsa: microchip: lan9371/2: update MAC capabilities for port 4 Date: Thu, 4 Jul 2024 16:13:48 +0200 Message-Id: <20240704141348.3947232-1-o.rempel@pengutronix.de> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1268039 org.kernel.vger.netdev:355662 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Set proper MAC capabilities for port 4 on LAN9371 and LAN9372 switches with integrated 100BaseTX PHY. Signed-off-by: Oleksij Rempel --- drivers/net/dsa/microchip/lan937x_main.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/dsa/microchip/lan937x_main.c b/drivers/net/dsa/microchip/lan937x_main.c index 83ac33fede3f5..44911bc7cea1d 100644 --- a/drivers/net/dsa/microchip/lan937x_main.c +++ b/drivers/net/dsa/microchip/lan937x_main.c @@ -324,6 +324,11 @@ void lan937x_phylink_get_caps(struct ksz_device *dev, int port, /* MII/RMII/RGMII ports */ config->mac_capabilities |= MAC_ASYM_PAUSE | MAC_SYM_PAUSE | MAC_100HD | MAC_10 | MAC_1000FD; + } else if ((dev->info->chip_id == LAN9371_CHIP_ID || + dev->info->chip_id == LAN9372_CHIP_ID) && + port == KSZ_PORT_4) { + config->mac_capabilities |= MAC_ASYM_PAUSE | MAC_SYM_PAUSE | + MAC_100HD | MAC_10; } } -- 2.39.2 . From: Josua Mayer Subject: [PATCH v7 0/5] arm64: dts: add description for solidrun cn9130 som and clearfog boards Date: Thu, 04 Jul 2024 17:03:18 +0200 Message-Id: <20240704-cn9130-som-v7-0-eea606ba5faa@solid-run.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Andrew Lunn , Gregory Clement , Sebastian Hesselbarth , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Richard Cochran Cc: Yazan Shhady , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Josua Mayer , Krzysztof Kozlowski X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1268137 org.kernel.vger.netdev:355685 Newsgroups: org.kernel.vger.linux-kernel,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail SolidRun CN9130 SoM is a mostly pin-comptible replacement for Armada 388 SoM used in Clearfog and Clearfog Pro boards. 1. Add new binding for compatible strings closely matching the original. 2. Add device-tree includes for SoM and carrier shared design. 3. Add device-tree for both Clearfog Base and Pro. While dtbs_check is happy with LED descriptions behind dsa switch, functionally they require supporting code by Andrew Lunn: https://lore.kernel.org/r/20240401-v6-8-0-net-next-mv88e6xxx-leds-v4-v3-0-221b3fa55f78@lunn.ch NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE: CN9130 SoM has a different footprint from Armada 388 SoM. Components on the carrier board below the SoM may collide causing damage, such as on Clearfog Base. Signed-off-by: Josua Mayer --- Changes in v7: - dropped dt-bindings for usb phy and adc which were picked into their respective trees - Link to v6: https://lore.kernel.org/r/20240602-cn9130-som-v6-0-89393e86d4c7@solid-run.com Changes in v6: - add device-tree for cn9132 clearfog and CEX-7 module - add dt compatible for tla2021 adc --> I don't plan to submit a driver patch because I can't test it --> might share untested patch - add dt property for swapping d+-/d- on cp110 utmi phy --> I plan to submit a driver patch, already prototyped - removed duplicate node reference / status=okay for cp0_utmi from cn9131-cf-solidwan.dts - rebased on 6.10-rc1 - Link to v5: https://lore.kernel.org/r/20240509-cn9130-som-v5-0-95493eb5c79d@solid-run.com Changes in v5: - replaced *-gpio properties with preferred *-gpios (Reported-by: robh@kernel.org) - removed fixed-regulator regulator-oc-protection-microamp properties This property is intended to set a configurable over-current limit to a particular value. The physical component however is not configurable, remove the property. - kept all review tags since the changes were minor, hope that is okay with everybody. - Link to v4: https://lore.kernel.org/r/20240502-cn9130-som-v4-0-0a2e2f1c70d8@solid-run.com Changes in v4: - Picked up reviewed-by tags by Andrew Lunn. - fixed a typo and changed 3-line comment into single-line comment for clearfog-base/-pro dts, but kept review tags since change was minor. - Updated SFP led labels to use "sfp?:colour" without "color" property, to avoid duplicate labels while reflecting they are each dual-colour. - Link to v3: https://lore.kernel.org/r/20240414-cn9130-som-v3-0-350a67d44e0a@solid-run.com Changes in v3: - picked up acked-by for dt-bindings - skipped acked-by for dts because additional changes were made: - moved legacy netdev aliases to carrier dts - fix status property style errors - add pinctrl for secondary spi chip-select on mikrobus header (& som) - specify spi bus frequency limits for som - Added CN9131 SolidWAN board - Link to v2: https://lore.kernel.org/r/20240404-cn9130-som-v2-0-3af2229c7d2d@solid-run.com Changes in v2: - rewrote dt bindings dropping unnecessary compatibles (Reported-By: Krzysztof Kozlowski ) - added bindings for two additional boards (cn9131/9132) support planned for the coming weeks, mostly serves illustrational purposes, to understand cn913x variants - cf-pro: add description for LEDs behind DSA switch - cf-base: add description for LEDs behind PHYs (Reported-By: Andrew Lunn ) - Link to v1: https://lore.kernel.org/r/20240321-cn9130-som-v1-0-711127a409ae@solid-run.com --- Josua Mayer (5): dt-bindings: arm64: marvell: add solidrun cn9130 som based boards dt-bindings: arm64: marvell: add solidrun cn9132 CEX-7 evaluation board arm64: dts: add description for solidrun cn9130 som and clearfog boards arm64: dts: add description for solidrun cn9131 solidwan board arm64: dts: add description for solidrun cn9132 cex7 module and clearfog board .../bindings/arm/marvell/armada-7k-8k.yaml | 18 + arch/arm64/boot/dts/marvell/Makefile | 4 + arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 178 ++++++ arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 375 +++++++++++ arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 197 ++++++ arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 +++++ arch/arm64/boot/dts/marvell/cn9131-cf-solidwan.dts | 637 ++++++++++++++++++ arch/arm64/boot/dts/marvell/cn9132-clearfog.dts | 673 +++++++++++++++++++ arch/arm64/boot/dts/marvell/cn9132-sr-cex7.dtsi | 712 +++++++++++++++++++++ 9 files changed, 2954 insertions(+) --- base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0 change-id: 20240318-cn9130-som-848e86acb0ac Sincerely, -- Josua Mayer . X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Thu, 04 Jul 2024 08:07:24 -0700 Message-ID: <000000000000e9f499061c6d4d7a@google.com> Subject: [syzbot] [net?] KCSAN: data-race in __dev_change_flags / is_upper_ndev_bond_master_filter (9) From: syzbot To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, pabeni@redhat.com, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1268146 org.kernel.vger.netdev:355689 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hello, syzbot found the following issue on: HEAD commit: 8a9c6c40432e Merge tag 'io_uring-6.10-20240703' of git://g.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1558eeb9980000 kernel config: https://syzkaller.appspot.com/x/.config?x=5b9537cd00be479e dashboard link: https://syzkaller.appspot.com/bug?extid=113b65786d8662e21ff7 compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 Unfortunately, I don't have any reproducer for this issue yet. Downloadable assets: disk image: https://storage.googleapis.com/syzbot-assets/f01153f3ec8e/disk-8a9c6c40.raw.xz vmlinux: https://storage.googleapis.com/syzbot-assets/04b88663a824/vmlinux-8a9c6c40.xz kernel image: https://storage.googleapis.com/syzbot-assets/63c518cc63c5/bzImage-8a9c6c40.xz IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+113b65786d8662e21ff7@syzkaller.appspotmail.com ================================================================== BUG: KCSAN: data-race in __dev_change_flags / is_upper_ndev_bond_master_filter read-write to 0xffff888112fca0b0 of 4 bytes by task 9257 on cpu 1: __dev_change_flags+0x9a/0x410 net/core/dev.c:8755 rtnl_configure_link net/core/rtnetlink.c:3321 [inline] rtnl_newlink_create net/core/rtnetlink.c:3518 [inline] __rtnl_newlink net/core/rtnetlink.c:3730 [inline] rtnl_newlink+0x121e/0x1690 net/core/rtnetlink.c:3743 rtnetlink_rcv_msg+0x85e/0x910 net/core/rtnetlink.c:6635 netlink_rcv_skb+0x12c/0x230 net/netlink/af_netlink.c:2564 rtnetlink_rcv+0x1c/0x30 net/core/rtnetlink.c:6653 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0x58d/0x660 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x5ca/0x6e0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x140/0x180 net/socket.c:745 ____sys_sendmsg+0x312/0x410 net/socket.c:2585 ___sys_sendmsg net/socket.c:2639 [inline] __sys_sendmsg+0x1e9/0x280 net/socket.c:2668 __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x46/0x50 net/socket.c:2675 x64_sys_call+0xb25/0x2d70 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f read to 0xffff888112fca0b0 of 4 bytes by task 3104 on cpu 0: netif_is_bond_master include/linux/netdevice.h:5020 [inline] is_upper_ndev_bond_master_filter+0x2b/0xb0 drivers/infiniband/core/roce_gid_mgmt.c:275 ib_enum_roce_netdev+0x124/0x1d0 drivers/infiniband/core/device.c:2310 ib_enum_all_roce_netdevs+0x8a/0x100 drivers/infiniband/core/device.c:2337 netdevice_event_work_handler+0x15b/0x3c0 drivers/infiniband/core/roce_gid_mgmt.c:626 process_one_work kernel/workqueue.c:3248 [inline] process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3329 worker_thread+0x526/0x720 kernel/workqueue.c:3409 kthread+0x1d1/0x210 kernel/kthread.c:389 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 value changed: 0x00001002 -> 0x00008002 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 3104 Comm: kworker/u8:6 Not tainted 6.10.0-rc6-syzkaller-00067-g8a9c6c40432e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Workqueue: gid-cache-wq netdevice_event_work_handler ================================================================== netdevsim netdevsim3 netdevsim3 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim3 netdevsim2 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim3 netdevsim1 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0 netdevsim netdevsim3 netdevsim0 (unregistering): unset [1, 0] type 2 family 0 port 6081 - 0 bridge_slave_1: left allmulticast mode bridge_slave_1: left promiscuous mode bridge0: port 2(bridge_slave_1) entered disabled state bridge_slave_0: left allmulticast mode bridge_slave_0: left promiscuous mode bridge0: port 1(bridge_slave_0) entered disabled state bond0 (unregistering): (slave bond_slave_0): Releasing backup interface bond0 (unregistering): (slave bond_slave_1): Releasing backup interface bond0 (unregistering): Released all slaves hsr_slave_0: left promiscuous mode hsr_slave_1: left promiscuous mode batman_adv: batadv0: Interface deactivated: batadv_slave_0 batman_adv: batadv0: Removing interface: batadv_slave_0 batman_adv: batadv0: Interface deactivated: batadv_slave_1 batman_adv: batadv0: Removing interface: batadv_slave_1 veth1_macvtap: left promiscuous mode veth0_macvtap: left promiscuous mode veth1_vlan: left promiscuous mode veth0_vlan: left promiscuous mode team0 (unregistering): Port device team_slave_1 removed team0 (unregistering): Port device team_slave_0 removed --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. If the report is already addressed, let syzbot know by replying with: #syz fix: exact-commit-title If you want to overwrite report's subsystems, reply with: #syz set subsystems: new-subsystem (See the list of subsystem names on the web dashboard) If the report is a duplicate of another one, reply with: #syz dup: exact-subject-of-another-report If you want to undo deduplication, reply with: #syz undup . Date: Thu, 4 Jul 2024 16:08:22 +0100 From: Daniel Golle To: =?utf-8?B?QXLEsW7DpyDDnE5BTA==?= , Daniel Golle , DENG Qingfang , Sean Wang , Andrew Lunn , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Matthias Brugger , AngeloGioacchino Del Regno , Landen Chao , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: [PATCH net v4] net: dsa: mt7530: fix impossible MDIO address and issue warning Message-ID: <1c378be54d0fb76117f6d72dadd4a43a9950f0dc.1720105125.git.daniel@makrotopia.org> 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-Disposition: inline Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1268151 org.kernel.vger.netdev:355690 Newsgroups: org.kernel.vger.linux-kernel,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-mediatek,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail The MDIO address of the MT7530 and MT7531 switch ICs can be configured using bootstrap pins. However, there are only 4 possible options for the switch itself: 7, 15, 23 and 31. As in MediaTek's SDK the address of the switch is wrongly stated in the device tree as 0 (while in reality it is 31), warn the user about such broken device tree and make a good guess what was actually intended. This is imporant also to not break compatibility with older Device Trees as with commit 868ff5f4944a ("net: dsa: mt7530-mdio: read PHY address of switch from device tree") the address in device tree will be taken into account, while before it was hard-coded to 0x1f. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: Daniel Golle Reviewed-by: Andrew Lunn Tested-by: Arınç ÜNAL Reviewed-by: Arınç ÜNAL --- Changes since v3 [3]: - simplify calculation of correct address Changes since v2 [2]: - use macros instead of magic numbers - introduce helper functions - register new device on MDIO bus instead of messing with the address and schedule delayed_work to unregister the "wrong" device. This is a slightly different approach than suggested by Russell, but imho makes things much easier than keeping the "wrong" device and having to deal with keeping the removal of both devices linked. - improve comments Changes since v1 [1]: - use FW_WARN as suggested. - fix build on net tree which doesn't have 'mdiodev' as member of the priv struct. Imho including this patch as fix makes sense to warn users about broken firmware, even if the change introducing the actual breakage is only present in net-next for now. [1]: https://patchwork.kernel.org/project/netdevbpf/patch/e615351aefba25e990215845e4812e6cb8153b28.1714433716.git.daniel@makrotopia.org/ [2]: https://patchwork.kernel.org/project/netdevbpf/patch/11f5f127d0350e72569c36f9060b6e642dfaddbb.1714514208.git.daniel@makrotopia.org/ [3]: https://patchwork.kernel.org/project/netdevbpf/patch/7e3fed489c0bbca84a386b1077c61589030ff4ab.1719963228.git.daniel@makrotopia.org/ drivers/net/dsa/mt7530-mdio.c | 91 +++++++++++++++++++++++++++++++++++ 1 file changed, 91 insertions(+) diff --git a/drivers/net/dsa/mt7530-mdio.c b/drivers/net/dsa/mt7530-mdio.c index 51df42ccdbe6..2037ed944801 100644 --- a/drivers/net/dsa/mt7530-mdio.c +++ b/drivers/net/dsa/mt7530-mdio.c @@ -11,6 +11,7 @@ #include #include #include +#include #include #include "mt7530.h" @@ -136,6 +137,92 @@ static const struct of_device_id mt7530_of_match[] = { }; MODULE_DEVICE_TABLE(of, mt7530_of_match); +static int +mt7530_correct_addr(int phy_addr) +{ + /* The corrected address is calculated as stated below: + * 0~6, 31 -> 31 + * 7~14 -> 7 + * 15~22 -> 15 + * 23~30 -> 23 + */ +return (phy_addr - MT7530_NUM_PORTS & ~MT7530_NUM_PORTS) + MT7530_NUM_PORTS & PHY_MAX_ADDR - 1; +} + +static bool +mt7530_is_invalid_addr(int phy_addr) +{ + /* Only MDIO bus addresses 7, 15, 23, and 31 are valid options, + * which all have the least significant three bits set. Check + * for this. + */ + return (phy_addr & MT7530_NUM_PORTS) != MT7530_NUM_PORTS; +} + +struct remove_impossible_priv { + struct delayed_work remove_impossible_work; + struct mdio_device *mdiodev; +}; + +static void +mt7530_remove_impossible(struct work_struct *work) +{ + struct remove_impossible_priv *priv = container_of(work, struct remove_impossible_priv, + remove_impossible_work.work); + struct mdio_device *mdiodev = priv->mdiodev; + + mdio_device_remove(mdiodev); + mdio_device_free(mdiodev); + kfree(priv); +} + +static int +mt7530_reregister(struct mdio_device *mdiodev) +{ + /* If the address in DT must be wrong, make a good guess about + * the most likely intention, issue a warning, register a new + * MDIO device at the correct address and schedule the removal + * of the device having an impossible address. + */ + struct fwnode_handle *fwnode = dev_fwnode(&mdiodev->dev); + int corrected_addr = mt7530_correct_addr(mdiodev->addr); + struct remove_impossible_priv *rem_priv; + struct mdio_device *new_mdiodev; + int ret; + + rem_priv = kmalloc(sizeof(*rem_priv), GFP_KERNEL); + if (!rem_priv) + return -ENOMEM; + + new_mdiodev = mdio_device_create(mdiodev->bus, corrected_addr); + if (IS_ERR(new_mdiodev)) { + ret = PTR_ERR(new_mdiodev); + goto out_free_work; + } + device_set_node(&new_mdiodev->dev, fwnode); + + ret = mdio_device_register(new_mdiodev); + if (WARN_ON(ret)) + goto out_free_dev; + + dev_warn(&mdiodev->dev, FW_WARN + "impossible switch MDIO address in device tree, assuming %d\n", + corrected_addr); + + /* schedule impossible device for removal from mdio bus */ + rem_priv->mdiodev = mdiodev; + INIT_DELAYED_WORK(&rem_priv->remove_impossible_work, mt7530_remove_impossible); + schedule_delayed_work(&rem_priv->remove_impossible_work, 0); + + return -EFAULT; + +out_free_dev: + mdio_device_free(new_mdiodev); +out_free_work: + kfree(rem_priv); + return ret; +} + static int mt7530_probe(struct mdio_device *mdiodev) { @@ -144,6 +231,10 @@ mt7530_probe(struct mdio_device *mdiodev) struct device_node *dn; int ret; + /* Check and if needed correct the MDIO address of the switch */ + if (mt7530_is_invalid_addr(mdiodev->addr)) + return mt7530_reregister(mdiodev); + dn = mdiodev->dev.of_node; priv = devm_kzalloc(&mdiodev->dev, sizeof(*priv), GFP_KERNEL); -- 2.45.2 . From: James Chapman To: netdev@vger.kernel.org Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, linux-kernel@vger.kernel.org, pabeni@redhat.com, syzkaller-bugs@googlegroups.com, tparkin@katalix.com, hdanton@sina.com, James Chapman , syzbot+b471b7c936301a59745b@syzkaller.appspotmail.com, syzbot+c041b4ce3a6dfd1e63e2@syzkaller.appspotmail.com Subject: [PATCH net-next v2] l2tp: fix possible UAF when cleaning up tunnels Date: Thu, 4 Jul 2024 16:25:08 +0100 Message-Id: <20240704152508.1923908-1-jchapman@katalix.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1268179 org.kernel.vger.netdev:355692 Newsgroups: org.kernel.vger.linux-kernel,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail syzbot reported a UAF caused by a race when the L2TP work queue closes a tunnel at the same time as a userspace thread closes a session in that tunnel. Tunnel cleanup is handled by a work queue which iterates through the sessions contained within a tunnel, and closes them in turn. Meanwhile, a userspace thread may arbitrarily close a session via either netlink command or by closing the pppox socket in the case of l2tp_ppp. The race condition may occur when l2tp_tunnel_closeall walks the list of sessions in the tunnel and deletes each one. Currently this is implemented using list_for_each_safe, but because the list spinlock is dropped in the loop body it's possible for other threads to manipulate the list during list_for_each_safe's list walk. This can lead to the list iterator being corrupted, leading to list_for_each_safe spinning. One sequence of events which may lead to this is as follows: * A tunnel is created, containing two sessions A and B. * A thread closes the tunnel, triggering tunnel cleanup via the work queue. * l2tp_tunnel_closeall runs in the context of the work queue. It removes session A from the tunnel session list, then drops the list lock. At this point the list_for_each_safe temporary variable is pointing to the other session on the list, which is session B, and the list can be manipulated by other threads since the list lock has been released. * Userspace closes session B, which removes the session from its parent tunnel via l2tp_session_delete. Since l2tp_tunnel_closeall has released the tunnel list lock, l2tp_session_delete is able to call list_del_init on the session B list node. * Back on the work queue, l2tp_tunnel_closeall resumes execution and will now spin forever on the same list entry until the underlying session structure is freed, at which point UAF occurs. The solution is to iterate over the tunnel's session list using list_first_entry_not_null to avoid the possibility of the list iterator pointing at a list item which may be removed during the walk. Also, have l2tp_tunnel_closeall ref each session while it processes it to prevent another thread from freeing it. cpu1 cpu2 --- --- pppol2tp_release() spin_lock_bh(&tunnel->list_lock); for (;;) { session = list_first_entry_or_null(&tunnel->session_list, struct l2tp_session, list); if (!session) break; list_del_init(&session->list); spin_unlock_bh(&tunnel->list_lock); l2tp_session_delete(session); l2tp_session_delete(session); spin_lock_bh(&tunnel->list_lock); } spin_unlock_bh(&tunnel->list_lock); Calling l2tp_session_delete on the same session twice isn't a problem per-se, but if cpu2 manages to destruct the socket and unref the session to zero before cpu1 progresses then it would lead to UAF. Reported-by: syzbot+b471b7c936301a59745b@syzkaller.appspotmail.com Reported-by: syzbot+c041b4ce3a6dfd1e63e2@syzkaller.appspotmail.com Fixes: d18d3f0a24fc ("l2tp: replace hlist with simple list for per-tunnel session list") Signed-off-by: James Chapman Signed-off-by: Tom Parkin --- v2: - hold session ref when processing tunnel close (Hillf Danton) v1: https://lore.kernel.org/netdev/20240703185108.1752795-1-jchapman@katalix.com/ --- net/l2tp/l2tp_core.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c index 64f446f0930b..2790a51e59e3 100644 --- a/net/l2tp/l2tp_core.c +++ b/net/l2tp/l2tp_core.c @@ -1290,17 +1290,20 @@ static void l2tp_session_unhash(struct l2tp_session *session) static void l2tp_tunnel_closeall(struct l2tp_tunnel *tunnel) { struct l2tp_session *session; - struct list_head *pos; - struct list_head *tmp; spin_lock_bh(&tunnel->list_lock); tunnel->acpt_newsess = false; - list_for_each_safe(pos, tmp, &tunnel->session_list) { - session = list_entry(pos, struct l2tp_session, list); + for (;;) { + session = list_first_entry_or_null(&tunnel->session_list, + struct l2tp_session, list); + if (!session) + break; + l2tp_session_inc_refcount(session); list_del_init(&session->list); spin_unlock_bh(&tunnel->list_lock); l2tp_session_delete(session); spin_lock_bh(&tunnel->list_lock); + l2tp_session_dec_refcount(session); } spin_unlock_bh(&tunnel->list_lock); } -- 2.34.1 . From: "Jason A. Donenfeld" To: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org Cc: "Jason A. Donenfeld" Subject: [PATCH net 0/4] wireguard fixes for 6.10-rc7 Date: Thu, 4 Jul 2024 17:45:13 +0200 Message-ID: <20240704154517.1572127-1-Jason@zx2c4.com> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Xref: photonic.trudheim.com org.kernel.vger.netdev:355693 Newsgroups: org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail Hi Jakub, These are four small fixes for WireGuard, which are all marked for stable: 1) A QEMU command line fix to remove deprecated flags. 2) Use of proper unaligned helpers to avoid unaligned memory access on some systems, from Helge. 3) Two patches to annotate intentional data races, so KCSAN and syzbot don't get upset. Thanks, Jason Helge Deller (1): wireguard: allowedips: avoid unaligned 64-bit memory accesses Jason A. Donenfeld (3): wireguard: selftests: use acpi=off instead of -no-acpi for recent QEMU wireguard: queueing: annotate intentional data race in cpu round robin wireguard: send: annotate intentional data race in checking empty queue drivers/net/wireguard/allowedips.c | 4 ++-- drivers/net/wireguard/queueing.h | 4 ++-- drivers/net/wireguard/send.c | 2 +- tools/testing/selftests/wireguard/qemu/Makefile | 8 ++++---- 4 files changed, 9 insertions(+), 9 deletions(-) -- 2.45.2 . From: Shengyu Qu To: nbd@nbd.name, sean.wang@mediatek.com, Mark-MC.Lee@mediatek.com, lorenzo@kernel.org, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Cc: Shengyu Qu , Elad Yifee Subject: [PATCH v3] net: ethernet: mtk_ppe: Change PPE entries number to 16K Date: Fri, 5 Jul 2024 01:26:26 +0800 Message-ID: Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Xref: photonic.trudheim.com org.kernel.vger.linux-kernel:1268340 org.kernel.vger.netdev:355699 Newsgroups: org.kernel.vger.linux-kernel,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-mediatek,org.kernel.vger.netdev Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail MT7981,7986 and 7988 all supports 32768 PPE entries, and MT7621/MT7620 supports 16384 PPE entries, but only set to 8192 entries in driver. So incrase max entries to 16384 instead. Signed-off-by: Elad Yifee Signed-off-by: Shengyu Qu --- Changes since V1: - Reduced max entries from 32768 to 16384 to keep compatible with MT7620/21 devices. - Add fixes tag Changes since V2: - Remove fixes tag (Thanks to Jakub) --- drivers/net/ethernet/mediatek/mtk_ppe.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/mediatek/mtk_ppe.h b/drivers/net/ethernet/mediatek/mtk_ppe.h index 691806bca372..223f709e2704 100644 --- a/drivers/net/ethernet/mediatek/mtk_ppe.h +++ b/drivers/net/ethernet/mediatek/mtk_ppe.h @@ -8,7 +8,7 @@ #include #include -#define MTK_PPE_ENTRIES_SHIFT 3 +#define MTK_PPE_ENTRIES_SHIFT 4 #define MTK_PPE_ENTRIES (1024 << MTK_PPE_ENTRIES_SHIFT) #define MTK_PPE_HASH_MASK (MTK_PPE_ENTRIES - 1) #define MTK_PPE_WAIT_TIMEOUT_US 1000000 -- 2.34.1 . From: Ronald Wahl To: Ronald Wahl Cc: Ronald Wahl , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , netdev@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH v2] net: ks8851: Fix deadlock with the SPI chip variant Date: Thu, 4 Jul 2024 19:47:56 +0200 Message-ID: <20240704174756.1225995-1-rwahl@gmx.de> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Xref: photonic.trudheim.com org.kernel.vger.netdev:355703 Newsgroups: org.kernel.vger.netdev,org.kernel.vger.stable Path: photonic.trudheim.com!nntp.lore.kernel.org!not-for-mail From: Ronald Wahl When SMP is enabled and spinlocks are actually functional then there is a deadlock with the 'statelock' spinlock between ks8851_start_xmit_spi and ks8851_irq: watchdog: BUG: soft lockup - CPU#0 stuck for 27s! call trace: queued_spin_lock_slowpath+0x100/0x284 do_raw_spin_lock+0x34/0x44 ks8851_start_xmit_spi+0x30/0xb8 ks8851_start_xmit+0x14/0x20 netdev_start_xmit+0x40/0x6c dev_hard_start_xmit+0x6c/0xbc sch_direct_xmit+0xa4/0x22c __qdisc_run+0x138/0x3fc qdisc_run+0x24/0x3c net_tx_action+0xf8/0x130 handle_softirqs+0x1ac/0x1f0 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x3c/0x58 do_softirq_own_stack+0x1c/0x28 __irq_exit_rcu+0x54/0x9c irq_exit_rcu+0x10/0x1c el1_interrupt+0x38/0x50 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 __netif_schedule+0x6c/0x80 netif_tx_wake_queue+0x38/0x48 ks8851_irq+0xb8/0x2c8 irq_thread_fn+0x2c/0x74 irq_thread+0x10c/0x1b0 kthread+0xc8/0xd8 ret_from_fork+0x10/0x20 This issue has not been identified earlier because tests were done on a device with SMP disabled and so spinlocks were actually NOPs. Now use spin_(un)lock_bh for TX queue related locking to avoid execution of softirq work synchronously that would lead to a deadlock. Fixes: 3dc5d4454545 ("net: ks8851: Fix TX stall caused by TX buffer overru= n") Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Simon Horman Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org # 5.10+ Signed-off-by: Ronald Wahl =2D-- V2: - use spin_lock_bh instead of moving netif_wake_queue outside of locked region (doing the same in the start_xmit function) - add missing net: tag drivers/net/ethernet/micrel/ks8851_common.c | 4 ++-- drivers/net/ethernet/micrel/ks8851_spi.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/micrel/ks8851_common.c b/drivers/net/eth= ernet/micrel/ks8851_common.c index 6453c92f0fa7..51fb6c27153e 100644 =2D-- a/drivers/net/ethernet/micrel/ks8851_common.c +++ b/drivers/net/ethernet/micrel/ks8851_common.c @@ -352,11 +352,11 @@ static irqreturn_t ks8851_irq(int irq, void *_ks) netif_dbg(ks, intr, ks->netdev, "%s: txspace %d\n", __func__, tx_space); - spin_lock(&ks->statelock); + spin_lock_bh(&ks->statelock); ks->tx_space =3D tx_space; if (netif_queue_stopped(ks->netdev)) netif_wake_queue(ks->netdev); - spin_unlock(&ks->statelock); + spin_unlock_bh(&ks->statelock); } if (status & IRQ_SPIBEI) { diff --git a/drivers/net/ethernet/micrel/ks8851_spi.c b/drivers/net/ethern= et/micrel/ks8851_spi.c index 670c1de966db..818e1ce3227b 100644 =2D-- a/drivers/net/ethernet/micrel/ks8851_spi.c +++ b/drivers/net/ethernet/micrel/ks8851_spi.c @@ -385,7 +385,7 @@ static netdev_tx_t ks8851_start_xmit_spi(struct sk_buf= f *skb, netif_dbg(ks, tx_queued, ks->netdev, "%s: skb %p, %d@%p\n", __func__, skb, skb->len, skb->data); - spin_lock(&ks->statelock); + spin_lock_bh(&ks->statelock); if (ks->queued_len + needed > ks->tx_space) { netif_stop_queue(dev); @@ -395,7 +395,7 @@ static netdev_tx_t ks8851_start_xmit_spi(struct sk_buf= f *skb, skb_queue_tail(&ks->txq, skb); } - spin_unlock(&ks->statelock); + spin_unlock_bh(&ks->statelock); if (ret =3D=3D NETDEV_TX_OK) schedule_work(&kss->tx_work); =2D- 2.45.2 .