* [PATCH RESEND net-next 2/2] KEYS: annotate struct user_key_payload with __counted_by
From: Thorsten Blum @ 2026-04-09 7:37 UTC (permalink / raw)
To: David Howells, Jarkko Sakkinen, Kees Cook, Gustavo A. R. Silva
Cc: Thorsten Blum, netdev, keyrings, linux-kernel, linux-hardening
In-Reply-To: <20260409073711.57020-4-thorsten.blum@linux.dev>
Add the __counted_by() compiler attribute to the flexible array member
'data' to improve access bounds-checking via CONFIG_UBSAN_BOUNDS and
CONFIG_FORTIFY_SOURCE.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Resending this because patch 2/2 didn't go to netdev@ (Jakub)
Cc: netdev@vger.kernel.org
---
include/keys/user-type.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/keys/user-type.h b/include/keys/user-type.h
index 386c31432789..2305991f4fcd 100644
--- a/include/keys/user-type.h
+++ b/include/keys/user-type.h
@@ -27,7 +27,8 @@
struct user_key_payload {
struct rcu_head rcu; /* RCU destructor */
unsigned short datalen; /* length of this data */
- char data[] __aligned(__alignof__(u64)); /* actual data */
+ char data[] /* actual data */
+ __aligned(__alignof__(u64)) __counted_by(datalen);
};
extern struct key_type key_type_user;
^ permalink raw reply related
* [PATCH 5.10.y] Bluetooth: SCO: Fix use-after-free in sco_recv_frame() due to missing sock_hold
From: Jianqiang kang @ 2026-04-09 7:44 UTC (permalink / raw)
To: gregkh, stable, imv4bel
Cc: patches, linux-kernel, marcel, johan.hedberg, luiz.dentz, davem,
kuba, linux-bluetooth, netdev, luiz.von.dentz
From: Hyunwoo Kim <imv4bel@gmail.com>
[ Upstream commit 598dbba9919c5e36c54fe1709b557d64120cb94b ]
sco_recv_frame() reads conn->sk under sco_conn_lock() but immediately
releases the lock without holding a reference to the socket. A concurrent
close() can free the socket between the lock release and the subsequent
sk->sk_state access, resulting in a use-after-free.
Other functions in the same file (sco_sock_timeout(), sco_conn_del())
correctly use sco_sock_hold() to safely hold a reference under the lock.
Fix by using sco_sock_hold() to take a reference before releasing the
lock, and adding sock_put() on all exit paths.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Jianqiang kang <jianqkang@sina.cn>
---
net/bluetooth/sco.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index ce084a184a1c..c441e5225458 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -305,7 +305,7 @@ static void sco_recv_frame(struct sco_conn *conn, struct sk_buff *skb)
struct sock *sk;
sco_conn_lock(conn);
- sk = conn->sk;
+ sk = sco_sock_hold(conn);
sco_conn_unlock(conn);
if (!sk)
@@ -314,11 +314,15 @@ static void sco_recv_frame(struct sco_conn *conn, struct sk_buff *skb)
BT_DBG("sk %p len %d", sk, skb->len);
if (sk->sk_state != BT_CONNECTED)
- goto drop;
+ goto drop_put;
- if (!sock_queue_rcv_skb(sk, skb))
+ if (!sock_queue_rcv_skb(sk, skb)) {
+ sock_put(sk);
return;
+ }
+drop_put:
+ sock_put(sk);
drop:
kfree_skb(skb);
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 0/6] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: Paolo Abeni @ 2026-04-09 7:46 UTC (permalink / raw)
To: Luca Weiss, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com>
On 4/3/26 6:43 PM, Luca Weiss wrote:
> First, two fixes that unbreak IPA v5.0+, which can be applied
> independently.
>
> Then add support for IPA v5.2 which can be found in the Milos SoC. And
> finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
> starts working.
You should have probably split the series in 2, with patches 1 & 2
targeting net and the following ones targeting net-next. It looks like
patch 5 needs some adjustment. I'm applying the first 2.
/P
^ permalink raw reply
* [PATCH iwl-next 1/1] igc: add support for forcing link speed without autonegotiation
From: KhaiWenTan @ 2026-04-09 7:27 UTC (permalink / raw)
To: anthony.l.nguyen, przemyslaw.kitszel, andrew+netdev, davem,
edumazet, kuba, pabeni
Cc: intel-wired-lan, netdev, linux-kernel, faizal.abdul.rahim,
hector.blanco.alcaine, hong.aun.looi, khai.wen.tan, Faizal Rahim,
Looi, KhaiWenTan
From: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Allow users to force 10/100 Mb/s link speed and duplex via ethtool
when autonegotiation is disabled. Previously, the driver rejected
"ethtool -s <dev> autoneg off speed <N> duplex <half|full>" with
"Force mode currently not supported."
When autoneg is disabled, the driver programs both the GPY PHY and
I225/I226 MAC control registers to bypass autonegotiation and apply
the requested speed and duplex. The MAC CTRL register is configured
with FRCSPD, FRCDPLX, and the appropriate SPEED and FD bits, while
the PHY STD_CTRL register has ANEN cleared and SSM/SSL/DPLX set to
match. Flow control is also forced on the MAC side when autoneg is
disabled, consistent with the existing autoneg-failed path.
Forcing 1000 Mb/s and 2500 Mb/s is not supported by this change.
Reviewed-by: Looi, Hong Aun <hong.aun.looi@intel.com>
Signed-off-by: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
Signed-off-by: KhaiWenTan <khai.wen.tan@linux.intel.com>
---
drivers/net/ethernet/intel/igc/igc_base.c | 35 +++++-
drivers/net/ethernet/intel/igc/igc_defines.h | 9 +-
drivers/net/ethernet/intel/igc/igc_ethtool.c | 122 ++++++++++++++-----
drivers/net/ethernet/intel/igc/igc_hw.h | 9 ++
drivers/net/ethernet/intel/igc/igc_mac.c | 2 +-
drivers/net/ethernet/intel/igc/igc_main.c | 2 +-
drivers/net/ethernet/intel/igc/igc_phy.c | 66 +++++++++-
drivers/net/ethernet/intel/igc/igc_phy.h | 1 +
8 files changed, 201 insertions(+), 45 deletions(-)
diff --git a/drivers/net/ethernet/intel/igc/igc_base.c b/drivers/net/ethernet/intel/igc/igc_base.c
index 1613b562d17c..ab9120a3127f 100644
--- a/drivers/net/ethernet/intel/igc/igc_base.c
+++ b/drivers/net/ethernet/intel/igc/igc_base.c
@@ -114,11 +114,35 @@ static s32 igc_setup_copper_link_base(struct igc_hw *hw)
u32 ctrl;
ctrl = rd32(IGC_CTRL);
- ctrl |= IGC_CTRL_SLU;
- ctrl &= ~(IGC_CTRL_FRCSPD | IGC_CTRL_FRCDPX);
- wr32(IGC_CTRL, ctrl);
-
- ret_val = igc_setup_copper_link(hw);
+ ctrl &= ~(IGC_CTRL_FRCSPD | IGC_CTRL_FRCDPX |
+ IGC_CTRL_SPEED_MASK | IGC_CTRL_FD);
+
+ if (hw->mac.autoneg_enabled) {
+ ctrl |= IGC_CTRL_SLU;
+ wr32(IGC_CTRL, ctrl);
+ ret_val = igc_setup_copper_link(hw);
+ } else {
+ ctrl |= IGC_CTRL_SLU | IGC_CTRL_FRCSPD | IGC_CTRL_FRCDPX;
+
+ switch (hw->mac.forced_speed_duplex) {
+ case IGC_FORCED_10H:
+ ctrl |= IGC_CTRL_SPEED_10;
+ break;
+ case IGC_FORCED_10F:
+ ctrl |= IGC_CTRL_SPEED_10 | IGC_CTRL_FD;
+ break;
+ case IGC_FORCED_100H:
+ ctrl |= IGC_CTRL_SPEED_100;
+ break;
+ case IGC_FORCED_100F:
+ ctrl |= IGC_CTRL_SPEED_100 | IGC_CTRL_FD;
+ break;
+ default:
+ return -IGC_ERR_CONFIG;
+ }
+ wr32(IGC_CTRL, ctrl);
+ ret_val = igc_setup_copper_link(hw);
+ }
return ret_val;
}
@@ -443,6 +467,7 @@ static const struct igc_phy_operations igc_phy_ops_base = {
.reset = igc_phy_hw_reset,
.read_reg = igc_read_phy_reg_gpy,
.write_reg = igc_write_phy_reg_gpy,
+ .force_speed_duplex = igc_force_speed_duplex,
};
const struct igc_info igc_base_info = {
diff --git a/drivers/net/ethernet/intel/igc/igc_defines.h b/drivers/net/ethernet/intel/igc/igc_defines.h
index 9482ab11f050..3f504751c2d9 100644
--- a/drivers/net/ethernet/intel/igc/igc_defines.h
+++ b/drivers/net/ethernet/intel/igc/igc_defines.h
@@ -129,10 +129,13 @@
#define IGC_ERR_SWFW_SYNC 13
/* Device Control */
+#define IGC_CTRL_FD BIT(0) /* Full Duplex */
#define IGC_CTRL_RST 0x04000000 /* Global reset */
-
#define IGC_CTRL_PHY_RST 0x80000000 /* PHY Reset */
#define IGC_CTRL_SLU 0x00000040 /* Set link up (Force Link) */
+#define IGC_CTRL_SPEED_MASK GENMASK(10, 8)
+#define IGC_CTRL_SPEED_10 FIELD_PREP(IGC_CTRL_SPEED_MASK, 0)
+#define IGC_CTRL_SPEED_100 FIELD_PREP(IGC_CTRL_SPEED_MASK, 1)
#define IGC_CTRL_FRCSPD 0x00000800 /* Force Speed */
#define IGC_CTRL_FRCDPX 0x00001000 /* Force Duplex */
#define IGC_CTRL_VME 0x40000000 /* IEEE VLAN mode enable */
@@ -673,6 +676,10 @@
#define IGC_GEN_POLL_TIMEOUT 1920
/* PHY Control Register */
+#define MII_CR_SPEED_MASK (BIT(6) | BIT(13))
+#define MII_CR_SPEED_10 0x0000 /* SSM=0, SSL=0: 10 Mb/s */
+#define MII_CR_SPEED_100 BIT(13) /* SSM=0, SSL=1: 100 Mb/s */
+#define MII_CR_DUPLEX_EN BIT(8) /* 0 = Half Duplex, 1 = Full Duplex */
#define MII_CR_RESTART_AUTO_NEG 0x0200 /* Restart auto negotiation */
#define MII_CR_POWER_DOWN 0x0800 /* Power down */
#define MII_CR_AUTO_NEG_EN 0x1000 /* Auto Neg Enable */
diff --git a/drivers/net/ethernet/intel/igc/igc_ethtool.c b/drivers/net/ethernet/intel/igc/igc_ethtool.c
index 0122009bedd0..e14771532dad 100644
--- a/drivers/net/ethernet/intel/igc/igc_ethtool.c
+++ b/drivers/net/ethernet/intel/igc/igc_ethtool.c
@@ -1930,7 +1930,12 @@ static int igc_ethtool_get_link_ksettings(struct net_device *netdev,
/* set autoneg settings */
ethtool_link_ksettings_add_link_mode(cmd, supported, Autoneg);
- ethtool_link_ksettings_add_link_mode(cmd, advertising, Autoneg);
+ if (hw->mac.autoneg_enabled) {
+ ethtool_link_ksettings_add_link_mode(cmd, advertising, Autoneg);
+ cmd->base.autoneg = AUTONEG_ENABLE;
+ } else {
+ cmd->base.autoneg = AUTONEG_DISABLE;
+ }
/* Set pause flow control settings */
ethtool_link_ksettings_add_link_mode(cmd, supported, Pause);
@@ -1983,7 +1988,6 @@ static int igc_ethtool_get_link_ksettings(struct net_device *netdev,
cmd->base.duplex = DUPLEX_UNKNOWN;
}
cmd->base.speed = speed;
- cmd->base.autoneg = AUTONEG_ENABLE;
/* MDI-X => 2; MDI =>1; Invalid =>0 */
if (hw->phy.media_type == igc_media_type_copper)
@@ -2000,37 +2004,54 @@ static int igc_ethtool_get_link_ksettings(struct net_device *netdev,
return 0;
}
-static int
-igc_ethtool_set_link_ksettings(struct net_device *netdev,
- const struct ethtool_link_ksettings *cmd)
+/**
+ * igc_handle_autoneg_disabled - Configure forced speed/duplex settings
+ * @netdev: network interface device structure
+ * @speed: requested speed
+ * @duplex: requested duplex
+ *
+ * Validates and records forced speed/duplex when autoneg is disabled.
+ * Only 10/100 Mb/s speeds are supported.
+ *
+ * Return: 0 on success, negative errno on failure.
+ */
+static int igc_handle_autoneg_disabled(struct net_device *netdev, u32 speed,
+ u8 duplex)
{
struct igc_adapter *adapter = netdev_priv(netdev);
- struct net_device *dev = adapter->netdev;
- struct igc_hw *hw = &adapter->hw;
- u16 advertised = 0;
+ struct igc_mac_info *mac = &adapter->hw.mac;
+ enum igc_forced_speed_duplex forced_speed_duplex;
- /* When adapter in resetting mode, autoneg/speed/duplex
- * cannot be changed
- */
- if (igc_check_reset_block(hw)) {
- netdev_err(dev, "Cannot change link characteristics when reset is active\n");
+ switch (speed) {
+ case SPEED_10:
+ forced_speed_duplex = (duplex == DUPLEX_FULL) ? IGC_FORCED_10F : IGC_FORCED_10H;
+ break;
+ case SPEED_100:
+ forced_speed_duplex = (duplex == DUPLEX_FULL) ? IGC_FORCED_100F : IGC_FORCED_100H;
+ break;
+ default:
+ netdev_info(netdev, "Unsupported speed for forced link\n");
return -EINVAL;
}
- /* MDI setting is only allowed when autoneg enabled because
- * some hardware doesn't allow MDI setting when speed or
- * duplex is forced.
- */
- if (cmd->base.eth_tp_mdix_ctrl) {
- if (cmd->base.eth_tp_mdix_ctrl != ETH_TP_MDI_AUTO &&
- cmd->base.autoneg != AUTONEG_ENABLE) {
- netdev_err(dev, "Forcing MDI/MDI-X state is not supported when link speed and/or duplex are forced\n");
- return -EINVAL;
- }
- }
+ mac->autoneg_enabled = false;
+ mac->forced_speed_duplex = forced_speed_duplex;
+ return 0;
+}
- while (test_and_set_bit(__IGC_RESETTING, &adapter->state))
- usleep_range(1000, 2000);
+/**
+ * igc_handle_autoneg_enabled - Configure autonegotiation advertisement
+ * @adapter: private driver structure
+ * @cmd: ethtool link ksettings from user
+ *
+ * Records advertised speeds and flow control settings when autoneg
+ * is enabled.
+ */
+static void igc_handle_autoneg_enabled(struct igc_adapter *adapter,
+ const struct ethtool_link_ksettings *cmd)
+{
+ struct igc_hw *hw = &adapter->hw;
+ u16 advertised = 0;
if (ethtool_link_ksettings_test_link_mode(cmd, advertising,
2500baseT_Full))
@@ -2056,12 +2077,51 @@ igc_ethtool_set_link_ksettings(struct net_device *netdev,
10baseT_Half))
advertised |= ADVERTISE_10_HALF;
- if (cmd->base.autoneg == AUTONEG_ENABLE) {
- hw->phy.autoneg_advertised = advertised;
- if (adapter->fc_autoneg)
- hw->fc.requested_mode = igc_fc_default;
+ hw->mac.autoneg_enabled = true;
+ hw->phy.autoneg_advertised = advertised;
+ if (adapter->fc_autoneg)
+ hw->fc.requested_mode = igc_fc_default;
+}
+
+static int
+igc_ethtool_set_link_ksettings(struct net_device *netdev,
+ const struct ethtool_link_ksettings *cmd)
+{
+ struct igc_adapter *adapter = netdev_priv(netdev);
+ struct net_device *dev = adapter->netdev;
+ struct igc_hw *hw = &adapter->hw;
+
+ /* When adapter in resetting mode, autoneg/speed/duplex
+ * cannot be changed
+ */
+ if (igc_check_reset_block(hw)) {
+ netdev_err(dev, "Cannot change link characteristics when reset is active\n");
+ return -EINVAL;
+ }
+
+ /* MDI setting is only allowed when autoneg enabled because
+ * some hardware doesn't allow MDI setting when speed or
+ * duplex is forced.
+ */
+ if (cmd->base.eth_tp_mdix_ctrl) {
+ if (cmd->base.eth_tp_mdix_ctrl != ETH_TP_MDI_AUTO &&
+ cmd->base.autoneg != AUTONEG_ENABLE) {
+ netdev_err(dev, "Forcing MDI/MDI-X state is not supported when link speed and/or duplex are forced\n");
+ return -EINVAL;
+ }
+ }
+
+ while (test_and_set_bit(__IGC_RESETTING, &adapter->state))
+ usleep_range(1000, 2000);
+
+ if (cmd->base.autoneg == AUTONEG_DISABLE) {
+ if (igc_handle_autoneg_disabled(netdev, cmd->base.speed,
+ cmd->base.duplex)) {
+ clear_bit(__IGC_RESETTING, &adapter->state);
+ return -EINVAL;
+ }
} else {
- netdev_info(dev, "Force mode currently not supported\n");
+ igc_handle_autoneg_enabled(adapter, cmd);
}
/* MDI-X => 2; MDI => 1; Auto => 3 */
diff --git a/drivers/net/ethernet/intel/igc/igc_hw.h b/drivers/net/ethernet/intel/igc/igc_hw.h
index be8a49a86d09..0794139dbc24 100644
--- a/drivers/net/ethernet/intel/igc/igc_hw.h
+++ b/drivers/net/ethernet/intel/igc/igc_hw.h
@@ -73,6 +73,13 @@ struct igc_info {
extern const struct igc_info igc_base_info;
+enum igc_forced_speed_duplex {
+ IGC_FORCED_10H,
+ IGC_FORCED_10F,
+ IGC_FORCED_100H,
+ IGC_FORCED_100F,
+};
+
struct igc_mac_info {
struct igc_mac_operations ops;
@@ -94,6 +101,8 @@ struct igc_mac_info {
bool autoneg_failed;
bool get_link_status;
+ bool autoneg_enabled;
+ enum igc_forced_speed_duplex forced_speed_duplex;
};
struct igc_nvm_operations {
diff --git a/drivers/net/ethernet/intel/igc/igc_mac.c b/drivers/net/ethernet/intel/igc/igc_mac.c
index 7ac6637f8db7..16b0f2db0689 100644
--- a/drivers/net/ethernet/intel/igc/igc_mac.c
+++ b/drivers/net/ethernet/intel/igc/igc_mac.c
@@ -452,7 +452,7 @@ s32 igc_config_fc_after_link_up(struct igc_hw *hw)
* so we had to force link. In this case, we need to force the
* configuration of the MAC to match the "fc" parameter.
*/
- if (mac->autoneg_failed)
+ if (mac->autoneg_failed || !mac->autoneg_enabled)
ret_val = igc_force_mac_fc(hw);
if (ret_val) {
diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethernet/intel/igc/igc_main.c
index 72bc5128d8b8..437e1d1ef1e4 100644
--- a/drivers/net/ethernet/intel/igc/igc_main.c
+++ b/drivers/net/ethernet/intel/igc/igc_main.c
@@ -7298,7 +7298,7 @@ static int igc_probe(struct pci_dev *pdev,
/* Initialize link properties that are user-changeable */
adapter->fc_autoneg = true;
hw->phy.autoneg_advertised = 0xaf;
-
+ hw->mac.autoneg_enabled = true;
hw->fc.requested_mode = igc_fc_default;
hw->fc.current_mode = igc_fc_default;
diff --git a/drivers/net/ethernet/intel/igc/igc_phy.c b/drivers/net/ethernet/intel/igc/igc_phy.c
index 6c4d204aecfa..51870a5c00a6 100644
--- a/drivers/net/ethernet/intel/igc/igc_phy.c
+++ b/drivers/net/ethernet/intel/igc/igc_phy.c
@@ -494,12 +494,20 @@ s32 igc_setup_copper_link(struct igc_hw *hw)
s32 ret_val = 0;
bool link;
- /* Setup autoneg and flow control advertisement and perform
- * autonegotiation.
- */
- ret_val = igc_copper_link_autoneg(hw);
- if (ret_val)
- goto out;
+ if (hw->mac.autoneg_enabled) {
+ /* Setup autoneg and flow control advertisement and perform
+ * autonegotiation.
+ */
+ ret_val = igc_copper_link_autoneg(hw);
+ if (ret_val)
+ goto out;
+ } else {
+ ret_val = hw->phy.ops.force_speed_duplex(hw);
+ if (ret_val) {
+ hw_dbg("Error Forcing Speed/Duplex\n");
+ goto out;
+ }
+ }
/* Check link status. Wait up to 100 microseconds for link to become
* valid.
@@ -778,3 +786,49 @@ u16 igc_read_phy_fw_version(struct igc_hw *hw)
return gphy_version;
}
+
+/**
+ * igc_force_speed_duplex - Force PHY speed and duplex settings
+ * @hw: pointer to the HW structure
+ *
+ * Programs the GPY PHY control register to disable autonegotiation
+ * and force the speed/duplex indicated by hw->mac.forced_speed_duplex.
+ */
+s32 igc_force_speed_duplex(struct igc_hw *hw)
+{
+ enum igc_forced_speed_duplex forced_speed_duplex = hw->mac.forced_speed_duplex;
+ struct igc_phy_info *phy = &hw->phy;
+ u16 phy_ctrl;
+ s32 ret_val;
+
+ ret_val = phy->ops.read_reg(hw, PHY_CONTROL, &phy_ctrl);
+ if (ret_val)
+ return ret_val;
+
+ phy_ctrl &= ~(MII_CR_SPEED_MASK | MII_CR_DUPLEX_EN |
+ MII_CR_AUTO_NEG_EN | MII_CR_RESTART_AUTO_NEG);
+
+ switch (forced_speed_duplex) {
+ case IGC_FORCED_10H:
+ phy_ctrl |= MII_CR_SPEED_10;
+ break;
+ case IGC_FORCED_10F:
+ phy_ctrl |= MII_CR_SPEED_10 | MII_CR_DUPLEX_EN;
+ break;
+ case IGC_FORCED_100H:
+ phy_ctrl |= MII_CR_SPEED_100;
+ break;
+ case IGC_FORCED_100F:
+ phy_ctrl |= MII_CR_SPEED_100 | MII_CR_DUPLEX_EN;
+ break;
+ default:
+ return -IGC_ERR_CONFIG;
+ }
+
+ ret_val = phy->ops.write_reg(hw, PHY_CONTROL, phy_ctrl);
+ if (ret_val)
+ return ret_val;
+
+ hw->mac.get_link_status = true;
+ return 0;
+}
diff --git a/drivers/net/ethernet/intel/igc/igc_phy.h b/drivers/net/ethernet/intel/igc/igc_phy.h
index 832a7e359f18..d37a89174826 100644
--- a/drivers/net/ethernet/intel/igc/igc_phy.h
+++ b/drivers/net/ethernet/intel/igc/igc_phy.h
@@ -18,5 +18,6 @@ void igc_power_down_phy_copper(struct igc_hw *hw);
s32 igc_write_phy_reg_gpy(struct igc_hw *hw, u32 offset, u16 data);
s32 igc_read_phy_reg_gpy(struct igc_hw *hw, u32 offset, u16 *data);
u16 igc_read_phy_fw_version(struct igc_hw *hw);
+s32 igc_force_speed_duplex(struct igc_hw *hw);
#endif
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] net: fix __this_cpu_add() in preemptible code in dev_xmit_recursion_inc/dec
From: Jiayuan Chen @ 2026-04-09 7:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Andrew Lunn, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt, Weiming Shi, linux-kernel,
linux-rt-devel
In-Reply-To: <CANn89iLEpVVo=q4FPpBQ5FomoLmdrfW3su7Mb0ZES4EV9=Q4xA@mail.gmail.com>
On 4/9/26 3:18 PM, Eric Dumazet wrote:
> On Wed, Apr 8, 2026 at 8:54 PM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>> dev_xmit_recursion_inc/dec() use __this_cpu_inc/dec() which requires
>> migration to be disabled. However, some callers like SCTP's UDP
>> encapsulation path invoke iptunnel_xmit() from process context without
>> disabling BH or preemption:
>>
>> sctp_inet_connect -> __sctp_connect -> sctp_do_sm ->
>> sctp_outq_flush -> sctp_packet_transmit -> sctp_v4_xmit ->
>> udp_tunnel_xmit_skb -> iptunnel_xmit -> dev_xmit_recursion_inc
>>
>> This triggers the following warning on PREEMPT(full) kernels:
>>
>>
>> Fix this by adding migrate_disable/enable() around the __this_cpu
>> operations in dev_xmit_recursion_inc/dec() to ensure the per-cpu
>> variable is accessed on the same CPU throughout the inc/dec pair.
>>
>> Fixes: 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions")
>> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
>> ---
>> include/linux/netdevice.h | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>> index 7ca01eb3f7d2..6b1cd5380d70 100644
>> --- a/include/linux/netdevice.h
>> +++ b/include/linux/netdevice.h
>> @@ -3591,14 +3591,19 @@ static inline bool dev_xmit_recursion(void)
>> XMIT_RECURSION_LIMIT);
>> }
>>
>> +/* Non PREEMPT_RT version: inc and dec must run on the same CPU,
>> + * migrate_disable is sufficient.
>> + */
>> static inline void dev_xmit_recursion_inc(void)
>> {
>> + migrate_disable();
>> __this_cpu_inc(softnet_data.xmit.recursion);
>> }
>>
>> static inline void dev_xmit_recursion_dec(void)
>> {
>> __this_cpu_dec(softnet_data.xmit.recursion);
>> + migrate_enable();
>> }
>> #else
>> static inline int dev_recursion_level(void)
>> --
>> 2.43.0
> This seems wrong.
>
> The migrate_disable() should happen before dev_recursion_level().
Thanks
I checked all callers of dev_xmit_recursion_inc(). Most are fine.
The only problematic ones are iptunnel_xmit() and ip6tunnel_xmit(),
I think adding guard(migrate)() at the top of both functions is enough
^ permalink raw reply
* [PATCH iwl-next v2] igb: use ktime_get_real helpers in igb_ptp_reset()
From: Aleksandr Loktionov @ 2026-04-09 7:55 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov
Cc: netdev, Jacob Keller, Simon Horman, Paul Menzel
Replace ktime_to_ns(ktime_get_real()) with the direct equivalent
ktime_get_real_ns() and ktime_to_timespec64(ktime_get_real()) with
ktime_get_real_ts64() in igb_ptp_reset(). Using the combined helpers
makes the intent clearer.
Suggested-by: Jacob Keller <jacob.e.keller@intel.com>
Suggested-by: Simon Horman <horms@kernel.org>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
v1 -> v2 removed the inaccurate claim, + Pauls RB
---
drivers/net/ethernet/intel/igb/igb_ptp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_ptp.c b/drivers/net/ethernet/intel/igb/igb_ptp.c
index bd85d02..638d824 100644
--- a/drivers/net/ethernet/intel/igb/igb_ptp.c
+++ b/drivers/net/ethernet/intel/igb/igb_ptp.c
@@ -1500,12 +1500,13 @@ void igb_ptp_reset(struct igb_adapter *adapter)
/* Re-initialize the timer. */
if ((hw->mac.type == e1000_i210) || (hw->mac.type == e1000_i211)) {
- struct timespec64 ts = ktime_to_timespec64(ktime_get_real());
+ struct timespec64 ts;
+ ktime_get_real_ts64(&ts);
igb_ptp_write_i210(adapter, &ts);
} else {
timecounter_init(&adapter->tc, &adapter->cc,
- ktime_to_ns(ktime_get_real()));
+ ktime_get_real_ns());
}
out:
spin_unlock_irqrestore(&adapter->tmreg_lock, flags);
--
2.52.0
^ permalink raw reply related
* Re: [5/6] arm64: dts: qcom: milos: Add IPA node
From: Paolo Abeni @ 2026-04-09 7:58 UTC (permalink / raw)
To: luca.weiss
Cc: pabeni, krzk+dt, akoskovich, konradybcio, linux-kernel, conor+dt,
devicetree, andersson, netdev, kuba, linux-arm-msm, andrew+netdev,
davem, robh, edumazet, ~postmarketos/upstreaming, phone-devel,
elder
In-Reply-To: <20260403-milos-ipa-v1-5-01e9e4e03d3e@fairphone.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
arm64: dts: qcom: milos: Add IPA node
Add the description of the IPA block in the Milos SoC.
> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> index e1a51d43943f..a244e136a877 100644
> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> @@ -1281,6 +1281,50 @@ adreno_smmu: iommu@3da0000 {
> dma-coherent;
> };
>
> + ipa: ipa@3f40000 {
> + compatible = "qcom,milos-ipa";
> +
> + reg = <0x0 0x03f40000 0x0 0x10000>,
> + <0x0 0x03f50000 0x0 0x5000>,
> + <0x0 0x03e04000 0x0 0xfc000>;
> + reg-names = "ipa-reg",
> + "ipa-shared",
> + "gsi";
> +
> + interrupts-extended = <&intc GIC_SPI 654 IRQ_TYPE_EDGE_RISING 0>,
> + <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH 0>,
> + <&smp2p_ipa_in 0 IRQ_TYPE_EDGE_RISING>,
> + <&smp2p_ipa_in 1 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "ipa",
> + "gsi",
> + "ipa-clock-query",
> + "ipa-setup-ready";
> +
> + clocks = <&rpmhcc RPMH_IPA_CLK>;
> + clock-names = "core";
> +
> + interconnects = <&aggre2_noc MASTER_IPA QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &cnoc_main SLAVE_IPA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "memory",
> + "config";
> +
> + iommus = <&apps_smmu 0x4a0 0x0>,
> + <&apps_smmu 0x4a2 0x0>;
> +
> + qcom,qmp = <&aoss_qmp>;
> +
> + qcom,smem-states = <&smp2p_ipa_out 0>,
> + <&smp2p_ipa_out 1>;
> + qcom,smem-state-names = "ipa-clock-enabled-valid",
> + "ipa-clock-enabled";
> +
> + sram = <&ipa_modem_tables>;
> ^^^^^^^^^^^^^^^^^^
Is the ipa_modem_tables label defined anywhere? The Device Tree Compiler
will fail with "Reference to non-existent node or label
'ipa_modem_tables'" if this label doesn't exist.
The sram property is optional according to the qcom,ipa.yaml binding, and
other similar Qualcomm SoCs like SM8350, SM8550, and SM8650 don't include
this property in their IPA nodes. Should this line be removed, or does the
ipa_modem_tables node need to be added to the reserved-memory section?
> +
> + status = "disabled";
> + };
> +
[ ... ]
^ permalink raw reply
* Re: [5/6] arm64: dts: qcom: milos: Add IPA node
From: Krzysztof Kozlowski @ 2026-04-09 8:00 UTC (permalink / raw)
To: Paolo Abeni, luca.weiss
Cc: krzk+dt, akoskovich, konradybcio, linux-kernel, conor+dt,
devicetree, andersson, netdev, kuba, linux-arm-msm, andrew+netdev,
davem, robh, edumazet, ~postmarketos/upstreaming, phone-devel,
elder
In-Reply-To: <20260409075854.308955-1-pabeni@redhat.com>
On 09/04/2026 09:58, Paolo Abeni wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
...
>> +
>> + qcom,smem-states = <&smp2p_ipa_out 0>,
>> + <&smp2p_ipa_out 1>;
>> + qcom,smem-state-names = "ipa-clock-enabled-valid",
>> + "ipa-clock-enabled";
>> +
>> + sram = <&ipa_modem_tables>;
>> ^^^^^^^^^^^^^^^^^^
>
> Is the ipa_modem_tables label defined anywhere? The Device Tree Compiler
> will fail with "Reference to non-existent node or label
> 'ipa_modem_tables'" if this label doesn't exist.
Paul, please ignore all of such review from AI tools. It is completely
wrong and pointless.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/6] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: patchwork-bot+netdevbpf @ 2026-04-09 8:00 UTC (permalink / raw)
To: Luca Weiss
Cc: elder, andrew+netdev, davem, edumazet, kuba, pabeni, robh,
krzk+dt, conor+dt, andersson, konradybcio, akoskovich,
~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 03 Apr 2026 18:43:46 +0200 you wrote:
> First, two fixes that unbreak IPA v5.0+, which can be applied
> independently.
>
> Then add support for IPA v5.2 which can be found in the Milos SoC. And
> finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
> starts working.
>
> [...]
Here is the summary with links:
- [1/6] net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+
https://git.kernel.org/netdev/net/c/9709b56d908a
- [2/6] net: ipa: fix event ring index not programmed for IPA v5.0+
https://git.kernel.org/netdev/net/c/56007972c0b1
- [3/6] dt-bindings: net: qcom,ipa: add Milos compatible
(no matching commit)
- [4/6] net: ipa: add IPA v5.2 configuration data
(no matching commit)
- [5/6] arm64: dts: qcom: milos: Add IPA node
(no matching commit)
- [6/6] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v4 net-next 10/14] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Vladimir Oltean @ 2026-04-09 8:07 UTC (permalink / raw)
To: Wei Fang
Cc: Jakub Kicinski, Claudiu Manoil, Clark Wang, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
f.fainelli@gmail.com, Frank Li, chleroy@kernel.org,
horms@kernel.org, linux@armlinux.org.uk, andrew@lunn.ch,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <AM8PR04MB72840DBFC7F3FD578DFF6AF8885BA@AM8PR04MB7284.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 11:59:24AM +0300, Wei Fang wrote:
> > > +static int netc_init_switch_id(struct netc_switch *priv)
> > > +{
> > > + struct netc_switch_regs *regs = &priv->regs;
> > > + struct dsa_switch *ds = priv->ds;
> > > +
> > > + /* The value of 0 is reserved for the VEPA switch and cannot
> > > + * be used.
> > > + */
> > > + if (ds->index > SWCR_SWID || !ds->index) {
> > > + dev_err(priv->dev, "Switch index %d out of range\n",
> > > + ds->index);
> > > + return -ERANGE;
> > > + }
> >
> > Does this check cause the probe to fail unconditionally for standard
> > single-switch topologies?
> >
> > The DSA core typically assigns ds->index = 0 by default for the first switch.
> > Because !ds->index evaluates to true for index 0, this setup function will
> > always fail unless the dsa,member property is explicitly overridden in the
> > device tree.
>
> As I mentioned in another mail, we added the 'dsa,member' property to the
> netc switch DT-binding doc, specifying that the 'member' (switch index) value
> cannot be 0. And 'dsa,member' is a required property for netc switch.
>
> >
> > Could the driver translate the hardware ID internally, for example by writing
> > ds->index + 1 to NETC_SWCR, rather than forcing this hardware-specific
> > restriction onto the software DSA index?
>
> The current approach is based on Vladimir's suggestion. I need to confirm with
> Vladimir which approach is better.
>
> Hi Vladimir,
>
> What are your thoughts on this suggestion? Is this approach better?
I maintain it is preferable/simpler the way you are doing it, with a 1:1 mapping.
The LLM's concern would be more valid if the switch were discrete and every
board DTS author would have to remember to place the dsa,member property.
But the switch OF node will live in an SoC dtsi.
Maybe you could put something along these lines in the commit message,
hopefully the LLM will pick it up and stop complaining.
^ permalink raw reply
* Re: [PATCH net] net: fix __this_cpu_add() in preemptible code in dev_xmit_recursion_inc/dec
From: Eric Dumazet @ 2026-04-09 8:10 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, David S. Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, Andrew Lunn, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt, Weiming Shi, linux-kernel,
linux-rt-devel
In-Reply-To: <8c761de0-4d8c-4b2e-89a6-80f12016fd78@linux.dev>
On Thu, Apr 9, 2026 at 12:50 AM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
> Thanks
>
> I checked all callers of dev_xmit_recursion_inc(). Most are fine.
>
> The only problematic ones are iptunnel_xmit() and ip6tunnel_xmit(),
>
> I think adding guard(migrate)() at the top of both functions is enough
Seems fine to me, thanks.
^ permalink raw reply
* Re: [PATCH] gcov: use atomic counter updates to fix concurrent access crashes
From: Peter Oberparleiter @ 2026-04-09 8:11 UTC (permalink / raw)
To: Nathan Chancellor, Konstantin Khorenko, Andrew Morton
Cc: Mikhail Zaslonko, Nicolas Schier, Masahiro Yamada,
Thomas Weißschuh, Arnd Bergmann, Steffen Klassert,
Herbert Xu, linux-kbuild, linux-kernel, netdev, Pavel Tikhomirov,
Vasileios Almpanis, Jakub Kicinski
In-Reply-To: <20260406193707.GB1319599@ax162>
On 06.04.2026 21:37, Nathan Chancellor wrote:
> On Thu, Apr 02, 2026 at 05:18:31PM +0300, Konstantin Khorenko wrote:
>> GCC's GCOV instrumentation can merge global branch counters with loop
>> induction variables as an optimization. In inflate_fast(), the inner
>> copy loops get transformed so that the GCOV counter value is loaded
>> multiple times to compute the loop base address, start index, and end
>> bound. Since GCOV counters are global (not per-CPU), concurrent
>> execution on different CPUs causes the counter to change between loads,
>> producing inconsistent values and out-of-bounds memory writes.
>>
>> The crash manifests during IPComp (IP Payload Compression) processing
>> when inflate_fast() runs concurrently on multiple CPUs:
>>
>> BUG: unable to handle page fault for address: ffffd0a3c0902ffa
>> RIP: inflate_fast+1431
>> Call Trace:
>> zlib_inflate
>> __deflate_decompress
>> crypto_comp_decompress
>> ipcomp_decompress [xfrm_ipcomp]
>> ipcomp_input [xfrm_ipcomp]
>> xfrm_input
>>
>> At the crash point, the compiler generated three loads from the same
>> global GCOV counter (__gcov0.inflate_fast+216) to compute base, start,
>> and end for an indexed loop. Another CPU modified the counter between
>> loads, making the values inconsistent — the write went 3.4 MB past a
>> 65 KB buffer.
>>
>> Add -fprofile-update=atomic to CFLAGS_GCOV at the global level in the
>> top-level Makefile. This tells GCC that GCOV counters may be
>> concurrently accessed, causing counter updates to use atomic
>> instructions (lock addq) instead of plain load/store. This prevents
>> the compiler from merging counters with loop induction variables.
>>
>> Applying this globally rather than per-subsystem not only addresses the
>> observed crash in zlib but makes GCOV coverage data more consistent
>> overall, preventing similar issues in any kernel code path that may
>> execute concurrently.
>>
>> Signed-off-by: Konstantin Khorenko <khorenko@virtuozzo.com>
>> Tested-by: Peter Oberparleiter <oberpar@linux.ibm.com>
>> Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
>
> While this is obviously a fix, what are the chances of regressions from
> this change? As this should only impact GCOV, this could go via whatever
> tree carries GCOV patches. If Kbuild is to take this change, my vote
> would be to defer it to 7.2 at this point in the development cycle so
> that it can have most of a cycle to sit in -next.
Adding Andrew since he typically integrates GCOV patches via his tree,
and for input on how to handle this patch.
To summarize the situation, this patch:
- is only effective with GCC + GCOV profiling enabled
- fixes a run-time crash
- improves overall GCOV coverage data consistency
- triggers a number of build errors due to side-effects on GCC constant
folding and therefore depends on the associated series [1] that fixes
these build-errors
- has a non-zero chance to trigger additional build-time errors, e.g.
in similar macros guarded by arch/config symbols not covered by
current testing
Given the last point, I agree with Nathan that this patch would benefit
from additional test coverage to minimize regression risks, e.g. via a
cycle in -next.
[1]
https://lore.kernel.org/lkml/20260402140558.1437002-1-khorenko@virtuozzo.com/
>> ---
>> Makefile | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Makefile b/Makefile
>> index 6b1d9fb1a6b4..a55ad668d6ba 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -806,7 +806,7 @@ all: vmlinux
>>
>> CFLAGS_GCOV := -fprofile-arcs -ftest-coverage
>> ifdef CONFIG_CC_IS_GCC
>> -CFLAGS_GCOV += -fno-tree-loop-im
>> +CFLAGS_GCOV += -fno-tree-loop-im -fprofile-update=atomic
>> endif
>> export CFLAGS_GCOV
>>
>> --
>> 2.43.5
>>
--
Peter Oberparleiter
Linux on IBM Z Development - IBM Germany R&D
^ permalink raw reply
* [PATCH net 0/2] More fixes for the IPA driver
From: Luca Weiss @ 2026-04-09 8:13 UTC (permalink / raw)
To: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-arm-msm,
linux-kernel, Luca Weiss
Two more fixes for the Qualcomm IPA driver.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Luca Weiss (2):
net: ipa: Fix programming of QTIME_TIMESTAMP_CFG
net: ipa: Fix decoding EV_PER_EE for IPA v5.0+
drivers/net/ipa/gsi.c | 1 +
drivers/net/ipa/ipa_main.c | 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
---
base-commit: 56007972c0b1e783ca714d6f1f4d6e66e531d21f
change-id: 20260409-ipa-fixes-a575cf2810df
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply
* [PATCH net 1/2] net: ipa: Fix programming of QTIME_TIMESTAMP_CFG
From: Luca Weiss @ 2026-04-09 8:13 UTC (permalink / raw)
To: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-arm-msm,
linux-kernel, Luca Weiss
In-Reply-To: <20260409-ipa-fixes-v1-0-a817c30678ac@fairphone.com>
The 'val' variable gets overwritten multiple times, discarding previous
values. Looking at the git log shows these should be combined with |=
instead.
Fixes: 9265a4f0f0b4 ("net: ipa: define even more IPA register fields")
Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=4
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
drivers/net/ipa/ipa_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
index edead9c48d1f..216506eeef1f 100644
--- a/drivers/net/ipa/ipa_main.c
+++ b/drivers/net/ipa/ipa_main.c
@@ -361,7 +361,7 @@ static void ipa_qtime_config(struct ipa *ipa)
{
const struct reg *reg;
u32 offset;
- u32 val;
+ u32 val = 0;
/* Timer clock divider must be disabled when we change the rate */
reg = ipa_reg(ipa, TIMERS_XO_CLK_DIV_CFG);
@@ -374,8 +374,8 @@ static void ipa_qtime_config(struct ipa *ipa)
val |= reg_bit(reg, DPL_TIMESTAMP_SEL);
}
/* Configure tag and NAT Qtime timestamp resolution as well */
- val = reg_encode(reg, TAG_TIMESTAMP_LSB, TAG_TIMESTAMP_SHIFT);
- val = reg_encode(reg, NAT_TIMESTAMP_LSB, NAT_TIMESTAMP_SHIFT);
+ val |= reg_encode(reg, TAG_TIMESTAMP_LSB, TAG_TIMESTAMP_SHIFT);
+ val |= reg_encode(reg, NAT_TIMESTAMP_LSB, NAT_TIMESTAMP_SHIFT);
iowrite32(val, ipa->reg_virt + reg_offset(reg));
--
2.53.0
^ permalink raw reply related
* [PATCH net 2/2] net: ipa: Fix decoding EV_PER_EE for IPA v5.0+
From: Luca Weiss @ 2026-04-09 8:13 UTC (permalink / raw)
To: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-arm-msm,
linux-kernel, Luca Weiss
In-Reply-To: <20260409-ipa-fixes-v1-0-a817c30678ac@fairphone.com>
Initially 'reg' and 'val' are assigned from HW_PARAM_2.
But since IPA v5.0+ takes EV_PER_EE from HW_PARAM_4 (instead of
NUM_EV_PER_EE from HW_PARAM_2), we not only need to re-assign 'reg' but
also read the register value of that register into 'val' so that
reg_decode() works on the correct value.
Fixes: f651334e1ef5 ("net: ipa: add HW_PARAM_4 GSI register")
Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=2
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
drivers/net/ipa/gsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ipa/gsi.c b/drivers/net/ipa/gsi.c
index 4c3227e77898..624649484d62 100644
--- a/drivers/net/ipa/gsi.c
+++ b/drivers/net/ipa/gsi.c
@@ -2044,6 +2044,7 @@ static int gsi_ring_setup(struct gsi *gsi)
count = reg_decode(reg, NUM_EV_PER_EE, val);
} else {
reg = gsi_reg(gsi, HW_PARAM_4);
+ val = ioread32(gsi->virt + reg_offset(reg));
count = reg_decode(reg, EV_PER_EE, val);
}
if (!count) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next] l2tp: Drop large packets with UDP encap
From: Paolo Abeni @ 2026-04-09 8:15 UTC (permalink / raw)
To: Alice Mikityanska, Simon Horman
Cc: Alice Mikityanska, David S. Miller, Eric Dumazet, Jakub Kicinski,
James Chapman, netdev, syzbot+ci3edea60a44225dec
In-Reply-To: <CAD0BsJU8-NBeAGn_rPD-woZARNZ8vb6uJGMDNf70syRkzKiL4A@mail.gmail.com>
On 4/8/26 7:11 PM, Alice Mikityanska wrote:
> On Wed, 8 Apr 2026 at 19:48, Simon Horman <horms@kernel.org> wrote:
>> On Fri, Apr 03, 2026 at 08:49:49PM +0300, Alice Mikityanska wrote:
>>> From: Alice Mikityanska <alice@isovalent.com>
>>>
>>> syzbot reported a WARN on my patch series [1]. The actual issue is an
>>> overflow of 16-bit UDP length field, and it exists in the upstream code.
>>> My series added a debug WARN with an overflow check that exposed the
>>> issue, that's why syzbot tripped on my patches, rather than on upstream
>>> code.
>>>
>>> syzbot's repro:
>>>
>>> # {"procs":1,"slowdown":1,"sandbox":"","sandbox_arg":0,"close_fds":false,"callcomments":true}
>>> r0 = socket$pppl2tp(0x18, 0x1, 0x1)
>>> r1 = socket$inet6_udp(0xa, 0x2, 0x0)
>>> connect$inet6(r1, &(0x7f00000000c0)={0xa, 0x0, 0x0, @loopback, 0xfffffffc}, 0x1c)
>>> connect$pppl2tp(r0, &(0x7f0000000240)=@pppol2tpin6={0x18, 0x1, {0x0, r1, 0x4, 0x0, 0x0, 0x0, {0xa, 0x4e22, 0xffff, @ipv4={'\x00', '\xff\xff', @empty}}}}, 0x32)
>>> writev(r0, &(0x7f0000000080)=[{&(0x7f0000000000)="ee", 0x34000}], 0x1)
>>>
>>> It basically sends an oversized (0x34000 bytes) PPPoL2TP packet with UDP
>>> encapsulation, and l2tp_xmit_core doesn't check for overflows when it
>>> assigns the UDP length field. The value gets trimmed to 16 bites.
>>>
>>> Add an overflow check that drops oversized packets and avoids sending
>>> packets with trimmed UDP length to the wire.
>>>
>>> syzbot's stack trace (with my patch applied):
>>>
>>> len >= 65536u
>>> WARNING: ./include/linux/udp.h:38 at udp_set_len_short include/linux/udp.h:38 [inline], CPU#1: syz.0.17/5957
>>> WARNING: ./include/linux/udp.h:38 at l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline], CPU#1: syz.0.17/5957
>>> WARNING: ./include/linux/udp.h:38 at l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327, CPU#1: syz.0.17/5957
>>> Modules linked in:
>>> CPU: 1 UID: 0 PID: 5957 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)
>>> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
>>> RIP: 0010:udp_set_len_short include/linux/udp.h:38 [inline]
>>> RIP: 0010:l2tp_xmit_core net/l2tp/l2tp_core.c:1293 [inline]
>>> RIP: 0010:l2tp_xmit_skb+0x1204/0x18d0 net/l2tp/l2tp_core.c:1327
>>> Code: 0f 0b 90 e9 21 f9 ff ff e8 e9 05 ec f6 90 0f 0b 90 e9 8d f9 ff ff e8 db 05 ec f6 90 0f 0b 90 e9 cc f9 ff ff e8 cd 05 ec f6 90 <0f> 0b 90 e9 de fa ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 0f 8c 4f
>>> RSP: 0018:ffffc90003d67878 EFLAGS: 00010293
>>> RAX: ffffffff8ad985e3 RBX: ffff8881a6400090 RCX: ffff8881697f0000
>>> RDX: 0000000000000000 RSI: 0000000000034010 RDI: 000000000000ffff
>>> RBP: dffffc0000000000 R08: 0000000000000003 R09: 0000000000000004
>>> R10: dffffc0000000000 R11: fffff520007acf00 R12: ffff8881baf20900
>>> R13: 0000000000034010 R14: ffff8881a640008e R15: ffff8881760f7000
>>> FS: 000055557e81f500(0000) GS:ffff8882a9467000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 0000200000033000 CR3: 00000001612f4000 CR4: 00000000000006f0
>>> Call Trace:
>>> <TASK>
>>> pppol2tp_sendmsg+0x40a/0x5f0 net/l2tp/l2tp_ppp.c:302
>>> sock_sendmsg_nosec net/socket.c:727 [inline]
>>> __sock_sendmsg net/socket.c:742 [inline]
>>> sock_write_iter+0x503/0x550 net/socket.c:1195
>>> do_iter_readv_writev+0x619/0x8c0 fs/read_write.c:-1
>>> vfs_writev+0x33c/0x990 fs/read_write.c:1059
>>> do_writev+0x154/0x2e0 fs/read_write.c:1105
>>> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>>> do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
>>> entry_SYSCALL_64_after_hwframe+0x77/0x7f
>>> RIP: 0033:0x7f636479c629
>>> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
>>> RSP: 002b:00007ffffd4241c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
>>> RAX: ffffffffffffffda RBX: 00007f6364a15fa0 RCX: 00007f636479c629
>>> RDX: 0000000000000001 RSI: 0000200000000080 RDI: 0000000000000003
>>> RBP: 00007f6364832b39 R08: 0000000000000000 R09: 0000000000000000
>>> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
>>> R13: 00007f6364a15fac R14: 00007f6364a15fa0 R15: 00007f6364a15fa0
>>> </TASK>
>>>
>>> [1]: https://lore.kernel.org/all/20260226201600.222044-1-alice.kernel@fastmail.im/
>>>
>>> Reported-by: syzbot+ci3edea60a44225dec@syzkaller.appspotmail.com
>>> Closes: https://lore.kernel.org/netdev/69a1dfba.050a0220.3a55be.0026.GAE@google.com/
>>
>> Hi Alice,
>>
>> A Fixes tag needs to go here.
>> And if it's fixing code present in net - that is, the bug can manifest
>> there - then it should be targeted at net rather than net-next.
>
> Thanks for the review! I submitted to net-next, because I wanted to
> piggy-back my net-next series on top of this fix without making a
> merge conflict, and the bug didn't look that critical to go to net
> (sometimes I received feedback that my bugfixes should have been
> submitted to -next).
The expected workflow in this case is: submit the fix(es) to net, wait
for the following net -> net-next cross merge (happens on Thursday),
submit the dependent net-next patch(es).
> I can resubmit to net, if it's something that
> deserves backporting, or the maintainers can apply it to net instead.
> For the Fixes tag, I can take the closest commit:
>
> Fixes: 0d76751fad77 ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support")
>
> It's old enough (2010) to cover all supported LTS kernels. Or I can go
> as deep as:
>
> Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core")
It looks like the correct fix tag is the latter. The patch LGTM and
given the current PW status, I'm applying it to net without a repost.
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH net 1/2] net: ipa: Fix programming of QTIME_TIMESTAMP_CFG
From: Konrad Dybcio @ 2026-04-09 8:17 UTC (permalink / raw)
To: Luca Weiss, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-arm-msm,
linux-kernel
In-Reply-To: <20260409-ipa-fixes-v1-1-a817c30678ac@fairphone.com>
On 4/9/26 10:13 AM, Luca Weiss wrote:
> The 'val' variable gets overwritten multiple times, discarding previous
> values. Looking at the git log shows these should be combined with |=
> instead.
>
> Fixes: 9265a4f0f0b4 ("net: ipa: define even more IPA register fields")
> Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=4
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Ha, nice!
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH net 2/2] net: ipa: Fix decoding EV_PER_EE for IPA v5.0+
From: Konrad Dybcio @ 2026-04-09 8:18 UTC (permalink / raw)
To: Luca Weiss, Alex Elder, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: ~postmarketos/upstreaming, phone-devel, netdev, linux-arm-msm,
linux-kernel
In-Reply-To: <20260409-ipa-fixes-v1-2-a817c30678ac@fairphone.com>
On 4/9/26 10:13 AM, Luca Weiss wrote:
> Initially 'reg' and 'val' are assigned from HW_PARAM_2.
>
> But since IPA v5.0+ takes EV_PER_EE from HW_PARAM_4 (instead of
> NUM_EV_PER_EE from HW_PARAM_2), we not only need to re-assign 'reg' but
> also read the register value of that register into 'val' so that
> reg_decode() works on the correct value.
>
> Fixes: f651334e1ef5 ("net: ipa: add HW_PARAM_4 GSI register")
> Link: https://sashiko.dev/#/patchset/20260403-milos-ipa-v1-0-01e9e4e03d3e%40fairphone.com?part=2
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net-next v1 2/2] ice: add 0x88E7 handling to SW validation paths
From: Romanowski, Rafal @ 2026-04-09 8:21 UTC (permalink / raw)
To: Loktionov, Aleksandr, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L, Loktionov, Aleksandr
Cc: netdev@vger.kernel.org
In-Reply-To: <20260318080737.3012293-3-aleksandr.loktionov@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Aleksandr Loktionov
> Sent: Wednesday, March 18, 2026 9:08 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>
> Cc: netdev@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net-next v1 2/2] ice: add 0x88E7 handling to
> SW validation paths
>
> The virtchnl v2 VLAN capability handshake now includes the new
> VIRTCHNL_VLAN_ETHERTYPE_88E7 flag for IEEE 802.1ah B-TAG support.
> Wire up the corresponding software-path handling in ice so the PF correctly
> accepts and translates 0x88E7 (ETH_P_8021AH) VLAN filters requested by VFs.
>
> Three software-only changes, no hardware offload path affected:
>
> - ice_check_supported_vlan_tpid() (ice_tc_lib.c): accept ETH_P_8021AH
> in the TC VLAN TPID validation switch so 0x88E7-tagged flower filters
> are not rejected early.
>
> - validate_vlan() (ice_vsi_vlan_lib.c): allow ETH_P_8021AH as a valid
> TPID when adding VLAN filters to a VSI, consistent with the other
> accepted dot1q/dot1ad/QinQ1 TPIDs.
>
> - ice_vc_validate_vlan_tpid() / ice_vc_get_tpid() (virt/virtchnl.c):
> bidirectional translation between ETH_P_8021AH and
> VIRTCHNL_VLAN_ETHERTYPE_88E7 in the virtchnl VLAN v2 filter path.
>
> This does not add 0x88E7 hardware offload capability, does not change outer-tag
> programming, and does not alter any datapath.
>
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/ice/ice_tc_lib.c | 1 +
> drivers/net/ethernet/intel/ice/ice_vsi_vlan_lib.c | 3 ++-
> drivers/net/ethernet/intel/ice/virt/virtchnl.c | 6 ++++++
> 3 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> index d20357c..4560e55 100644
> --- a/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_tc_lib.c
> @@ -174,6 +174,7 @@ static u16 ice_check_supported_vlan_tpid(u16 vlan_tpid)
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
^ permalink raw reply
* Re: [PATCH 6/6] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
From: Luca Weiss @ 2026-04-09 8:26 UTC (permalink / raw)
To: Dmitry Baryshkov, Luca Weiss
Cc: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich,
~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <ku4w5dbfk4ihxfslyf7lcxtxnbzabim5mmtm7xlhqbnmav36iv@zt3dky3vbfbo>
Hi Dmitry,
On Fri Apr 3, 2026 at 9:27 PM CEST, Dmitry Baryshkov wrote:
> On Fri, Apr 03, 2026 at 06:43:52PM +0200, Luca Weiss wrote:
>> Configure and enable the node for IPA which enables mobile data on this
>> device.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> index c1899db46e71..31c6d6627619 100644
>> --- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> +++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> @@ -690,6 +690,15 @@ vreg_l7p: ldo7 {
>> /* AW86938FCR vibrator @ 0x5a */
>> };
>>
>> +&ipa {
>> + firmware-name = "qcom/milos/fairphone/fp6/ipa_fws.mbn";
>> + memory-region = <&ipa_fw_mem>;
>> +
>> + qcom,gsi-loader = "self";
>
> Are these two common to all Milos devices? Should they be a part of the
> milos.dtsi?
All qcom,gsi-loader properties are in device .dts (or device-common
.dtsi) files, never in SoC .dtsi files. Based on this, I guess it would
mostly differ based on the boot firmware used. If Linux is booted in
EL2, then probably it needs to be changed?
Regards
Luca
^ permalink raw reply
* Re: [PATCH net-next] l2tp: Drop large packets with UDP encap
From: patchwork-bot+netdevbpf @ 2026-04-09 8:30 UTC (permalink / raw)
To: Alice Mikityanska
Cc: davem, edumazet, kuba, pabeni, horms, jchapman, netdev, alice,
syzbot+ci3edea60a44225dec
In-Reply-To: <20260403174949.843941-1-alice.kernel@fastmail.im>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 3 Apr 2026 20:49:49 +0300 you wrote:
> From: Alice Mikityanska <alice@isovalent.com>
>
> syzbot reported a WARN on my patch series [1]. The actual issue is an
> overflow of 16-bit UDP length field, and it exists in the upstream code.
> My series added a debug WARN with an overflow check that exposed the
> issue, that's why syzbot tripped on my patches, rather than on upstream
> code.
>
> [...]
Here is the summary with links:
- [net-next] l2tp: Drop large packets with UDP encap
https://git.kernel.org/netdev/net/c/ebe560ea5f54
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: move .getsockopt away from __user buffers
From: Stefan Metzmacher @ 2026-04-09 8:39 UTC (permalink / raw)
To: David Laight, Breno Leitao
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, axboe,
Stanislav Fomichev, io-uring, bpf, netdev, Linus Torvalds,
linux-kernel, kernel-team
In-Reply-To: <3fd4bf27-344f-45fc-bca3-9e9676522972@samba.org>
Am 08.04.26 um 15:56 schrieb Stefan Metzmacher:
> Am 08.04.26 um 13:26 schrieb David Laight:
>> On Wed, 08 Apr 2026 03:30:28 -0700
>> Breno Leitao <leitao@debian.org> wrote:
>>
>>> Currently, the .getsockopt callback requires __user pointers:
>>>
>>> int (*getsockopt)(struct socket *sock, int level,
>>> int optname, char __user *optval, int __user *optlen);
>>>
>>> This prevents kernel callers (io_uring, BPF) from using getsockopt on
>>> levels other than SOL_SOCKET, since they pass kernel pointers.
>>>
>>> Following Linus' suggestion [0], this series introduces sockopt_t, a
>>> type-safe wrapper around iov_iter, and a getsockopt_iter callback that
>>> works with both user and kernel buffers. AF_PACKET and CAN raw are
>>> converted as initial users, with selftests covering the trickiest
>>> conversion patterns.
>>
>> What are you doing about the cases where 'optlen' is a complete lie?
>> IIRC there is one related to some form of async io where it is just
>> the length of the header, the actual buffer length depends on
>> data in the header.
>> This doesn't matter with the existing code for applications, when they
>> get it wrong they just crash.
>> But kernel users will need to pass the actual buffer length separately
>> from optlen.
>> It also affects any code that tries to cache the actual data and copy
>> it back to userspace in the syscall wrapper - which makes sense for
>> most short getsockopt.
>>
>> (This is different from historic code where the length might be
>> assumed to be 4 regardless of what was passed.)
>
> As the insane legacy cases can only happen for keeping
> compatibility with existing userspace applications,
> we could get the original optval and optlen __user pointers
> out of sockopt_t again via something like:
>
> char __user * __must_check sockopt_get_insame_legacy_optval(sockopt_t *sopt);
> int __user * __must_check sockopt_get_insame_legacy_optlen(sockopt_t *sopt);
>
> And for kernel callers they return NULL and the code should
> turn that into -EINVAL or something similar.
Or better helper macros/inline functions to call the legacy implementations.
something like this:
int sockopt_call_legacy_sock_fn(struct socket *sock, int level, int optname, sockopt_t *sopt,
int kernel_errno,
int (*legacy_fn)(struct socket *sock, int level,
int optname, char __user *optval, int __user *optlen))
{
if (!sopt->legacy.optlen)
return kernel_errno;
return legacy_fn(sock, level, optname, sopt->legacy.optval, sopt->legacy.optlen);
}
And a similar sockopt_call_legacy_sk_fn() that takes struct sock instead of struct socket.
That way it would be relatively easy to move the calls of sockopt_call_legacy_{sock,sk}_fn
down the stack to the places where it's really needed in incremental steps.
^ permalink raw reply
* Re: [PATCH net-next v9 00/10] net: phy_port: SFP modules representation and phy_port listing
From: Maxime Chevallier @ 2026-04-09 8:40 UTC (permalink / raw)
To: Paolo Abeni, davem, Andrew Lunn, Jakub Kicinski, Eric Dumazet,
Russell King, Heiner Kallweit
Cc: netdev, linux-kernel, thomas.petazzoni, Christophe Leroy,
Herve Codina, Florian Fainelli, Vladimir Oltean,
Köry Maincent, Marek Behún, Oleksij Rempel,
Nicolò Veronese, Simon Horman, mwojtas, Romain Gantois,
Daniel Golle, Dimitri Fedrau
In-Reply-To: <76e290cd-22bd-4ed3-b2b3-036e1edff140@redhat.com>
On 09/04/2026 09:35, Paolo Abeni wrote:
> @Maxime: I went over sashiko feedback and I *think* it ranges from
> orthogonal to wrong, but it would be useful if you could go over it.
Yeah I've looked at its feedback, and indeed most of it is incorrect or
irrelevant :(
Let's see if the PHY crew have things to say on the overall approach :)
Thanks for pinging on this,
Maxime
>
> Thanks,
>
> Paolo
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net] ice: Fix missing 1's complement negation in GCS raw checksum
From: Loktionov, Aleksandr @ 2026-04-09 8:45 UTC (permalink / raw)
To: Matt Fleming, Nguyen, Anthony L, Kitszel, Przemyslaw
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@cloudflare.com, Matt Fleming
In-Reply-To: <20260408190214.1287708-1-matt@readmodwrite.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Matt Fleming
> Sent: Wednesday, April 8, 2026 9:02 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>; David S . Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; intel-
> wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; kernel-team@cloudflare.com; Matt Fleming
> <mfleming@cloudflare.com>
> Subject: [Intel-wired-lan] [PATCH net] ice: Fix missing 1's complement
> negation in GCS raw checksum
>
> From: Matt Fleming <mfleming@cloudflare.com>
>
> Commit 905d1a220e8d ("ice: Add E830 checksum offload support") added
> Generic Checksum (GCS) support for E830 NICs but omitted the 1's
> complement negation (~) when converting the hardware raw_csum to
> skb->csum for CHECKSUM_COMPLETE.
>
> Without the negation, every CHECKSUM_COMPLETE packet fails the fast-
> path validation in nf_ip_checksum() and falls through to software
> checksumming via __skb_checksum_complete(), which triggers the rate-
> limited "hw csum failure" warning. Packets are still accepted (the
> software recheck passes) but hardware checksum offload is effectively
> disabled and the warning floods dmesg on systems running nf_conntrack
> on VLAN sub-interfaces.
>
> Multiple other drivers (idpf, ehea, iwlwifi, cassini, sunhme, enetc)
> also apply ~ for CHECKSUM_COMPLETE. The ice driver was the only in-
> tree user of csum_unfold() for CHECKSUM_COMPLETE that omitted it.
>
> Fixes: 905d1a220e8d ("ice: Add E830 checksum offload support")
> Signed-off-by: Matt Fleming <mfleming@cloudflare.com>
> ---
> drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> index e695a664e53d..c177579e0114 100644
> --- a/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_txrx_lib.c
> @@ -92,7 +92,7 @@ static void ice_rx_gcs(struct sk_buff *skb,
> desc = (struct ice_32b_rx_flex_desc_nic *)rx_desc;
> skb->ip_summed = CHECKSUM_COMPLETE;
> csum = (__force u16)desc->raw_csum;
> - skb->csum = csum_unfold((__force __sum16)swab16(csum));
> + skb->csum = csum_unfold((__force __sum16)~swab16(csum));
> }
>
> /**
> --
> 2.43.0
I'd recommend adding Cc: stable@vger.kernel.org
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH 3/5] uaccess: add copy_struct_{from,to}_bounce_buffer() helpers
From: Stefan Metzmacher @ 2026-04-09 8:47 UTC (permalink / raw)
To: David Laight
Cc: linux-kernel, Dmitry Safonov, Dmitry Safonov, Francesco Ruggeri,
Salam Noureddine, David Ahern, David S . Miller, Michal Luczaj,
David Wei, Luiz Augusto von Dentz, Luiz Augusto von Dentz,
Marcel Holtmann, Xin Long, Eric Dumazet, Kuniyuki Iwashima,
Paolo Abeni, Willem de Bruijn, Neal Cardwell, Jakub Kicinski,
Simon Horman, Aleksa Sarai, Christian Brauner, Kees Cook, netdev,
linux-bluetooth
In-Reply-To: <20260407192540.321f3879@pumpkin>
Hi David,
> On Tue, 7 Apr 2026 18:03:15 +0200
> Stefan Metzmacher <metze@samba.org> wrote:
>
>> These are similar to copy_struct_{from,to}_user() but operate
>> on kernel buffers instead of user buffers.
>>
>> They can be used when there is a temporary bounce buffer used,
>> e.g. in msg_control or similar places.
>>
>> It allows us to have the same logic to handle old vs. current
>> and current vs. new structures in the same compatible way.
>>
>> copy_struct_from_sockptr() will also be able to
>> use copy_struct_from_bounce_buffer() for the kernel
>> case as follow us patch.
>>
>> I'll use this in my IPPROTO_SMBDIRECT work,
>> but maybe it will also be useful for others...
>> IPPROTO_QUIC will likely also use it.
>>
>> Cc: Dmitry Safonov <0x7f454c46@gmail.com>
>> Cc: Dmitry Safonov <dima@arista.com>
>> Cc: Francesco Ruggeri <fruggeri@arista.com>
>> Cc: Salam Noureddine <noureddine@arista.com>
>> Cc: David Ahern <dsahern@kernel.org>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Michal Luczaj <mhal@rbox.co>
>> Cc: David Wei <dw@davidwei.uk>
>> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
>> Cc: Marcel Holtmann <marcel@holtmann.org>
>> Cc: Xin Long <lucien.xin@gmail.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Cc: Kuniyuki Iwashima <kuniyu@google.com>
>> Cc: Paolo Abeni <pabeni@redhat.com>
>> Cc: Willem de Bruijn <willemb@google.com>
>> Cc: Neal Cardwell <ncardwell@google.com>
>> Cc: Jakub Kicinski <kuba@kernel.org>
>> Cc: Simon Horman <horms@kernel.org>
>> Cc: Aleksa Sarai <cyphar@cyphar.com>
>> Cc: Christian Brauner <brauner@kernel.org>
>> CC: Kees Cook <keescook@chromium.org>
>> Cc: netdev@vger.kernel.org
>> Cc: linux-bluetooth@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Stefan Metzmacher <metze@samba.org>
>> ---
>> include/linux/uaccess.h | 63 +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 63 insertions(+)
>>
>> diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
>> index 1234b5fa4761..a6cd4f48bb99 100644
>> --- a/include/linux/uaccess.h
>> +++ b/include/linux/uaccess.h
>> @@ -513,6 +513,69 @@ copy_struct_to_user(void __user *dst, size_t usize, const void *src,
>> return 0;
>> }
>>
>> +static __always_inline void
>> +__copy_struct_generic_bounce_buffer(void *dst, size_t dstsize,
>> + const void *src, size_t srcsize,
>> + bool *ignored_trailing)
>> +{
>> + size_t size = min(dstsize, srcsize);
>> + size_t rest = max(dstsize, srcsize) - size;
>> +
>> + /* Deal with trailing bytes. */
>> + if (dstsize > srcsize)
>> + memset(dst + size, 0, rest);
>> + if (ignored_trailing)
>> + *ignored_trailing = dstsize < srcsize &&
>> + memchr_inv(src + size, 0, rest) != NULL;
>> + /* Copy the interoperable parts of the struct. */
>> + memcpy(dst, src, size);
>> +}
>
> Return 'ignored_trailing' rather than pass by reference.
I also thought about that but it makes
the copy_struct_to_ case more complex.
I'm not sure but my guess would be that
the compiler would have the chance to skip the
ignore_trailing logic if (as all current callers do)
NULL is passed.
> And this is probably too big to inline.
In the next patch this replace open coded logic in
copy_struct_from_sockptr. So as all of copy_struct_*
consists of inline functions I thought it would be good to
keep it that way.
So unless there a real good reason to change it
I'd like to keep it as is.
Thanks!
metze
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox