* [PATCH net-next v1 3/5] net/fsl: xgmac_mdio: Switch to using fwnode_mdiobus_register()
From: Andy Shevchenko @ 2026-05-04 7:29 UTC (permalink / raw)
To: Andy Shevchenko, linux-kernel, netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Heiner Kallweit, Russell King
In-Reply-To: <20260504074610.40799-1-andriy.shevchenko@linux.intel.com>
Replace custom implementation of fwnode_mdiobus_register().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/freescale/xgmac_mdio.c | 13 +++----------
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/freescale/xgmac_mdio.c b/drivers/net/ethernet/freescale/xgmac_mdio.c
index 65dc07d0df0f..b63c8a3d6daf 100644
--- a/drivers/net/ethernet/freescale/xgmac_mdio.c
+++ b/drivers/net/ethernet/freescale/xgmac_mdio.c
@@ -13,14 +13,13 @@
*/
#include <linux/acpi.h>
-#include <linux/acpi_mdio.h>
#include <linux/clk.h>
+#include <linux/fwnode_mdio.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/mdio.h>
#include <linux/module.h>
#include <linux/of.h>
-#include <linux/of_mdio.h>
#include <linux/phy.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
@@ -370,7 +369,7 @@ static void xgmac_mdio_set_suppress_preamble(struct mii_bus *bus)
static int xgmac_mdio_probe(struct platform_device *pdev)
{
- struct fwnode_handle *fwnode;
+ struct fwnode_handle *fwnode = dev_fwnode(&pdev->dev);
struct mdio_fsl_priv *priv;
struct resource *res;
struct mii_bus *bus;
@@ -422,13 +421,7 @@ static int xgmac_mdio_probe(struct platform_device *pdev)
if (ret)
return ret;
- fwnode = dev_fwnode(&pdev->dev);
- if (is_of_node(fwnode))
- ret = of_mdiobus_register(bus, to_of_node(fwnode));
- else if (is_acpi_node(fwnode))
- ret = acpi_mdiobus_register(bus, fwnode);
- else
- ret = -EINVAL;
+ ret = fwnode_mdiobus_register(bus, fwnode);
if (ret) {
dev_err(&pdev->dev, "cannot register MDIO bus\n");
return ret;
--
2.50.1
^ permalink raw reply related
* [PATCH net-next v1 2/5] net: mvmdio: Switch to using fwnode_mdiobus_register()
From: Andy Shevchenko @ 2026-05-04 7:29 UTC (permalink / raw)
To: Andy Shevchenko, linux-kernel, netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Heiner Kallweit, Russell King
In-Reply-To: <20260504074610.40799-1-andriy.shevchenko@linux.intel.com>
Replace custom implementation of fwnode_mdiobus_register().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/ethernet/marvell/mvmdio.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvmdio.c b/drivers/net/ethernet/marvell/mvmdio.c
index 3f4447e68888..62fbe22c01cb 100644
--- a/drivers/net/ethernet/marvell/mvmdio.c
+++ b/drivers/net/ethernet/marvell/mvmdio.c
@@ -18,16 +18,15 @@
*/
#include <linux/acpi.h>
-#include <linux/acpi_mdio.h>
#include <linux/clk.h>
#include <linux/delay.h>
+#include <linux/fwnode_mdio.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/iopoll.h>
#include <linux/kernel.h>
#include <linux/mod_devicetable.h>
#include <linux/module.h>
-#include <linux/of_mdio.h>
#include <linux/phy.h>
#include <linux/platform_device.h>
#include <linux/sched.h>
@@ -379,13 +378,7 @@ static int orion_mdio_probe(struct platform_device *pdev)
goto out_mdio;
}
- /* For the platforms not supporting DT/ACPI fall-back
- * to mdiobus_register via of_mdiobus_register.
- */
- if (is_acpi_node(pdev->dev.fwnode))
- ret = acpi_mdiobus_register(bus, pdev->dev.fwnode);
- else
- ret = of_mdiobus_register(bus, pdev->dev.of_node);
+ ret = fwnode_mdiobus_register(bus, dev_fwnode(&pdev->dev));
if (ret < 0) {
dev_err(&pdev->dev, "Cannot register MDIO bus (%d)\n", ret);
goto out_mdio;
--
2.50.1
^ permalink raw reply related
* [PATCH net-next v1 1/5] net: mdiobus: Provide fwnode_mdiobus_register()
From: Andy Shevchenko @ 2026-05-04 7:29 UTC (permalink / raw)
To: Andy Shevchenko, linux-kernel, netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Heiner Kallweit, Russell King
In-Reply-To: <20260504074610.40799-1-andriy.shevchenko@linux.intel.com>
Provide an agnostic helper to register MDIO bus independently on
the firmware node provider.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/mdio/fwnode_mdio.c | 15 +++++++++++++++
include/linux/fwnode_mdio.h | 17 +++++++++++++++++
2 files changed, 32 insertions(+)
diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
index ba7091518265..7541df43ba6d 100644
--- a/drivers/net/mdio/fwnode_mdio.c
+++ b/drivers/net/mdio/fwnode_mdio.c
@@ -7,9 +7,11 @@
*/
#include <linux/acpi.h>
+#include <linux/acpi_mdio.h>
#include <linux/dev_printk.h>
#include <linux/fwnode_mdio.h>
#include <linux/of.h>
+#include <linux/of_mdio.h>
#include <linux/phy.h>
#include <linux/pse-pd/pse.h>
@@ -187,3 +189,16 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
return rc;
}
EXPORT_SYMBOL(fwnode_mdiobus_register_phy);
+
+int __fwnode_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *fwnode,
+ struct module *owner)
+{
+ if (is_of_node(fwnode))
+ return __of_mdiobus_register(mdio, to_of_node(fwnode), owner);
+
+ if (is_acpi_node(fwnode))
+ return __acpi_mdiobus_register(mdio, fwnode, owner);
+
+ return mdiobus_register(mdio);
+}
+EXPORT_SYMBOL(__fwnode_mdiobus_register);
diff --git a/include/linux/fwnode_mdio.h b/include/linux/fwnode_mdio.h
index faf603c48c86..c316b738333a 100644
--- a/include/linux/fwnode_mdio.h
+++ b/include/linux/fwnode_mdio.h
@@ -16,6 +16,14 @@ int fwnode_mdiobus_phy_device_register(struct mii_bus *mdio,
int fwnode_mdiobus_register_phy(struct mii_bus *bus,
struct fwnode_handle *child, u32 addr);
+int __fwnode_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *fwnode,
+ struct module *owner);
+
+static inline int
+fwnode_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *fwnode)
+{
+ return __fwnode_mdiobus_register(mdio, fwnode, THIS_MODULE);
+}
#else /* CONFIG_FWNODE_MDIO */
int fwnode_mdiobus_phy_device_register(struct mii_bus *mdio,
struct phy_device *phy,
@@ -30,6 +38,15 @@ static inline int fwnode_mdiobus_register_phy(struct mii_bus *bus,
{
return -EINVAL;
}
+
+static inline int fwnode_mdiobus_register(struct mii_bus *mdio, struct
+ fwnode_handle *fwnode)
+{
+ /* Fall back to mdiobus_register() function to register a bus.
+ * This way, we don't have to keep compat bits around in drivers.
+ */
+ return mdiobus_register(mdio);
+}
#endif
#endif /* __LINUX_FWNODE_MDIO_H */
--
2.50.1
^ permalink raw reply related
* [PATCH net-next v1 5/5] net: mdiobus: Hide acpi_mdio.h
From: Andy Shevchenko @ 2026-05-04 7:29 UTC (permalink / raw)
To: Andy Shevchenko, linux-kernel, netdev
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Heiner Kallweit, Russell King
In-Reply-To: <20260504074610.40799-1-andriy.shevchenko@linux.intel.com>
No more users outside of MDIO framework.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
drivers/net/mdio/acpi_mdio.c | 3 ++-
drivers/net/mdio/fwnode_mdio.c | 3 ++-
drivers/net/mdio/mdio.h | 4 ++++
include/linux/acpi_mdio.h | 33 ---------------------------------
4 files changed, 8 insertions(+), 35 deletions(-)
create mode 100644 drivers/net/mdio/mdio.h
delete mode 100644 include/linux/acpi_mdio.h
diff --git a/drivers/net/mdio/acpi_mdio.c b/drivers/net/mdio/acpi_mdio.c
index 5d0f11f280cf..15c3fc05fad5 100644
--- a/drivers/net/mdio/acpi_mdio.c
+++ b/drivers/net/mdio/acpi_mdio.c
@@ -7,13 +7,14 @@
*/
#include <linux/acpi.h>
-#include <linux/acpi_mdio.h>
#include <linux/bits.h>
#include <linux/dev_printk.h>
#include <linux/fwnode_mdio.h>
#include <linux/module.h>
#include <linux/types.h>
+#include "mdio.h"
+
MODULE_AUTHOR("Calvin Johnson <calvin.johnson@oss.nxp.com>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("ACPI MDIO bus (Ethernet PHY) accessors");
diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
index 7541df43ba6d..610753d55262 100644
--- a/drivers/net/mdio/fwnode_mdio.c
+++ b/drivers/net/mdio/fwnode_mdio.c
@@ -7,7 +7,6 @@
*/
#include <linux/acpi.h>
-#include <linux/acpi_mdio.h>
#include <linux/dev_printk.h>
#include <linux/fwnode_mdio.h>
#include <linux/of.h>
@@ -15,6 +14,8 @@
#include <linux/phy.h>
#include <linux/pse-pd/pse.h>
+#include "mdio.h"
+
MODULE_AUTHOR("Calvin Johnson <calvin.johnson@oss.nxp.com>");
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("FWNODE MDIO bus (Ethernet PHY) accessors");
diff --git a/drivers/net/mdio/mdio.h b/drivers/net/mdio/mdio.h
new file mode 100644
index 000000000000..c053bb05368a
--- /dev/null
+++ b/drivers/net/mdio/mdio.h
@@ -0,0 +1,4 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+
+int __acpi_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *fwnode,
+ struct module *owner);
diff --git a/include/linux/acpi_mdio.h b/include/linux/acpi_mdio.h
deleted file mode 100644
index 8e2eefa9fbc0..000000000000
--- a/include/linux/acpi_mdio.h
+++ /dev/null
@@ -1,33 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-/*
- * ACPI helper for the MDIO (Ethernet PHY) API
- */
-
-#ifndef __LINUX_ACPI_MDIO_H
-#define __LINUX_ACPI_MDIO_H
-
-#include <linux/phy.h>
-
-#if IS_ENABLED(CONFIG_ACPI_MDIO)
-int __acpi_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *fwnode,
- struct module *owner);
-
-static inline int
-acpi_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *handle)
-{
- return __acpi_mdiobus_register(mdio, handle, THIS_MODULE);
-}
-#else /* CONFIG_ACPI_MDIO */
-static inline int
-acpi_mdiobus_register(struct mii_bus *mdio, struct fwnode_handle *fwnode)
-{
- /*
- * Fall back to mdiobus_register() function to register a bus.
- * This way, we don't have to keep compat bits around in drivers.
- */
-
- return mdiobus_register(mdio);
-}
-#endif
-
-#endif /* __LINUX_ACPI_MDIO_H */
--
2.50.1
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH iwl-net] ice: reject out-of-range ptype in ice_parser_profile_init
From: Loktionov, Aleksandr @ 2026-05-04 7:47 UTC (permalink / raw)
To: Paul Menzel
Cc: intel-wired-lan@lists.osuosl.org, Nguyen, Anthony L,
netdev@vger.kernel.org
In-Reply-To: <1737f22d-1eca-4dee-95cc-6bd397e655dc@molgen.mpg.de>
> -----Original Message-----
> From: Paul Menzel <pmenzel@molgen.mpg.de>
> Sent: Thursday, April 30, 2026 7:21 PM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; netdev@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net] ice: reject out-of-
> range ptype in ice_parser_profile_init
>
> Dear Aleksandr,
>
>
> Thank you for your patch.
>
> Am 30.04.26 um 16:21 schrieb Aleksandr Loktionov:
> > set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of
> > ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from
> > providing ptype >= 1024 through VIRTCHNL, resulting in a write past
> > the end of the bitmap and a kernel page fault.
> >
> > Reproduced with a custom kernel module injecting a crafted
> > VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91
> 0x800214af
> > 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1.
>
> 7.1-rc1 (no need to resend)
>
> > crash_parser: ice_parser_profile_init @ ffffffffc0d61b60
> > crash_parser: setting ptype=0xffff (max valid=1023)
> > crash_parser: calling ice_parser_profile_init -- expect OOB crash!
> > BUG: kernel NULL pointer dereference, address: 0000000000000000
> > #PF: supervisor write access in kernel mode
> > #PF: error_code(0x0002) - not-present page
> > Oops: Oops: 0002 [#1] SMP NOPTI
> > CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U
> > OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB
> > RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace:
> > <TASK>
> > ? __pfx_ice_parser_profile_init+0x10/0x10 [ice]
> > crash_init+0x127/0xff0 [crash_parser]
> > do_one_initcall+0x45/0x310
> > do_init_module+0x64/0x270
> > init_module_from_file+0xcc/0xf0
> > idempotent_init_module+0x17b/0x280
> > __x64_sys_finit_module+0x6e/0xe0
> >
> > Bail out early with -EINVAL when ptype is out of range.
>
> Is a warning logged now?
This error is potentially possible to generate from VM via modified iavf driver.
I think it's not a good idea to let user other than admin to spam host dmesg.
I couldn’t find a good example of such logging for other AQ packets types.
Do you have a good reason?
Thank you
>
> > Fixes: e312b3a1e209 ("ice: add API for parser profile
> initialization")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> > ---
> > drivers/net/ethernet/intel/ice/ice_parser.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/ethernet/intel/ice/ice_parser.c
> > b/drivers/net/ethernet/intel/ice/ice_parser.c
> > index f8e6963..3ede4c1 100644
> > --- a/drivers/net/ethernet/intel/ice/ice_parser.c
> > +++ b/drivers/net/ethernet/intel/ice/ice_parser.c
> > @@ -2368,6 +2368,9 @@ int ice_parser_profile_init(struct
> ice_parser_result *rslt,
> > u16 proto_off = 0;
> > u16 off;
> >
> > + if (rslt->ptype >= ICE_FLOW_PTYPE_MAX)
> > + return -EINVAL;
> > +
> > memset(prof, 0, sizeof(*prof));
> > set_bit(rslt->ptype, prof->ptypes);
> > if (blk == ICE_BLK_SW) {
>
>
> Kind regards,
>
> Paul
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: Add Shikra pinctrl driver
From: Komal Bajaj @ 2026-05-04 7:50 UTC (permalink / raw)
To: Maulik Shah (mkshah), Bjorn Andersson, Linus Walleij, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Richard Cochran
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel, netdev
In-Reply-To: <38bb1b79-67da-4a23-a0e8-3c3da77933d7@oss.qualcomm.com>
On 4/30/2026 9:36 AM, Maulik Shah (mkshah) wrote:
>
> On 4/29/2026 6:41 PM, Komal Bajaj wrote:
>> Add pinctrl driver for TLMM block found in Shikra SoC.
>
> [...]
>
>> +#define UFS_RESET(pg_name, ctl, io) \
>> + { \
>> + .grp = PINCTRL_PINGROUP(#pg_name, \
>> + pg_name##_pins, \
>> + ARRAY_SIZE(pg_name##_pins)), \
>> + .ctl_reg = ctl, \
>> + .io_reg = io, \
>> + .intr_cfg_reg = 0, \
>> + .intr_status_reg = 0, \
>> + .mux_bit = -1, \
>> + .pull_bit = 3, \
>> + .drv_bit = 0, \
>> + .oe_bit = -1, \
>> + .in_bit = -1, \
>> + .out_bit = 0, \
>> + .intr_enable_bit = -1, \
>> + .intr_status_bit = -1, \
>> + .intr_target_bit = -1, \
>> + .intr_raw_status_bit = -1, \
>> + .intr_polarity_bit = -1, \
>> + .intr_detection_bit = -1, \
>> + .intr_detection_width = -1, \
>> + }
> UFS_RESET macro is not used anywhere in the file, please remove it.
>
> I assume the macro keeps getting added since the file pinctrl-<target> is
> fully/partially auto generated. Would be good to fix auto generation to
> avoid getting this added as default in future.
>
> The unused ones were removed via [1].
>
> [1] https://lore.kernel.org/all/4429f44e-f7e5-449c-824c-83daa339b383@oss.qualcomm.com/
>
> [...]
>
Thanks Maulik for review, will update the driver to cleanup unused
macros in next version.
>> +static const struct msm_gpio_wakeirq_map shikra_mpm_map[] = {
>> + {1, 9}, {2, 31}, {5, 49}, {6, 53}, {9, 72}, {10, 10},
> It would be better to have spacing before/after brackets inline with other pinctrl drivers.
> {1, 9}, should be { 1, 9 }.
Noted.
Thanks
Komal
>
>> + {12, 22}, {14, 26}, {17, 29}, {18, 24}, {20, 32}, {22, 33},
>> + {25, 34}, {27, 35}, {28, 36}, {29, 37}, {30, 38}, {31, 39},
>> + {32, 40}, {33, 41}, {38, 42}, {40, 43}, {43, 44}, {44, 45},
>> + {45, 46}, {46, 47}, {47, 48}, {48, 60}, {50, 50}, {51, 51},
>> + {52, 61}, {53, 62}, {57, 52}, {58, 63}, {60, 54}, {63, 64},
>> + {73, 55}, {74, 56}, {75, 57}, {77, 3}, {80, 4}, {84, 5},
>> + {85, 67}, {86, 69}, {88, 70}, {89, 71}, {90, 73}, {91, 74},
>> + {92, 75}, {93, 76}, {94, 77}, {95, 78}, {97, 79}, {99, 80},
>> + {100, 11}, {101, 13}, {102, 14}, {103, 15}, {106, 16}, {108, 17},
>> + {112, 18}, {116, 19}, {117, 20}, {119, 21}, {120, 23}, {136, 25},
>> + {159, 27}, {161, 28},
>> +};
>> +
> Thanks,
> Maulik
>
^ permalink raw reply
* Re: [BUG] KASAN: slab-use-after-free in __sk_msg_recvmsg
From: Kuniyuki Iwashima @ 2026-05-04 7:52 UTC (permalink / raw)
To: eulgyukim
Cc: bpf, byoungyoung, davem, edumazet, horms, jakub, jjy600901,
john.fastabend, kuba, linux-kernel, netdev, pabeni
In-Reply-To: <20260504072325.23474-1-eulgyukim@snu.ac.kr>
From: Eulgyu Kim <eulgyukim@snu.ac.kr>
Date: Mon, 4 May 2026 16:23:25 +0900
> Hello,
>
> We encountered a "KASAN: slab-use-after-free in __sk_msg_recvmsg"
> on kernel version v7.1.0-rc1.
>
> As this issue was identified via fuzzing and we have limited background,
> we find it challenging to identify the exact root cause or propose a correct fix.
> Therefore, please consider the following analysis as a best-effort guess,
> which may still be incomplete or incorrect.
>
> The issue is that sk_psock_peek_msg() only protects the list lookup; after it
> drops ingress_lock, the returned sk_msg can be concurrently consumed and freed
> by another recvmsg caller.
>
> Following is the harmful sequence:
>
> 1. Thread A calls recvmmsg() on the socket and reaches __sk_msg_recvmsg()
> through udp_bpf_recvmsg() -> sk_msg_recvmsg() -> __sk_msg_recvmsg().
>
> 2. __sk_msg_recvmsg() calls sk_psock_peek_msg() and obtains msg_rx, the
> first struct sk_msg on psock->ingress_msg. The ingress_lock is dropped
> immediately after the peek.
>
> 3. Thread A copies data to userspace and still holds local pointers to
> msg_rx and sge = sk_msg_elem(msg_rx, i), but has not yet updated
> sge->offset/sge->length or dequeued the message.
>
> 4. Thread B concurrently calls recvmmsg() on the same socket.
>
> 5. Because udp_bpf_recvmsg() does not hold a per-socket receive lock,
This reminds me that I forgot to respin this series.
https://lore.kernel.org/bpf/20260221233234.3814768-1-kuniyu@google.com/
I'll rebase and respin it.
^ permalink raw reply
* Re: [PATCH net] xfrm: esp: avoid in-place decrypt on shared skb frags
From: Steffen Klassert @ 2026-05-04 7:53 UTC (permalink / raw)
To: HexRabbit
Cc: netdev, Greg Kroah-Hartman, Herbert Xu, Simon Horman,
David S . Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ido Schimmel, linux-kernel, Hyunwoo Kim
In-Reply-To: <20260504073403.38854-1-h3xrabbit@gmail.com>
We have antoher patch that addresses this issue in a different way,
so Cc the author of the other patch.
On Mon, May 04, 2026 at 03:34:03PM +0800, HexRabbit wrote:
> From: Kuan-Ting Chen <h3xrabbit@gmail.com>
>
> MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP
> marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),
> so later paths that may modify packet data can first make a private
> copy. The IPv4/IPv6 datagram append paths did not set this flag when
> splicing pages into UDP skbs.
>
> That leaves an ESP-in-UDP packet made from shared pipe pages looking
> like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW
> fast path for uncloned skbs without a frag_list and decrypts in place
> over data that is not owned privately by the skb.
>
> Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching
> TCP. Also make ESP input fall back to skb_cow_data() when the flag is
> present, so ESP does not decrypt externally backed frags in place.
> Private nonlinear skb frags still use the existing fast path.
>
> This intentionally does not change ESP output. In esp_output_head(),
> the path that appends the ESP trailer to existing skb tailroom without
> calling skb_cow_data() is not reachable for nonlinear skbs:
> skb_tailroom() returns zero when skb->data_len is nonzero, while ESP
> tailen is positive. Thus ESP output will either use the separate
> destination-frag path or fall back to skb_cow_data().
>
> Signed-off-by: Kuan-Ting Chen <h3xrabbit@gmail.com>
> ---
> net/ipv4/esp4.c | 3 ++-
> net/ipv4/ip_output.c | 2 ++
> net/ipv6/esp6.c | 3 ++-
> net/ipv6/ip6_output.c | 2 ++
> 4 files changed, 8 insertions(+), 2 deletions(-)
This looks ok to me. From the IPsec point of view, I'm
fine with this patch, but it also touches generic
networking code. So I'd like to hear an opinion of one
of the networking maintainers before proceeding.
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: Add Shikra pinctrl driver
From: Komal Bajaj @ 2026-05-04 7:53 UTC (permalink / raw)
To: Konrad Dybcio, Maulik Shah (mkshah), Bjorn Andersson,
Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel, netdev
In-Reply-To: <bf1e9880-745e-4c7b-bfde-3c5ac39175fc@oss.qualcomm.com>
On 4/30/2026 4:24 PM, Konrad Dybcio wrote:
> On 4/30/26 6:06 AM, Maulik Shah (mkshah) wrote:
>>
>> On 4/29/2026 6:41 PM, Komal Bajaj wrote:
>>> Add pinctrl driver for TLMM block found in Shikra SoC.
> [...]
>
>
>>> +static const struct msm_gpio_wakeirq_map shikra_mpm_map[] = {
>>> + {1, 9}, {2, 31}, {5, 49}, {6, 53}, {9, 72}, {10, 10},
>> It would be better to have spacing before/after brackets inline with other pinctrl drivers.
>> {1, 9}, should be { 1, 9 }.
> If that's also something that the generator takes care of, let's fix
> it there too
Sure, we will try to take care of this in the generator to avoid such
cases going forward.
Thanks
Komal
>
> Konrad
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: Add Shikra pinctrl driver
From: Komal Bajaj @ 2026-05-04 7:56 UTC (permalink / raw)
To: Linus Walleij
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, linux-arm-msm, linux-gpio, devicetree,
linux-kernel, netdev
In-Reply-To: <CAD++jLnDc_Myjt4TKUHZAqYqVwO37TaRO6t23ABew0M5VnzJWg@mail.gmail.com>
On 4/30/2026 5:21 PM, Linus Walleij wrote:
> On Wed, Apr 29, 2026 at 3:12 PM Komal Bajaj
> <komal.bajaj@oss.qualcomm.com> wrote:
>
>> Add pinctrl driver for TLMM block found in Shikra SoC.
>>
>> Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
> (...)
>> +config PINCTRL_SHIKRA
>> + tristate "Qualcomm Technologies Inc Shikra pin controller driver"
> Those descriptions are changed in my devel branch, should be something
> like "Qualcomm Shikra pin controller driver".
Will make the changes as suggested in the next revision.
Thanks
Komal
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH net] xfrm: esp: avoid in-place decrypt on shared skb frags
From: Eric Dumazet @ 2026-05-04 7:56 UTC (permalink / raw)
To: Steffen Klassert
Cc: HexRabbit, netdev, Greg Kroah-Hartman, Herbert Xu, Simon Horman,
David S . Miller, David Ahern, Jakub Kicinski, Paolo Abeni,
Ido Schimmel, linux-kernel, Hyunwoo Kim
In-Reply-To: <afhQjlpmt2agPcRE@secunet.com>
On Mon, May 4, 2026 at 12:53 AM Steffen Klassert
<steffen.klassert@secunet.com> wrote:
>
> We have antoher patch that addresses this issue in a different way,
> so Cc the author of the other patch.
>
> On Mon, May 04, 2026 at 03:34:03PM +0800, HexRabbit wrote:
> > From: Kuan-Ting Chen <h3xrabbit@gmail.com>
> >
> > MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP
> > marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),
> > so later paths that may modify packet data can first make a private
> > copy. The IPv4/IPv6 datagram append paths did not set this flag when
> > splicing pages into UDP skbs.
> >
> > That leaves an ESP-in-UDP packet made from shared pipe pages looking
> > like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW
> > fast path for uncloned skbs without a frag_list and decrypts in place
> > over data that is not owned privately by the skb.
> >
> > Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching
> > TCP. Also make ESP input fall back to skb_cow_data() when the flag is
> > present, so ESP does not decrypt externally backed frags in place.
> > Private nonlinear skb frags still use the existing fast path.
> >
> > This intentionally does not change ESP output. In esp_output_head(),
> > the path that appends the ESP trailer to existing skb tailroom without
> > calling skb_cow_data() is not reachable for nonlinear skbs:
> > skb_tailroom() returns zero when skb->data_len is nonzero, while ESP
> > tailen is positive. Thus ESP output will either use the separate
> > destination-frag path or fall back to skb_cow_data().
> >
> > Signed-off-by: Kuan-Ting Chen <h3xrabbit@gmail.com>
> > ---
> > net/ipv4/esp4.c | 3 ++-
> > net/ipv4/ip_output.c | 2 ++
> > net/ipv6/esp6.c | 3 ++-
> > net/ipv6/ip6_output.c | 2 ++
> > 4 files changed, 8 insertions(+), 2 deletions(-)
>
> This looks ok to me. From the IPsec point of view, I'm
> fine with this patch, but it also touches generic
> networking code. So I'd like to hear an opinion of one
> of the networking maintainers before proceeding.
I have not seen a Fixes: tag.
Do we need to split this patch into two parts?
^ permalink raw reply
* Re: [PATCH v7 phy-next 08/27] PCI: Remove device links to PHY
From: Vladimir Oltean @ 2026-05-04 7:57 UTC (permalink / raw)
To: linux-phy, Bjorn Helgaas
Cc: Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Vignesh Raghavendra,
Siddharth Vadapalli
In-Reply-To: <20260430110652.558622-9-vladimir.oltean@nxp.com>
Sashiko says:
> commit e4f495a9118b40f8a77e8dc097821d2c846ed1fc
> Author: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> PCI: Remove device links to PHY
> This commit removes device links between the PCIe controllers and PHY
> providers across several drivers, since the PHY core already creates consumer
> device links.
>
> > diff --git a/drivers/pci/controller/cadence/pcie-cadence-plat.c b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> > index b067a3296dd37..fc39c01b79648 100644
> > --- a/drivers/pci/controller/cadence/pcie-cadence-plat.c
> > +++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> [ ... ]
> > @@ -122,9 +121,6 @@ static int cdns_plat_pcie_probe(struct platform_device *pdev)
> > pm_runtime_put_sync(dev);
> > pm_runtime_disable(dev);
> > cdns_pcie_disable_phy(cdns_plat_pcie->pcie);
> > - phy_count = cdns_plat_pcie->pcie->phy_count;
> > - while (phy_count--)
> > - device_link_del(cdns_plat_pcie->pcie->link[phy_count]);
> >
> > return 0;
>
> This isn't a bug introduced by your patch, but I noticed the error path in
> cdns_plat_pcie_probe() returns 0.
> Does this cause the driver core to consider the probe successful even when
> host or endpoint setup steps fail? It looks like the device would be left
> in an uninitialized and disabled state while still being bound to the driver.
> Should this return ret instead?
>
The condition does not appear intentional. Commit bd22885aa188 ("PCI:
cadence: Refactor driver to use as a core library") changed
cdns_pcie_host_probe() which properly returned ret on error with
cdns_plat_pcie_probe() which doesn't.
I will add a preparatory patch which replaces "return 0" with "return ret"
in cdns_plat_pcie_probe(), blaming that commit.
> > }
> > diff --git a/drivers/pci/controller/dwc/pci-dra7xx.c b/drivers/pci/controller/dwc/pci-dra7xx.c
> > index cd904659c3216..9c1aef4d0bd1c 100644
> > --- a/drivers/pci/controller/dwc/pci-dra7xx.c
> > +++ b/drivers/pci/controller/dwc/pci-dra7xx.c
> [ ... ]
> > @@ -852,10 +840,6 @@ static int dra7xx_pcie_probe(struct platform_device *pdev)
> > pm_runtime_disable(dev);
> > dra7xx_pcie_disable_phy(dra7xx);
> >
> > -err_link:
> > - while (--i >= 0)
> > - device_link_del(link[i]);
> > -
> > return ret;
> > }
>
> This isn't a bug introduced by your changes, but looking closely at the error
> path right above this hunk, there is a call to pm_runtime_put(dev) immediately
> followed by pm_runtime_disable(dev):
> err_gpio:
> err_get_sync:
> pm_runtime_put(dev);
> pm_runtime_disable(dev);
> Does this sequence create a power management race condition? The pending
> asynchronous idle/suspend work can be abruptly cancelled by
> pm_runtime_disable(), leaving the hardware in an incorrect or unpredictable
> power state.
> Should this use pm_runtime_put_sync() instead?
>
> > diff --git a/drivers/pci/controller/dwc/pci-keystone.c b/drivers/pci/controller/dwc/pci-keystone.c
> > index fe4836925c4e3..cab9fad212add 100644
> > --- a/drivers/pci/controller/dwc/pci-keystone.c
> > +++ b/drivers/pci/controller/dwc/pci-keystone.c
> [ ... ]
> > @@ -1337,25 +1321,18 @@ static int ks_pcie_probe(struct platform_device *pdev)
> > pm_runtime_disable(dev);
> > ks_pcie_disable_phy(ks_pcie);
> >
> > -err_link:
> > - while (--i >= 0 && link[i])
> > - device_link_del(link[i]);
> > -
> > +err:
> > return ret;
> > }
> >
> > static void ks_pcie_remove(struct platform_device *pdev)
> > {
> > struct keystone_pcie *ks_pcie = platform_get_drvdata(pdev);
> > - struct device_link **link = ks_pcie->link;
> > - int num_lanes = ks_pcie->num_lanes;
> > struct device *dev = &pdev->dev;
> >
> > pm_runtime_put(dev);
> > pm_runtime_disable(dev);
>
> Similar to the question above, is it possible this asynchronous put causes
> a race when immediately followed by pm_runtime_disable() during removal?
>
> > ks_pcie_disable_phy(ks_pcie);
> > - while (num_lanes--)
> > - device_link_del(link[num_lanes]);
> > }
It seems plausible that the pm_runtime_put() -> pm_runtime_disable()
pattern is ineffective, i.e. one of two things can happen: either
pm_runtime_put() runs to completion by chance, or pm_runtime_disable()
cancels it. However I am not very familiar with the runtime PM API and
its effects, and unless a maintainer tells me to, I would prefer leaving
these code paths alone.
^ permalink raw reply
* Re: [PATCH 1/6] lib: include crc32.h conditionally on CONFIG_CRC32
From: Arnd Bergmann @ 2026-05-04 8:03 UTC (permalink / raw)
To: Yury Norov, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yury Norov, Rasmus Villemoes, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Morton, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend, Stanislav Fomichev,
Ruan Jinjie, linux-kernel, linux-riscv, Linux-Arch, Netdev, bpf
Cc: Nathan Chancellor
In-Reply-To: <20260430211351.658193-2-ynorov@nvidia.com>
On Thu, Apr 30, 2026, at 23:13, Yury Norov wrote:
> Currently, bitreverse API is either declared based on
> CONFIG_HAVE_ARCH_BITREVERSE, wired to arch implementation, or if the
> arch has no bitreverse, based on generic implementation.
>
> So, regardless of CONFIG_BITREVERSE=n, the corresponding API is always
> declared. If that happens, the functions become declared but not
> implemented, which is an error.
I'm not following that description. Why is it an error to declare
a funtion that is not implemented? Isn't that how optional interfaces
tend to work in general?
> The only header requiring the crc32 and bitreverse prototypes is
> include/linux/etherdevice.h. Thus, protect inclusion of corresponding
> headers in the etherdevice with CONFIG_CRC32, together with the only
> function depending on it.
...
> #include <linux/if_ether.h>
> #include <linux/netdevice.h>
> #include <linux/random.h>
> +#ifdef CONFIG_CRC32
> #include <linux/crc32.h>
> +#endif
> #include <linux/unaligned.h>
> #include <asm/bitsperlong.h>
Don't add #ifdef blocks around headers. If the header cannot
be included without side-effects, change the linux/crc32.h
file instead of its users.
It looks like the problem is the check for CONFIG_GENERIC_BITREVERSE
in include/asm-generic/bitops/__bitrev.h, which ends up
hinding the generic___bitrev32() helper without need.
Simply removing the #ifdef there should avoid the build failure.
> +#ifdef CONFIG_CRC32
> /**
> * eth_hw_addr_crc - Calculate CRC from netdev_hw_addr
> * @ha: pointer to hardware address
> @@ -291,6 +294,7 @@ static inline u32 eth_hw_addr_crc(struct netdev_hw_addr *ha)
> {
> return ether_crc(ETH_ALEN, ha->addr);
> }
> +#endif
I see there are only user users of this function, neither of
them are performance critical. So the other options would
be to either open-code this function in the two callers
and remove it entirely, or move it into net/ethernet/eth.c.
Arnd
^ permalink raw reply
* Re: [PATCH net] xfrm: esp: avoid in-place decrypt on shared skb frags
From: Steffen Klassert @ 2026-05-04 8:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: HexRabbit, netdev, Greg Kroah-Hartman, Herbert Xu, Simon Horman,
David S . Miller, David Ahern, Jakub Kicinski, Paolo Abeni,
Ido Schimmel, linux-kernel, Hyunwoo Kim
In-Reply-To: <CANn89iLeX5eZuH6c=_HcADzgejYzE36HhFxmvg+2U3gqsOqHkg@mail.gmail.com>
On Mon, May 04, 2026 at 12:56:50AM -0700, Eric Dumazet wrote:
> On Mon, May 4, 2026 at 12:53 AM Steffen Klassert
> <steffen.klassert@secunet.com> wrote:
> >
> > We have antoher patch that addresses this issue in a different way,
> > so Cc the author of the other patch.
> >
> > On Mon, May 04, 2026 at 03:34:03PM +0800, HexRabbit wrote:
> > > From: Kuan-Ting Chen <h3xrabbit@gmail.com>
> > >
> > > MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP
> > > marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),
> > > so later paths that may modify packet data can first make a private
> > > copy. The IPv4/IPv6 datagram append paths did not set this flag when
> > > splicing pages into UDP skbs.
> > >
> > > That leaves an ESP-in-UDP packet made from shared pipe pages looking
> > > like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW
> > > fast path for uncloned skbs without a frag_list and decrypts in place
> > > over data that is not owned privately by the skb.
> > >
> > > Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching
> > > TCP. Also make ESP input fall back to skb_cow_data() when the flag is
> > > present, so ESP does not decrypt externally backed frags in place.
> > > Private nonlinear skb frags still use the existing fast path.
> > >
> > > This intentionally does not change ESP output. In esp_output_head(),
> > > the path that appends the ESP trailer to existing skb tailroom without
> > > calling skb_cow_data() is not reachable for nonlinear skbs:
> > > skb_tailroom() returns zero when skb->data_len is nonzero, while ESP
> > > tailen is positive. Thus ESP output will either use the separate
> > > destination-frag path or fall back to skb_cow_data().
> > >
> > > Signed-off-by: Kuan-Ting Chen <h3xrabbit@gmail.com>
> > > ---
> > > net/ipv4/esp4.c | 3 ++-
> > > net/ipv4/ip_output.c | 2 ++
> > > net/ipv6/esp6.c | 3 ++-
> > > net/ipv6/ip6_output.c | 2 ++
> > > 4 files changed, 8 insertions(+), 2 deletions(-)
> >
> > This looks ok to me. From the IPsec point of view, I'm
> > fine with this patch, but it also touches generic
> > networking code. So I'd like to hear an opinion of one
> > of the networking maintainers before proceeding.
>
> I have not seen a Fixes: tag.
Right, we need a v2 with a Fixes tag, and maybe also
'Cc: stable@vger.kernel.org'
> Do we need to split this patch into two parts?
I don't think we need to spilt it, we can merge it
either to the net or the ipsec tree. Both should
be OK.
^ permalink raw reply
* Re: [PATCH ipsec-next v3] xfrm: cleanup error path in xfrm_add_policy()
From: Steffen Klassert @ 2026-05-04 8:07 UTC (permalink / raw)
To: Deepanshu Kartikey
Cc: herbert, davem, edumazet, kuba, pabeni, horms, sd, netdev,
linux-kernel
In-Reply-To: <afG0TLg68svCz3G1@secunet.com>
On Wed, Apr 29, 2026 at 09:33:32AM +0200, Steffen Klassert wrote:
> On Wed, Apr 29, 2026 at 07:31:40AM +0530, Deepanshu Kartikey wrote:
> > On Tue, Apr 14, 2026 at 7:39 AM Deepanshu Kartikey
> > <kartikey406@gmail.com> wrote:
> > >
> > > Replace the open-coded manual cleanup in the error path of
> > > xfrm_add_policy() with xfrm_policy_destroy(), which already
> > > handles all the necessary cleanup internally. This is consistent
> > > with how xfrm_policy_construct() handles its own error paths.
> > >
> > > The walk.dead flag must be set before calling xfrm_policy_destroy()
> > > as required by BUG_ON(!policy->walk.dead).
> > >
> > > Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
> > > ---
> > > v3:
> > > - Changed prefix to ipsec-next as this is a cleanup
> > > - Dropped syzbot references as suggested by Sabrina Dubroca
> > > v2:
> > > - Reworded commit message to reflect cleanup rather than bugfix
> > > as suggested by Sabrina Dubroca
> > > - Removed incorrect Fixes: and Closes: tags
> > > - Corrected subject prefix to PATCH ipsec
> > > ---
> > > net/xfrm/xfrm_user.c | 5 ++---
> > > 1 file changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
> > > index d56450f61669..ae144d1e4a65 100644
> > > --- a/net/xfrm/xfrm_user.c
> > > +++ b/net/xfrm/xfrm_user.c
> > > @@ -2267,9 +2267,8 @@ static int xfrm_add_policy(struct sk_buff *skb, struct nlmsghdr *nlh,
> > >
> > > if (err) {
> > > xfrm_dev_policy_delete(xp);
> > > - xfrm_dev_policy_free(xp);
> > > - security_xfrm_policy_free(xp->security);
> > > - kfree(xp);
> > > + xp->walk.dead = 1;
> > > + xfrm_policy_destroy(xp);
> > > return err;
> > > }
> > >
> > > --
> > > 2.43.0
> > >
> > Gentle ping on this patch . Please let me know the status of this patch.
> > If anything is required from my side
>
> Your patch was submitted during the merge window. The net-next
> and ipsec-next trees don't accept patches during this period.
>
> The merge window ended last Sunday with the release of 7.1-rc1.
> I prepared the ipsec-next tree for the new development cycle
> yesterday. I'll consider your patch now.
Now applied to ipsec-next, thanks Deepanshu!
^ permalink raw reply
* Re: [PATCH net] xfrm: esp: avoid in-place decrypt on shared skb frags
From: Hyunwoo Kim @ 2026-05-04 8:11 UTC (permalink / raw)
To: Steffen Klassert
Cc: Eric Dumazet, HexRabbit, netdev, Greg Kroah-Hartman, Herbert Xu,
Simon Horman, David S . Miller, David Ahern, Jakub Kicinski,
Paolo Abeni, Ido Schimmel, linux-kernel, imv4bel
In-Reply-To: <afhTekPcnIak0IcI@secunet.com>
On Mon, May 04, 2026 at 10:06:18AM +0200, Steffen Klassert wrote:
> On Mon, May 04, 2026 at 12:56:50AM -0700, Eric Dumazet wrote:
> > On Mon, May 4, 2026 at 12:53 AM Steffen Klassert
> > <steffen.klassert@secunet.com> wrote:
> > >
> > > We have antoher patch that addresses this issue in a different way,
> > > so Cc the author of the other patch.
> > >
> > > On Mon, May 04, 2026 at 03:34:03PM +0800, HexRabbit wrote:
> > > > From: Kuan-Ting Chen <h3xrabbit@gmail.com>
> > > >
> > > > MSG_SPLICE_PAGES can attach pages from a pipe directly to an skb. TCP
> > > > marks such skbs with SKBFL_SHARED_FRAG after skb_splice_from_iter(),
> > > > so later paths that may modify packet data can first make a private
> > > > copy. The IPv4/IPv6 datagram append paths did not set this flag when
> > > > splicing pages into UDP skbs.
> > > >
> > > > That leaves an ESP-in-UDP packet made from shared pipe pages looking
> > > > like an ordinary uncloned nonlinear skb. ESP input then takes the no-COW
> > > > fast path for uncloned skbs without a frag_list and decrypts in place
> > > > over data that is not owned privately by the skb.
> > > >
> > > > Mark IPv4/IPv6 datagram splice frags with SKBFL_SHARED_FRAG, matching
> > > > TCP. Also make ESP input fall back to skb_cow_data() when the flag is
> > > > present, so ESP does not decrypt externally backed frags in place.
> > > > Private nonlinear skb frags still use the existing fast path.
> > > >
> > > > This intentionally does not change ESP output. In esp_output_head(),
> > > > the path that appends the ESP trailer to existing skb tailroom without
> > > > calling skb_cow_data() is not reachable for nonlinear skbs:
> > > > skb_tailroom() returns zero when skb->data_len is nonzero, while ESP
> > > > tailen is positive. Thus ESP output will either use the separate
> > > > destination-frag path or fall back to skb_cow_data().
> > > >
> > > > Signed-off-by: Kuan-Ting Chen <h3xrabbit@gmail.com>
> > > > ---
> > > > net/ipv4/esp4.c | 3 ++-
> > > > net/ipv4/ip_output.c | 2 ++
> > > > net/ipv6/esp6.c | 3 ++-
> > > > net/ipv6/ip6_output.c | 2 ++
> > > > 4 files changed, 8 insertions(+), 2 deletions(-)
> > >
> > > This looks ok to me. From the IPsec point of view, I'm
> > > fine with this patch, but it also touches generic
> > > networking code. So I'd like to hear an opinion of one
> > > of the networking maintainers before proceeding.
> >
> > I have not seen a Fixes: tag.
>
> Right, we need a v2 with a Fixes tag, and maybe also
> 'Cc: stable@vger.kernel.org'
>
> > Do we need to split this patch into two parts?
>
> I don't think we need to spilt it, we can merge it
> either to the net or the ipsec tree. Both should
> be OK.
Also, please add:
Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
Best regards,
Hyunwoo Kim
^ permalink raw reply
* Re: [PATCH iwl-net v1 2/2] ice: use NETIF_F_HW_CSUM instead of IP/IPV6
From: Michal Swiatkowski @ 2026-05-04 8:09 UTC (permalink / raw)
To: Simon Horman
Cc: michal.swiatkowski, intel-wired-lan, netdev, jramaseu,
anthony.l.nguyen, przemyslaw.kitszel, aleksandr.loktionov
In-Reply-To: <20260430162149.GC900403@horms.kernel.org>
On Thu, Apr 30, 2026 at 05:21:49PM +0100, Simon Horman wrote:
> On Thu, Apr 30, 2026 at 04:29:49PM +0100, Simon Horman wrote:
> > From: 'Simon Horman' <horms@kernel.org>
> >
> > This is an AI-generated review of your patch. The human sending this
> > email has considered the AI review valid, or at least plausible.
> > Full review at: https://sashiko.dev
>
> Sorry, the email I am responding to was supposed to come with
> some commentary - it seems my method for adding it is broken :(
> So I'm adding it below (as best as I can remember what it was).
>
Thanks for adding the comments.
> > ---
> > ice: use NETIF_F_HW_CSUM instead of IP/IPV6
> >
> > This commit replaces the IP and IPV6 checksum offload flags with HW_CSUM
> > in the ice driver to allow hardware checksumming for IPv6 packets with
> > extension headers. It also removes the mutual exclusivity check between
> > TSO and GCS.
> >
> > > diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> > > index 5f92377d4dfc..33f252a6a22f 100644
> > > --- a/drivers/net/ethernet/intel/ice/ice_main.c
> > > +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> > > @@ -3491,9 +3491,8 @@ void ice_set_netdev_features(struct net_device *netdev)
> > > NETIF_F_RXHASH;
> > >
> > > csumo_features = NETIF_F_RXCSUM |
> > > - NETIF_F_IP_CSUM |
> > > NETIF_F_SCTP_CRC |
> > > - NETIF_F_IPV6_CSUM;
> > > + NETIF_F_HW_CSUM;
> >
> > By advertising NETIF_F_HW_CSUM, the network stack assumes the driver can handle
> > checksums for any protocol and passes non-IP packets (e.g., from AF_PACKET
> > injected frames) to the driver with CHECKSUM_PARTIAL.
> >
> > Since ice_tx_csum() strictly parses the L3 header and expects IPv4 or IPv6,
> > returning -1 for other protocols, will this regression cause non-IP packets to
> > be silently dropped instead of falling back to software checksums in the kernel?
>
> The problem above seems to be a legitimate concern, if a corner case.
> It seems to also exist in i40e.
>
I think there is a lack of skb_checksum_help() before one error return
from ice_tx_csum(). I will add it.
> > Additionally, skb_csum_hwoffload_help() relies on NETIF_F_IPV6_CSUM to
> > safely fall back to software checksums when IPv6 extension headers are
> > present.
> >
> > Does using NETIF_F_HW_CSUM bypass this safeguard, potentially causing
> > legacy hardware (like E810) or E830 without GCS descriptors to compute
> > incorrect pseudo-headers and silently corrupt IPv6 packets with extension
> > headers?
>
> The issue above seems to be a false positive as the ice driver
> doesn't rely on the behaviour described. Rather ice_tx_csum()
> uses ipv6_skip_exthdr() to correctly handle extension headers.
>
Yeah, righ.
> >
> > Finally, for protocols other than TCP, UDP, or SCTP, the driver falls back to
> > calling skb_checksum_help(skb) in the default case of ice_tx_csum().
> >
> > However, the driver appears to ignore the return value of skb_checksum_help().
> >
> > If skb_checksum_help() fails (e.g., due to -ENOMEM during pskb_expand_head()),
> > could this result in the packet being transmitted with an uncomputed checksum?
>
> The problem above seems real to me, but it also seems to be pre-existing.
> So I don't think it should delay progress of this patch.
>
> If it is a problem, it also seems to be present in i40e.
idpf, igbe too. It should return error in such case and drop the packet.
What do you think, should I add the patch for that here or send it separately?
To be honest I prefer sending it separately as this is in already exsisting
code and touch more than one driver.
Thanks
^ permalink raw reply
* Re: nl80211: SET_WIPHY_NETNS does not check caller's CAP_NET_ADMIN over the target netns
From: Johannes Berg @ 2026-05-04 8:28 UTC (permalink / raw)
To: Xie Maoyi
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev
In-Reply-To: <TYZPR01MB6758FE8FDBB58A6CAA4DC6BBDC302@TYZPR01MB6758.apcprd01.prod.exchangelabs.com>
Hi,
On Sun, 2026-05-03 at 06:55 +0000, Xie Maoyi wrote:
> Hi Johannes,
>
> I think I have found two related namespace handling gaps in nl80211 on v7.0 mainline. I would appreciate your view on whether they are bugs and whether they are worth fixing. The second one is much narrower than the first.
>
> Bug A: NL80211_CMD_SET_WIPHY_NETNS does not check the target netns.
I guess that's more a question of convention than anything else?
But I guess we should follow the netdev convention:
> By comparison, net/core/rtnetlink.c::rtnl_get_net_ns_capable() spells out the convention:
>
> /* For now, the caller is required to have CAP_NET_ADMIN in
> * the user namespace owning the target net ns. */
> if (!sk_ns_capable(sk, net->user_ns, CAP_NET_ADMIN))
> return ERR_PTR(-EACCES);
which (also?) requires access in the target netns.
> Bug B: nl80211_prepare_wdev_dump() continuation does not re-check netns.
>
> The first dumpit invocation validates the wdev against the caller via __cfg80211_wdev_from_attrs(..., sock_net(cb->skb->sk), ...). Subsequent invocations look up the wiphy by global index via wiphy_idx_to_wiphy(). They do not re-check sock_net(cb->skb->sk) against the wiphy's current netns.
>
> Other dump paths in the same file do this check on every iteration. See nl80211_dump_wiphy() at line 3437 and the parallel scheduled scan dump at line 4420.
>
> If a wiphy moves between dumpit invocations of NL80211_CMD_GET_SCAN via NL80211_CMD_SET_WIPHY_NETNS, the dump silently keeps copying BSS list contents from the wiphy's new netns into the caller's netns. On its own this race needs a separate caller to migrate the wiphy mid-dump. With bug A, the attacker can arrange the race themselves.
This seems ... inconsequential? After all, moving a wireless device
between namespaces doesn't really change the physical layout of the
machine. Perhaps that'd give someone access to the SSID of some hidden
network but that's not really a secret anyway since it's over the air.
Maybe we should fix it for clarity and convention, but I don't see it's
really an issue?
johannes
^ permalink raw reply
* Re: [RFC PATCH] xprtrdma: Move long delayed work on system_dfl_long_wq
From: Marco Crivellari @ 2026-05-04 8:34 UTC (permalink / raw)
To: Chuck Lever
Cc: Frederic Weisbecker, linux-kernel, linux-nfs, netdev, Tejun Heo,
Lai Jiangshan, Sebastian Andrzej Siewior, Michal Hocko,
Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
In-Reply-To: <4edf7abf-8f48-4433-98f0-2ed2d97a32f5@app.fastmail.com>
On Thu, Apr 30, 2026 at 5:09 PM Chuck Lever <cel@kernel.org> wrote:
> [...]
> The light dawns (for me). That's what I'd like to see in the commit message.
>
> I don't have any technical objections to the code change.
Hello Chuck,
Thanks for all your feedback.
I will improve the commit log with your suggestion and then send v2.
Thanks.
--
Marco Crivellari
SUSE Labs
^ permalink raw reply
* [PATCH net 0/4] bnxt_en: Bug fixes
From: Pavan Chebbi @ 2026-05-04 8:36 UTC (permalink / raw)
To: davem, kuba
Cc: andrew+netdev, andrew.gospodarek, edumazet, michael.chan, netdev,
pabeni, pavan.chebbi
This patchset adds the following fixes for bnxt:
Patch #1 fixes DPC AER handling to make it more reliable
Patch #2 fixes incorrect capping bp->max_tpa based on what the FW
supports
Patch #3 fixes ignoring of VNIC configuration result when RDMA
driver is loading
Patch #4 fixes logic to make phase adjustment on the PPS OUT signal
Kalesh AP (1):
bnxt_en: Check return value of bnxt_hwrm_vnic_cfg
Michael Chan (2):
bnxt_en: Delay for 5 seconds after AER DPC for all chips
bnxt_en: Set bp->max_tpa according to what the FW supports
Pavan Chebbi (1):
bnxt_en: Use absolute target ns from ptp_clock_request
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 16 +++++++---
drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c | 29 ++++---------------
drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c | 10 +++++--
3 files changed, 25 insertions(+), 30 deletions(-)
--
2.52.0
^ permalink raw reply
* [PATCH net 1/4] bnxt_en: Delay for 5 seconds after AER DPC for all chips
From: Pavan Chebbi @ 2026-05-04 8:36 UTC (permalink / raw)
To: davem, kuba
Cc: andrew+netdev, andrew.gospodarek, edumazet, michael.chan, netdev,
pabeni, pavan.chebbi, Kalesh AP
In-Reply-To: <20260504083611.1383776-1-pavan.chebbi@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
The FW on all chips is requiring a 5-second delay after Downstream
Port Containment (DPC) AER. The previously added 900 msec delay was
not long enough in all cases because the chip's CRS (Configuration
Request Retry Status) mechanism is not always reliable.
Fixes: d5ab32e9b02d ("bnxt_en: Add delay to handle Downstream Port Containment (DPC) AER")
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 8c55874f44ca..3db951d0c690 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -17360,9 +17360,14 @@ static pci_ers_result_t bnxt_io_slot_reset(struct pci_dev *pdev)
netdev_info(bp->dev, "PCI Slot Reset\n");
- if (!(bp->flags & BNXT_FLAG_CHIP_P5_PLUS) &&
- test_bit(BNXT_STATE_PCI_CHANNEL_IO_FROZEN, &bp->state))
- msleep(900);
+ if (test_bit(BNXT_STATE_PCI_CHANNEL_IO_FROZEN, &bp->state)) {
+ /* After DPC, the chip should return CRS when the vendor ID
+ * config register is read until it is ready. On all chips,
+ * this is not happening reliably so add a 5-second delay as a
+ * workaround.
+ */
+ msleep(5000);
+ }
netdev_lock(netdev);
--
2.52.0
^ permalink raw reply related
* [PATCH net 2/4] bnxt_en: Set bp->max_tpa according to what the FW supports
From: Pavan Chebbi @ 2026-05-04 8:36 UTC (permalink / raw)
To: davem, kuba
Cc: andrew+netdev, andrew.gospodarek, edumazet, michael.chan, netdev,
pabeni, pavan.chebbi, Kalesh AP, Colin Winegarden,
Rukhsana Ansari
In-Reply-To: <20260504083611.1383776-1-pavan.chebbi@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Fix the logic to set bp->max_tpa no higher than what the FW supports.
On P5 chips, some older FW sets max_tpa very low so we override it to
prevent performance regressions with the older FW.
Fixes: 79632e9ba386 ("bnxt_en: Expand bnxt_tpa_info struct to support 57500 chips.")
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Reviewed-by: Colin Winegarden <colin.winegarden@broadcom.com>
Reviewed-by: Rukhsana Ansari <rukhsana.ansari@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 3db951d0c690..008c34cff7b4 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -3825,7 +3825,10 @@ static int bnxt_alloc_tpa_info(struct bnxt *bp)
if (bp->flags & BNXT_FLAG_CHIP_P5_PLUS) {
if (!bp->max_tpa_v2)
return 0;
- bp->max_tpa = max_t(u16, bp->max_tpa_v2, MAX_TPA_P5);
+ bp->max_tpa = min_t(u16, bp->max_tpa_v2, MAX_TPA_P5);
+ /* Older P5 FW sets max_tpa_v2 low by mistake except NPAR */
+ if (bp->max_tpa <= 32 && BNXT_CHIP_P5(bp) && !BNXT_NPAR(bp))
+ bp->max_tpa = MAX_TPA_P5;
}
for (i = 0; i < bp->rx_nr_rings; i++) {
--
2.52.0
^ permalink raw reply related
* [PATCH net 3/4] bnxt_en: Check return value of bnxt_hwrm_vnic_cfg
From: Pavan Chebbi @ 2026-05-04 8:36 UTC (permalink / raw)
To: davem, kuba
Cc: andrew+netdev, andrew.gospodarek, edumazet, michael.chan, netdev,
pabeni, pavan.chebbi, Kalesh AP
In-Reply-To: <20260504083611.1383776-1-pavan.chebbi@broadcom.com>
From: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
When the bnxt RDMA driver is loaded, it calls bnxt_register_dev().
As part of this, driver sends HWRM_VNIC_CFG firmware command
to configure the VNIC to operate in dual VNIC mode. Currently
the driver ignores the result of this firmware command. The RDMA
driver must know the result since it affects its functioning.
Check return value of call to bnxt_hwrm_vnic_cfg() in
bnxt_register_dev() and return failure on error.
Fixes: a588e4580a7e ("bnxt_en: Add interface to support RDMA driver.")
Reviewed-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c
index 052bf69cfa4c..5c751933da6a 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c
@@ -175,8 +175,14 @@ int bnxt_register_dev(struct bnxt_en_dev *edev,
ulp->handle = handle;
rcu_assign_pointer(ulp->ulp_ops, ulp_ops);
- if (test_bit(BNXT_STATE_OPEN, &bp->state))
- bnxt_hwrm_vnic_cfg(bp, &bp->vnic_info[BNXT_VNIC_DEFAULT]);
+ if (test_bit(BNXT_STATE_OPEN, &bp->state)) {
+ rc = bnxt_hwrm_vnic_cfg(bp, &bp->vnic_info[BNXT_VNIC_DEFAULT]);
+ if (rc) {
+ netdev_err(dev, "Failed to configure dual VNIC mode\n");
+ RCU_INIT_POINTER(ulp->ulp_ops, NULL);
+ goto exit;
+ }
+ }
edev->ulp_tbl->msix_requested = bnxt_get_ulp_msix_num(bp);
--
2.52.0
^ permalink raw reply related
* [PATCH net 4/4] bnxt_en: Use absolute target ns from ptp_clock_request
From: Pavan Chebbi @ 2026-05-04 8:36 UTC (permalink / raw)
To: davem, kuba
Cc: andrew+netdev, andrew.gospodarek, edumazet, michael.chan, netdev,
pabeni, pavan.chebbi, Kalesh AP, Richard Cochran
In-Reply-To: <20260504083611.1383776-1-pavan.chebbi@broadcom.com>
There is no need to calculate the target PHC cycles required
to make phase adjustment on the PPS OUT signal. This is because
the application supplies absolute n_sec value in the future and
is already the actual desired target value.
Remove the unnecessary code.
Fixes: 9e518f25802c ("bnxt_en: 1PPS functions to configure TSIO pins")
Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
---
drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c | 29 ++++---------------
1 file changed, 5 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
index 53f336db4fcc..5d41dc1bc782 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ptp.c
@@ -419,31 +419,13 @@ void bnxt_ptp_reapply_pps(struct bnxt *bp)
}
}
-static int bnxt_get_target_cycles(struct bnxt_ptp_cfg *ptp, u64 target_ns,
- u64 *cycles_delta)
-{
- u64 cycles_now;
- u64 nsec_now, nsec_delta;
- int rc;
-
- rc = bnxt_refclk_read(ptp->bp, NULL, &cycles_now);
- if (rc)
- return rc;
-
- nsec_now = bnxt_timecounter_cyc2time(ptp, cycles_now);
-
- nsec_delta = target_ns - nsec_now;
- *cycles_delta = div64_u64(nsec_delta << ptp->cc.shift, ptp->cc.mult);
- return 0;
-}
-
static int bnxt_ptp_perout_cfg(struct bnxt_ptp_cfg *ptp,
struct ptp_clock_request *rq)
{
struct hwrm_func_ptp_cfg_input *req;
struct bnxt *bp = ptp->bp;
struct timespec64 ts;
- u64 target_ns, delta;
+ u64 target_ns;
u16 enables;
int rc;
@@ -451,10 +433,6 @@ static int bnxt_ptp_perout_cfg(struct bnxt_ptp_cfg *ptp,
ts.tv_nsec = rq->perout.start.nsec;
target_ns = timespec64_to_ns(&ts);
- rc = bnxt_get_target_cycles(ptp, target_ns, &delta);
- if (rc)
- return rc;
-
rc = hwrm_req_init(bp, req, HWRM_FUNC_PTP_CFG);
if (rc)
return rc;
@@ -468,7 +446,10 @@ static int bnxt_ptp_perout_cfg(struct bnxt_ptp_cfg *ptp,
req->ptp_freq_adj_dll_phase = 0;
req->ptp_freq_adj_ext_period = cpu_to_le32(NSEC_PER_SEC);
req->ptp_freq_adj_ext_up = 0;
- req->ptp_freq_adj_ext_phase_lower = cpu_to_le32(delta);
+ req->ptp_freq_adj_ext_phase_lower =
+ cpu_to_le32(lower_32_bits(target_ns));
+ req->ptp_freq_adj_ext_phase_upper =
+ cpu_to_le32(upper_32_bits(target_ns));
return hwrm_req_send(bp, req);
}
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net-next v2 1/2] dpll: move fractional-frequency-offset-ppt under pin-parent-device
From: Jiri Pirko @ 2026-05-04 8:48 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev, Andrew Lunn, Arkadiusz Kubalewski, David S. Miller,
Donald Hunter, Eric Dumazet, Jakub Kicinski, Jonathan Corbet,
Leon Romanovsky, Mark Bloch, Michal Schmidt, Paolo Abeni,
Pasi Vaananen, Petr Oros, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
In-Reply-To: <20260430173611.3312596-2-ivecera@redhat.com>
Thu, Apr 30, 2026 at 07:36:10PM +0200, ivecera@redhat.com wrote:
>Move the fractional-frequency-offset-ppt attribute from the top-level
>pin attributes into the pin-parent-device nested attribute set. This
>makes it consistent with phase-offset which is already per-parent and
>clarifies that FFO PPT represents the frequency difference between
>a pin and its parent DPLL device.
>
>The top-level fractional-frequency-offset attribute (in PPM) remains
>unchanged for backward compatibility.
That is odd. The ppt one was added just for higher precision but was
semantically the same. Now you change it. Could you still treat both the
same?
>
>Distinguish the two contexts in the ffo_get callback by passing
>dpll=NULL for the top-level (rx vs tx symbol rate) call and a valid
>dpll pointer for the nested (pin vs parent DPLL) call. Update mlx5
>and zl3073x drivers to return -ENODATA for the nested context they
>do not yet support.
>
>Add documentation for both FFO attributes to dpll.rst.
>
[..]
^ 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