* Re: [PATCH net-next 4/5] crypto: fcrypt - Remove support for FCrypt block cipher
From: Geert Uytterhoeven @ 2026-04-28 10:03 UTC (permalink / raw)
To: Eric Biggers
Cc: netdev, linux-afs, David Howells, Marc Dionne, linux-crypto,
linux-kernel, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
In-Reply-To: <20260428024400.123337-5-ebiggers@kernel.org>
On Tue, 28 Apr 2026 at 04:49, Eric Biggers <ebiggers@kernel.org> wrote:
> Remove the insecure FCrypt block cipher from the crypto API. Its only
> user was net/rxrpc/, but now net/rxrpc/ implements it locally. The
> crypto API implementation is no longer needed.
>
> For some additional context: FCrypt was designed in 1988 and is
> essentially a weakened version of DES. It has the same 56-bit key size
> as DES, which is easily brute forced. Moreover, it's cryptographically
> weak and doesn't even provide the intended 56-bit security level. Its
> author considers it to be a mistake, as well
> (https://lists.openafs.org/pipermail/openafs-devel/2000-December/005320.html).
>
> But fortunately this 1980s-era homebrew block cipher was never adopted
> outside of net/rxrpc/. So its code can just be kept there.
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> arch/m68k/configs/amiga_defconfig | 1 -
> arch/m68k/configs/apollo_defconfig | 1 -
> arch/m68k/configs/atari_defconfig | 1 -
> arch/m68k/configs/bvme6000_defconfig | 1 -
> arch/m68k/configs/hp300_defconfig | 1 -
> arch/m68k/configs/mac_defconfig | 1 -
> arch/m68k/configs/multi_defconfig | 1 -
> arch/m68k/configs/mvme147_defconfig | 1 -
> arch/m68k/configs/mvme16x_defconfig | 1 -
> arch/m68k/configs/q40_defconfig | 1 -
> arch/m68k/configs/sun3_defconfig | 1 -
> arch/m68k/configs/sun3x_defconfig | 1 -
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net-next 5/5] crypto: pcbc - Remove support for PCBC mode
From: Geert Uytterhoeven @ 2026-04-28 10:05 UTC (permalink / raw)
To: Eric Biggers
Cc: netdev, linux-afs, David Howells, Marc Dionne, linux-crypto,
linux-kernel, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
In-Reply-To: <20260428024400.123337-6-ebiggers@kernel.org>
On Tue, 28 Apr 2026 at 04:49, Eric Biggers <ebiggers@kernel.org> wrote:
> The only user of PCBC mode (Propagating Cipher Block Chaining mode) was
> net/rxrpc/rxkad.c, which now uses local code instead.
>
> While PCBC was an interesting cryptographic experiment, it has largely
> been relegated to the history books and academic exercises. It is
> non-parallelizable (i.e., very slow) and doesn't actually achieve the
> integrity properties it was apparently intended to achieve.
>
> Remove support for it from the crypto API.
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> arch/m68k/configs/amiga_defconfig | 1 -
> arch/m68k/configs/apollo_defconfig | 1 -
> arch/m68k/configs/atari_defconfig | 1 -
> arch/m68k/configs/bvme6000_defconfig | 1 -
> arch/m68k/configs/hp300_defconfig | 1 -
> arch/m68k/configs/mac_defconfig | 1 -
> arch/m68k/configs/multi_defconfig | 1 -
> arch/m68k/configs/mvme147_defconfig | 1 -
> arch/m68k/configs/mvme16x_defconfig | 1 -
> arch/m68k/configs/q40_defconfig | 1 -
> arch/m68k/configs/sun3_defconfig | 1 -
> arch/m68k/configs/sun3x_defconfig | 1 -
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> # m68k
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 1/4] rdma: Update headers
From: Chiara Meiohas @ 2026-04-28 10:05 UTC (permalink / raw)
To: David Ahern, Stephen Hemminger
Cc: leon, michaelgur, jgg, linux-rdma, netdev, Patrisious Haddad
In-Reply-To: <77e1a762-e204-497b-b7cb-40d5a93f8ec7@gmail.com>
On 27/04/2026 21:27, David Ahern wrote:
> On 4/27/26 12:25 PM, Stephen Hemminger wrote:
>> On Mon, 30 Mar 2026 20:31:15 +0300
>> Chiara Meiohas <cmeiohas@nvidia.com> wrote:
>>
>>> From: Michael Guralnik <michaelgur@nvidia.com>
>>>
>>> Update rdma_netlink.h file up to kernel commit dbd0472fd7a5
>>> ("RDMA/nldev: Expose kernel-internal FRMR pools in netlink")
>>>
>>> Signed-off-by: Michael Guralnik <michaelgur@nvidia.com>
>>> Reviewed-by: Patrisious Haddad <phaddad@nvidia.com>
>>> Reviewed-by: Chiara Meiohas <cmeiohas@nvidia.com>
>> The upstream macro names changed, the iproute2 build is broken after
>> current headers sync.
>>
>> In file included from res.c:7:
>> res.h: In function ‘_res_frmr_pools’:
>> res.h:203:26: error: ‘RDMA_NLDEV_CMD_RES_FRMR_POOLS_GET’ undeclared (first use in this function); did you mean ‘RDMA_NLDEV_CMD_FRMR_POOLS_GET’?
>> 203 | RES_FUNC(res_frmr_pools, RDMA_NLDEV_CMD_RES_FRMR_POOLS_GET,
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> res.h:56:44: note: in definition of macro ‘RES_FUNC’
>> 56 | _command = res_get_command(command, rd); \
>> | ^~~~~~~
>> res.h:203:26: note: each undeclared identifier is reported only once for each function it appears in
>> 203 | RES_FUNC(res_frmr_pools, RDMA_NLDEV_CMD_RES_FRMR_POOLS_GET,
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> res.h:56:44: note: in definition of macro ‘RES_FUNC’
>> 56 | _command = res_get_command(command, rd); \
>> | ^~~~~~~
>
> Looks like the merged API does not have the _RES part of the uapi:
>
> kernel vs iproute2:
>
> @@ -590,19 +590,19 @@
> /*
> * FRMR Pools attributes
> */
> - RDMA_NLDEV_ATTR_FRMR_POOLS, /* nested table */
> - RDMA_NLDEV_ATTR_FRMR_POOL_ENTRY, /* nested table */
> - RDMA_NLDEV_ATTR_FRMR_POOL_KEY, /* nested table */
> - RDMA_NLDEV_ATTR_FRMR_POOL_KEY_ATS, /* u8 */
> - RDMA_NLDEV_ATTR_FRMR_POOL_KEY_ACCESS_FLAGS, /* u32 */
> - RDMA_NLDEV_ATTR_FRMR_POOL_KEY_VENDOR_KEY, /* u64 */
> - RDMA_NLDEV_ATTR_FRMR_POOL_KEY_NUM_DMA_BLOCKS, /* u64 */
> - RDMA_NLDEV_ATTR_FRMR_POOL_QUEUE_HANDLES, /* u32 */
> - RDMA_NLDEV_ATTR_FRMR_POOL_MAX_IN_USE, /* u64 */
> - RDMA_NLDEV_ATTR_FRMR_POOL_IN_USE, /* u64 */
> - RDMA_NLDEV_ATTR_FRMR_POOLS_AGING_PERIOD, /* u32 */
> - RDMA_NLDEV_ATTR_FRMR_POOL_PINNED_HANDLES, /* u32 */
> - RDMA_NLDEV_ATTR_FRMR_POOL_KEY_KERNEL_VENDOR_KEY, /* u64 */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOLS, /* nested table */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_ENTRY, /* nested table */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_KEY, /* nested table */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_KEY_ATS, /* u8 */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_KEY_ACCESS_FLAGS, /* u32 */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_KEY_VENDOR_KEY, /* u64 */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_KEY_NUM_DMA_BLOCKS, /* u64 */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_QUEUE_HANDLES, /* u32 */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_MAX_IN_USE, /* u64 */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_IN_USE, /* u64 */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_AGING_PERIOD, /* u32 */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_PINNED, /* u32 */
> + RDMA_NLDEV_ATTR_RES_FRMR_POOL_KEY_KERNEL_VENDOR_KEY, /* u64 */
>
> /*
Thanks for catching this.
We will prepare a sync patch to align the names with the kernel and send it shortly.
Best regards,
Chiara
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v7 01/14] virtchnl: create 'include/linux/intel' and move necessary header files
From: Loktionov, Aleksandr @ 2026-04-28 10:08 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Salin, Samuel, Czurylo, Krzysztof
In-Reply-To: <20260428082654.44364-2-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Tuesday, April 28, 2026 10:27 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Salin, Samuel
> <samuel.salin@intel.com>; Czurylo, Krzysztof
> <krzysztof.czurylo@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v7 01/14] virtchnl: create
> 'include/linux/intel' and move necessary header files
>
> From: Victor Raj <victor.raj@intel.com>
>
> include/linux/net houses a single folder "intel", meanwhile
> include/linux/intel is vacant. On top of that, it would be useful to
> place all iavf headers together with other intel networking headers,
> same goes for virtchnl2 headers which will be used by both idpf and
> ixd drivers.
>
> Move abovementioned intel header files into new folder
> include/linux/intel.
> Also, assign new folder to both intel and general networking
> maintainers.
>
> Suggested-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> Reviewed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> Signed-off-by: Victor Raj <victor.raj@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Tested-by: Samuel Salin <Samuel.salin@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> MAINTAINERS | 6 +++--
> -
> drivers/infiniband/hw/irdma/i40iw_if.c | 2 +-
> drivers/infiniband/hw/irdma/icrdma_if.c | 2 +-
> drivers/infiniband/hw/irdma/ig3rdma_if.c | 2 +-
> drivers/infiniband/hw/irdma/main.c | 2 +-
> drivers/infiniband/hw/irdma/main.h | 2 +-
> drivers/net/ethernet/intel/i40e/i40e.h | 4 ++--
> drivers/net/ethernet/intel/i40e/i40e_adminq_cmd.h | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_client.c | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_common.c | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_prototype.h | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_txrx.c | 4 ++--
> drivers/net/ethernet/intel/i40e/i40e_txrx.h | 2 +-
> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.h | 2 +-
> drivers/net/ethernet/intel/iavf/iavf.h | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_adminq_cmd.h | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_common.c | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_main.c | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_prototype.h | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_txrx.c | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_txrx.h | 2 +-
> drivers/net/ethernet/intel/iavf/iavf_types.h | 4 +---
> drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 2 +-
> drivers/net/ethernet/intel/ice/ice.h | 2 +-
> drivers/net/ethernet/intel/ice/ice_adminq_cmd.h | 2 +-
> drivers/net/ethernet/intel/ice/ice_base.c | 2 +-
> drivers/net/ethernet/intel/ice/ice_common.h | 2 +-
> drivers/net/ethernet/intel/ice/ice_flow.h | 2 +-
> drivers/net/ethernet/intel/ice/ice_idc_int.h | 4 ++--
> drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +-
> drivers/net/ethernet/intel/ice/ice_txrx_lib.c | 2 +-
> drivers/net/ethernet/intel/ice/ice_type.h | 2 +-
> drivers/net/ethernet/intel/ice/ice_vf_lib.h | 2 +-
> drivers/net/ethernet/intel/ice/virt/virtchnl.h | 2 +-
> drivers/net/ethernet/intel/idpf/idpf.h | 6 +++--
> -
> drivers/net/ethernet/intel/idpf/idpf_txrx.h | 2 +-
> drivers/net/ethernet/intel/idpf/idpf_virtchnl.h | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_type.h | 2 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_type_e610.h | 2 +-
> drivers/net/ethernet/intel/libie/adminq.c | 2 +-
> drivers/net/ethernet/intel/libie/fwlog.c | 2 +-
> drivers/net/ethernet/intel/libie/rx.c | 2 +-
> include/linux/{net => }/intel/i40e_client.h | 0
> include/linux/{net => }/intel/iidc_rdma.h | 0
> include/linux/{net => }/intel/iidc_rdma_ice.h | 0
> include/linux/{net => }/intel/iidc_rdma_idpf.h | 0
> include/linux/{net => }/intel/libie/adminq.h | 0
> include/linux/{net => }/intel/libie/fwlog.h | 2 +-
> include/linux/{net => }/intel/libie/pctype.h | 0
> include/linux/{net => }/intel/libie/rx.h | 0
> include/linux/{avf => intel}/virtchnl.h | 0
> .../ethernet/intel/idpf => include/linux/intel}/virtchnl2.h | 0
> .../intel/idpf => include/linux/intel}/virtchnl2_lan_desc.h | 0
> 55 files changed, 52 insertions(+), 54 deletions(-) rename
> include/linux/{net => }/intel/i40e_client.h (100%) rename
> include/linux/{net => }/intel/iidc_rdma.h (100%) rename
> include/linux/{net => }/intel/iidc_rdma_ice.h (100%) rename
> include/linux/{net => }/intel/iidc_rdma_idpf.h (100%) rename
> include/linux/{net => }/intel/libie/adminq.h (100%) rename
> include/linux/{net => }/intel/libie/fwlog.h (98%) rename
> include/linux/{net => }/intel/libie/pctype.h (100%) rename
> include/linux/{net => }/intel/libie/rx.h (100%) rename
> include/linux/{avf => intel}/virtchnl.h (100%) rename
> {drivers/net/ethernet/intel/idpf => include/linux/intel}/virtchnl2.h
> (100%) rename {drivers/net/ethernet/intel/idpf =>
> include/linux/intel}/virtchnl2_lan_desc.h (100%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e7dc9e6fad2e..8bfa20b02005 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -12842,8 +12842,7 @@ T: git
> git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git
> F: Documentation/networking/device_drivers/ethernet/intel/
> F: drivers/net/ethernet/intel/
> F: drivers/net/ethernet/intel/*/
...
>
> /* Only a single log level should be set and all log levels under the
> set value
> * are enabled, e.g. if log level is set to
> LIBIE_FW_LOG_LEVEL_VERBOSE, then all diff --git
> a/include/linux/net/intel/libie/pctype.h
> b/include/linux/intel/libie/pctype.h
> similarity index 100%
> rename from include/linux/net/intel/libie/pctype.h
> rename to include/linux/intel/libie/pctype.h
> diff --git a/include/linux/net/intel/libie/rx.h
> b/include/linux/intel/libie/rx.h similarity index 100% rename from
> include/linux/net/intel/libie/rx.h
> rename to include/linux/intel/libie/rx.h diff --git
> a/include/linux/avf/virtchnl.h b/include/linux/intel/virtchnl.h
> similarity index 100% rename from include/linux/avf/virtchnl.h rename
> to include/linux/intel/virtchnl.h diff --git
> a/drivers/net/ethernet/intel/idpf/virtchnl2.h
> b/include/linux/intel/virtchnl2.h similarity index 100% rename from
> drivers/net/ethernet/intel/idpf/virtchnl2.h
> rename to include/linux/intel/virtchnl2.h diff --git
> a/drivers/net/ethernet/intel/idpf/virtchnl2_lan_desc.h
> b/include/linux/intel/virtchnl2_lan_desc.h
> similarity index 100%
> rename from drivers/net/ethernet/intel/idpf/virtchnl2_lan_desc.h
> rename to include/linux/intel/virtchnl2_lan_desc.h
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v7 02/14] libie: add PCI device initialization helpers to libie
From: Loktionov, Aleksandr @ 2026-04-28 10:09 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Burra, Phani R, R, Bharath,
Salin, Samuel
In-Reply-To: <20260428082654.44364-3-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Tuesday, April 28, 2026 10:27 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Burra, Phani R
> <phani.r.burra@intel.com>; R, Bharath <bharath.r@intel.com>; Salin,
> Samuel <samuel.salin@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v7 02/14] libie: add PCI
> device initialization helpers to libie
>
> From: Phani R Burra <phani.r.burra@intel.com>
>
> Add support functions for drivers to configure PCI functionality and
> access MMIO space.
>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Signed-off-by: Phani R Burra <phani.r.burra@intel.com>
> Co-developed-by: Victor Raj <victor.raj@intel.com>
> Signed-off-by: Victor Raj <victor.raj@intel.com>
> Co-developed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> Co-developed-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Tested-by: Bharath R <bharath.r@intel.com>
> Tested-by: Samuel Salin <Samuel.salin@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> drivers/net/ethernet/intel/libie/Kconfig | 6 +
> drivers/net/ethernet/intel/libie/Makefile | 4 +
> drivers/net/ethernet/intel/libie/pci.c | 208
> ++++++++++++++++++++++
> include/linux/intel/libie/pci.h | 56 ++++++
> 4 files changed, 274 insertions(+)
> create mode 100644 drivers/net/ethernet/intel/libie/pci.c
> create mode 100644 include/linux/intel/libie/pci.h
>
> diff --git a/drivers/net/ethernet/intel/libie/Kconfig
> b/drivers/net/ethernet/intel/libie/Kconfig
> index 70831c7e336e..500a95c944a8 100644
> --- a/drivers/net/ethernet/intel/libie/Kconfig
> +++ b/drivers/net/ethernet/intel/libie/Kconfig
> @@ -23,3 +23,9 @@ config LIBIE_FWLOG
> for it. Firmware logging is using admin queue interface to
> communicate
> with the device. Debugfs is a user interface used to config
> logging
> and dump all collected logs.
...
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v7 04/14] libie: add control queue support
From: Loktionov, Aleksandr @ 2026-04-28 10:10 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Burra, Phani R, R, Bharath,
Salin, Samuel
In-Reply-To: <20260428082654.44364-5-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Tuesday, April 28, 2026 10:27 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Burra, Phani R
> <phani.r.burra@intel.com>; R, Bharath <bharath.r@intel.com>; Salin,
> Samuel <samuel.salin@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v7 04/14] libie: add
> control queue support
>
> From: Phani R Burra <phani.r.burra@intel.com>
>
> Libie will now support control queue setup and configuration APIs.
> These are mainly used for mailbox communication between drivers and
> control plane.
>
> Make use of the libeth_rx page pool support for managing controlq
> buffers.
>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Signed-off-by: Phani R Burra <phani.r.burra@intel.com>
> Co-developed-by: Victor Raj <victor.raj@intel.com>
> Signed-off-by: Victor Raj <victor.raj@intel.com>
> Co-developed-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> Signed-off-by: Sridhar Samudrala <sridhar.samudrala@intel.com>
> Co-developed-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Tested-by: Bharath R <bharath.r@intel.com>
> Tested-by: Samuel Salin <Samuel.salin@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> drivers/net/ethernet/intel/libie/Kconfig | 8 +
> drivers/net/ethernet/intel/libie/Makefile | 4 +
> drivers/net/ethernet/intel/libie/controlq.c | 614
> ++++++++++++++++++++
> include/linux/intel/libie/controlq.h | 249 ++++++++
> 4 files changed, 875 insertions(+)
> create mode 100644 drivers/net/ethernet/intel/libie/controlq.c
> create mode 100644 include/linux/intel/libie/controlq.h
>
> diff --git a/drivers/net/ethernet/intel/libie/Kconfig
> b/drivers/net/ethernet/intel/libie/Kconfig
> index 500a95c944a8..9c5fdebb6766 100644
> --- a/drivers/net/ethernet/intel/libie/Kconfig
> +++ b/drivers/net/ethernet/intel/libie/Kconfig
> @@ -15,6 +15,14 @@ config LIBIE_ADMINQ
> Helper functions used by Intel Ethernet drivers for
> administration
> queue command interface (aka adminq).
>
...
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net/tcp-ao: Use crypto library API instead of crypto_ahash
From: David Laight @ 2026-04-28 10:10 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Eric Biggers, netdev, linux-crypto, linux-kernel, Eric Dumazet,
Neal Cardwell, Kuniyuki Iwashima, David S . Miller, David Ahern,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jason A . Donenfeld,
Herbert Xu, Dmitry Safonov
In-Reply-To: <bab8b5b6-6ee7-4e0b-9999-becf8f28ce71@app.fastmail.com>
On Tue, 28 Apr 2026 08:34:47 +0200
"Ard Biesheuvel" <ardb@kernel.org> wrote:
> On Tue, 28 Apr 2026, at 03:24, David Laight wrote:
> > On Mon, 27 Apr 2026 10:27:24 -0700
> > Eric Biggers <ebiggers@kernel.org> wrote:
> >
> >> Currently the kernel's TCP-AO implementation does the MAC and KDF
> >> computations using the crypto_ahash API. This API is inefficient and
> >> difficult to use, and it has required extensive workarounds in the form
> >> of per-CPU preallocated objects (tcp_sigpool) to work at all.
> >>
> >> Let's use lib/crypto/ instead. This means switching to straightforward
> >> stack-allocated structures, virtually addressed buffers, and direct
> >> function calls. It also means removing quite a bit of error handling.
> >> This makes TCP-AO quite a bit faster.
> >>
> >> This also enables many additional cleanups, which later commits will
> >> handle: removing tcp-sigpool, removing support for crypto_tfm cloning,
> >> removing more error handling, and replacing more dynamically-allocated
> >> buffers with stack buffers based on the now-statically-known limits.
> >>
> >> Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
> >> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > ...
> >> @@ -344,33 +444,26 @@ static int tcp_v4_ao_calc_key(struct tcp_ao_key *mkt, u8 *key,
> >> struct kdf_input_block {
> >> u8 counter;
> >> u8 label[6];
> >> struct tcp4_ao_context ctx;
> >> __be16 outlen;
> >> - } __packed * tmp;
> >
> > That looks a bit horrid.
> > I also had a feeling that the compiler sometimes rejects non-packed structures
> > inside packed ones.
> > Perhaps nest the whole thing inside another structure that has an initial
> > u8 pad and is marked __packed __aligned(4).
> > Then the assignments to the fields of 'ctx' will be known to be aligned
> > even when tcp4_ao_context is also __packed.
> >
>
> Agree with Eric that this has no bearing on this patch,
true - just the in the same code.
> but I'm not sure
> I see the problem here. 'ctx' will not be packed, and appear misaligned
> in struct kdf_input_block, but that would only matter if the address of
> the ctx field were taken and passed to a function taking a pointer to
> struct tcp4_ao_context (which would expect it to appear naturally
> aligned).
>
> Having a feeling about what the compiler sometimes rejects is not
> actionable feedback - could you be more specific about which problem
> you think needs to be solved here? Are you concerned about unaligned
> accesses when populating the struct?
(It was 2am and the side effects of a cold were stopping me sleeping...)
I tend to double-check __packed because it gets misused in places
where you really want the compiler to error implicit padding rather
than generate expensive misaligned access code.
But I am sure I remember some build warning that needed __packed added
to the definition of a structure embedded in a __packed structure.
I don't think it was only the arm OABI (which pads structures to 2 bytes).
Historically this has never mattered (even the 'address of packed member'
error is moderately recent - well sometime in the last 20 years).
In this case (and the ipv6 code) 'struct tcp4_ao_context' can just be
marked __packed.
Or, since this is the only place it is used, possibly just inlined
into 'struct kdf_input_block' - which may not even need to be named.
David
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v7 05/14] libie: add bookkeeping support for control queue messages
From: Loktionov, Aleksandr @ 2026-04-28 10:10 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Burra, Phani R, R, Bharath,
Salin, Samuel
In-Reply-To: <20260428082654.44364-6-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Tuesday, April 28, 2026 10:27 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Burra, Phani R
> <phani.r.burra@intel.com>; R, Bharath <bharath.r@intel.com>; Salin,
> Samuel <samuel.salin@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v7 05/14] libie: add
> bookkeeping support for control queue messages
>
> From: Phani R Burra <phani.r.burra@intel.com>
>
> All send control queue messages are allocated/freed in libie itself
> and tracked with the unique transaction (Xn) ids until they receive
> response or time out. Responses can be received out of order,
> therefore transactions are stored in an array and tracked though a
> bitmap.
>
> Pre-allocated DMA memory is used where possible. It reduces the driver
> overhead in handling memory allocation/free and message timeouts.
>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Signed-off-by: Phani R Burra <phani.r.burra@intel.com>
> Co-developed-by: Victor Raj <victor.raj@intel.com>
> Signed-off-by: Victor Raj <victor.raj@intel.com>
> Co-developed-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Co-developed-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Tested-by: Bharath R <bharath.r@intel.com>
> Tested-by: Samuel Salin <Samuel.salin@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> drivers/net/ethernet/intel/libie/controlq.c | 599
> ++++++++++++++++++++
> include/linux/intel/libie/controlq.h | 177 ++++++
> 2 files changed, 776 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/libie/controlq.c
> b/drivers/net/ethernet/intel/libie/controlq.c
> index 934721c98f34..5b06d797facf 100644
> --- a/drivers/net/ethernet/intel/libie/controlq.c
> +++ b/drivers/net/ethernet/intel/libie/controlq.c
> @@ -609,6 +609,605 @@ u32 libie_ctlq_recv(struct libie_ctlq_info
> *ctlq, struct libie_ctlq_msg *msg, }
> EXPORT_SYMBOL_NS_GPL(libie_ctlq_recv, "LIBIE_CP");
>
...
> #endif /* __LIBIE_CONTROLQ_H */
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH net v2 1/1] net/sched: cls_flower: avoid stale mask references after delete
From: Paolo Abeni @ 2026-04-28 10:11 UTC (permalink / raw)
To: Jakub Kicinski, jiri
Cc: Ren Wei, netdev, jhs, davem, edumazet, horms, sbrivio, vladbu,
yuantan098, yifanwucs, tomapufckgml, bird, kanolyc, z1652074432
In-Reply-To: <20260423115129.6d8cbd15@kernel.org>
On 4/23/26 8:51 PM, Jakub Kicinski wrote:
> On Wed, 22 Apr 2026 00:03:02 +0800 Ren Wei wrote:
>> From: Yuhang Zheng <z1652074432@gmail.com>
>>
>> cls_flower keeps filter and mask state separately. After a filter is
>> removed or replaced, some paths can still need the mask data associated
>> with that filter.
>>
>> Cache the mask key and dissector in struct cls_fl_filter when the mask
>> is assigned, and use the cached copies in dump and offload paths. This
>> avoids depending on the external mask object's lifetime after delete or
>> replace.
>>
>> Fixes: 92149190067d ("net: sched: flower: set unlocked flag for flower proto ops")
>> Cc: stable@kernel.org
>> Reported-by: Yuan Tan <yuantan098@gmail.com>
>> Reported-by: Yifan Wu <yifanwucs@gmail.com>
>> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
>> Reported-by: Xin Liu <bird@lzu.edu.cn>
>> Tested-by: Yucheng Lu <kanolyc@gmail.com>
>> Signed-off-by: Yuhang Zheng <z1652074432@gmail.com>
>> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
>
> Jiri, do you have an opinion? Feels slightly wasteful (as sashiko points
> out), IDK if there's a cleaner fix.
I agree we should try hard to avoid the considerable struct
cls_fl_filter size increase.
Would be possible to move the fl_mask_put() into __fl_put, after the
rfcount decrement?!?
Or possibly would be less invasive to set the fd->mask to NULL in
__fl_delete() under the tp->lock, and explicitly check for NULL ptr in
before access (AFAICS, each access is under tp->lock).
/P
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v7 06/14] idpf: remove 'vport_params_reqd' field
From: Loktionov, Aleksandr @ 2026-04-28 10:10 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Salin, Samuel
In-Reply-To: <20260428082654.44364-7-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Tuesday, April 28, 2026 10:27 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Salin, Samuel
> <samuel.salin@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v7 06/14] idpf: remove
> 'vport_params_reqd' field
>
> From: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
>
> While sending a create vport message to the device control plane, a
> create vport virtchnl message is prepared with all the required info
> to initialize the vport. This info is stored in the adapter struct but
> never used thereafter. So, remove the said field.
>
> Signed-off-by: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Tested-by: Samuel Salin <Samuel.salin@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> drivers/net/ethernet/intel/idpf/idpf.h | 2 --
> drivers/net/ethernet/intel/idpf/idpf_lib.c | 2 --
> .../net/ethernet/intel/idpf/idpf_virtchnl.c | 30 +++++++-----------
> -
> 3 files changed, 10 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf.h
> b/drivers/net/ethernet/intel/idpf/idpf.h
> index 3a3dc9892d16..0d08f51be7e3 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf.h
> +++ b/drivers/net/ethernet/intel/idpf/idpf.h
> @@ -638,7 +638,6 @@ struct idpf_vc_xn_manager;
> * @avail_queues: Device given queue limits
> * @vports: Array to store vports created by the driver
> * @netdevs: Associated Vport netdevs
...
>
> adapter->vport_ids = kcalloc(num_max_vports, sizeof(u32),
> GFP_KERNEL);
> if (!adapter->vport_ids)
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v7 09/14] idpf: make mbx_task queueing and cancelling more consistent
From: Loktionov, Aleksandr @ 2026-04-28 10:11 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Salin, Samuel
In-Reply-To: <20260428082654.44364-10-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Tuesday, April 28, 2026 10:27 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Salin, Samuel
> <samuel.salin@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v7 09/14] idpf: make
> mbx_task queueing and cancelling more consistent
>
> As a consequence of refactoring idpf code to use libeth APIs,
> idpf_vc_xn_shutdown was merged with and replaced by
> idpf_deinit_dflt_mbx.
> This does not affect the Tx path, as it checked for a presence of an
> xn manager anyway. Rx processing is handled by the mbx_task that is
> not always cancelled before calling the new consolidated mailbox
> deinit function.
> Moreover, in the reset path idpf_intr_rel() reschedules it after the
> deinit is done. This leads to mbx_task referencing the freed mailbox
> and causing KASAN warnings.
>
> To remedy this, in the init path, do the first queueing of mbx_task in
> idpf_init_dflt_mbx(), in deinit and reset, always cancel the task in
> idpf_deinit_dflt_mbx() and in every flow first call
> idpf_mb_intr_rel_irq().
>
> Reviewed-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Tested-by: Samuel Salin <Samuel.salin@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> drivers/net/ethernet/intel/idpf/idpf.h | 1 +
> drivers/net/ethernet/intel/idpf/idpf_lib.c | 9 ++++-----
> drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 6 +++++-
> 3 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf.h
> b/drivers/net/ethernet/intel/idpf/idpf.h
> index 679539a1b947..1d0e32e47e87 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf.h
> +++ b/drivers/net/ethernet/intel/idpf/idpf.h
> @@ -984,6 +984,7 @@ void idpf_vc_event_task(struct work_struct *work);
> void idpf_dev_ops_init(struct idpf_adapter *adapter); void
> idpf_vf_dev_ops_init(struct idpf_adapter *adapter); int
> idpf_intr_req(struct idpf_adapter *adapter);
> +void idpf_mb_intr_rel_irq(struct idpf_adapter *adapter);
> void idpf_intr_rel(struct idpf_adapter *adapter);
> u16 idpf_get_max_tx_hdr_size(struct idpf_adapter *adapter); int
> idpf_initiate_soft_reset(struct idpf_vport *vport, diff --git
> a/drivers/net/ethernet/intel/idpf/idpf_lib.c
> b/drivers/net/ethernet/intel/idpf/idpf_lib.c
> index 0d131bf0993e..7988836fbae0 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_lib.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c
> @@ -68,9 +68,11 @@ static void idpf_deinit_vector_stack(struct
> idpf_adapter *adapter)
> * This will also disable interrupt mode and queue up mailbox task.
> Mailbox
> * task will reschedule itself if not in interrupt mode.
> */
...
>
> idpf_vport_params_buf_rel(adapter);
>
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH iwl-net] ice: only free LL TS IRQ when the handler is present
From: Simon Horman @ 2026-04-28 10:11 UTC (permalink / raw)
To: Aleksandr Loktionov
Cc: intel-wired-lan, anthony.l.nguyen, netdev, Sergey Temerkhanov
In-Reply-To: <20260424061958.918404-1-aleksandr.loktionov@intel.com>
On Fri, Apr 24, 2026 at 08:19:58AM +0200, Aleksandr Loktionov wrote:
> From: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
>
> Free LL TS IRQ handler only when the handler was previously installed.
> Unguarded calls to ice_free_irq_msix_ll_ts() may result in a double
> free when the LL TS interrupt is not supported by the firmware because
> ll_ts_irq.index is zero-initialised and would pass the index >= 0 check.
>
> Track whether the LL TS IRQ was successfully requested by initialising
> ll_ts_irq.index to -ENOENT in ice_init_pf() and when taking the
> "not supported" skip path or on request failure, then guard the free
> paths with ll_ts_irq.index >= 0.
>
> Fixes: 82e71b226e0e ("ice: Enable SW interrupt from FW for LL TS")
> Signed-off-by: Sergey Temerkhanov <sergey.temerkhanov@intel.com>
> Cc: stable@vger.kernel.org
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
FTR: There is an AI generated review of this patch available on sashiko.dev.
I believe the issues flagged there pre-date this patch and do not impact
this patch. So while I do not think they should block progress of this
patch I suggest looking over them to see if any follow-up is warranted.
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v7 11/14] ixd: add basic driver framework for Intel(R) Control Plane Function
From: Loktionov, Aleksandr @ 2026-04-28 10:11 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Michal Swiatkowski,
Zaremba, Larysa, Fijalkowski, Maciej, Tantilov, Emil S,
Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, R, Bharath
In-Reply-To: <20260428082654.44364-12-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Tuesday, April 28, 2026 10:27 AM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org; R, Bharath
> <bharath.r@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next v7 11/14] ixd: add basic
> driver framework for Intel(R) Control Plane Function
>
> Add module register and probe functionality. Add the required support
> to register IXD PCI driver, as well as probe and remove call backs.
> Enable the PCI device and request the kernel to reserve the memory
> resources that will be used by the driver. Finally map the BAR0
> address space.
>
> For now, use devm_alloc() to allocate adapter, as it requires the
> least amount of code. In a later commit, it will be replaced with a
> devlink alternative.
>
> Co-developed-by: Amritha Nambiar <amritha.nambiar@intel.com>
> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Tested-by: Bharath R <Bharath.r@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> .../device_drivers/ethernet/index.rst | 1 +
> .../device_drivers/ethernet/intel/ixd.rst | 39 ++++++
> drivers/net/ethernet/intel/Kconfig | 2 +
> drivers/net/ethernet/intel/Makefile | 1 +
> drivers/net/ethernet/intel/ixd/Kconfig | 13 ++
> drivers/net/ethernet/intel/ixd/Makefile | 8 ++
> drivers/net/ethernet/intel/ixd/ixd.h | 28 +++++
> drivers/net/ethernet/intel/ixd/ixd_lan_regs.h | 28 +++++
> drivers/net/ethernet/intel/ixd/ixd_main.c | 112
> ++++++++++++++++++
> 9 files changed, 232 insertions(+)
> create mode 100644
> Documentation/networking/device_drivers/ethernet/intel/ixd.rst
> create mode 100644 drivers/net/ethernet/intel/ixd/Kconfig
> create mode 100644 drivers/net/ethernet/intel/ixd/Makefile
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd.h
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd_lan_regs.h
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd_main.c
>
> diff --git
> a/Documentation/networking/device_drivers/ethernet/index.rst
> b/Documentation/networking/device_drivers/ethernet/index.rst
> index 5f3f06111911..5b6846f387f8 100644
> --- a/Documentation/networking/device_drivers/ethernet/index.rst
> +++ b/Documentation/networking/device_drivers/ethernet/index.rst
> @@ -38,6 +38,7 @@ Contents:
> intel/igbvf
> intel/ixgbe
> intel/ixgbevf
...
> +module_pci_driver(ixd_driver);
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH net 9/9] selftests/tc-testing: Add netem test case exercising loops
From: Paolo Abeni @ 2026-04-28 10:16 UTC (permalink / raw)
To: Jamal Hadi Salim, netdev
Cc: davem, edumazet, kuba, horms, jiri, stephen, victor, savy, will,
xmei5, pctammela, kuniyu, toke, willemdebruijnkernel, hxzene
In-Reply-To: <20260426190916.128489-10-jhs@mojatatu.com>
On 4/26/26 9:09 PM, Jamal Hadi Salim wrote:
> From: Victor Nogueira <victor@mojatatu.com>
>
> Add a netem nested duplicate test case to validate that it won't
> cause an infinite loop
>
> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Acked-by: Stephen Hemminger <stephen@networkplumber.org>
> Signed-off-by: Victor Nogueira <victor@mojatatu.com>
> ---
> .../tc-testing/tc-tests/qdiscs/netem.json | 33 ++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/tc-testing/tc-tests/qdiscs/netem.json b/tools/testing/selftests/tc-testing/tc-tests/qdiscs/netem.json
> index 3c4444961488..7c954989069d 100644
> --- a/tools/testing/selftests/tc-testing/tc-tests/qdiscs/netem.json
> +++ b/tools/testing/selftests/tc-testing/tc-tests/qdiscs/netem.json
> @@ -336,5 +336,36 @@
> "teardown": [
> "$TC qdisc del dev $DUMMY handle 1: root"
> ]
> - }
> + },
> + {
> + "id": "8c17",
> + "name": "Test netem's recursive duplicate",
This test is apparently consistently failing on our CI:
# not ok 365 8c17 - Test netem's recursive duplicate
# Value doesn't match: bytes: 294 != 196
# Matching against output: {'kind': 'netem', 'handle': '1:', 'root':
True, 'refcnt': 2, 'options': {'limit': 1, 'duplicate': {'duplicate': 1,
'correlation': 0}, 'seed': 17230427318941832146, 'ecn': False, 'gap':
0}, 'bytes': 196, 'packets': 2, 'drops': 1, 'overlimits': 0, 'requeues':
0, 'backlog': 0, 'qlen': 0}
sample full info avail:
https://github.com/p4tc-dev/tc-executor/blob/storage/artifacts/622604/1-tdc-sh/
/P
^ permalink raw reply
* [PATCH net] neighbour: neigh_xmit needs to release skb on -EAFNOSUPPORT
From: Pablo Neira Ayuso @ 2026-04-28 10:20 UTC (permalink / raw)
To: netdev; +Cc: netfilter-devel, edumazet, davem, kuba, pabeni, horms
Sashiko reports:
"... if the target neighbor table is NULL (for example, for
NEIGH_ND_TABLE when IPv6 is disabled), the code takes the out_unlock
path and bypasses the out_kfree_skb cleanup"
Fix this skb memleak by releasing the skb in case of -EAFNOSUPPORT.
Fixes: f8f2eb9de69a ("neighbour: add RCU protection to neigh_tables[]")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
net/core/neighbour.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 9e12524b67fa..2191668b79e3 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -3210,8 +3210,10 @@ int neigh_xmit(int index, struct net_device *dev,
rcu_read_lock();
tbl = rcu_dereference(neigh_tables[index]);
- if (!tbl)
- goto out_unlock;
+ if (!tbl) {
+ rcu_read_unlock();
+ goto out_kfree_skb;
+ }
if (index == NEIGH_ARP_TABLE) {
u32 key = *((u32 *)addr);
@@ -3227,7 +3229,6 @@ int neigh_xmit(int index, struct net_device *dev,
goto out_kfree_skb;
}
err = READ_ONCE(neigh->output)(neigh, skb);
-out_unlock:
rcu_read_unlock();
}
else if (index == NEIGH_LINK_TABLE) {
--
2.47.3
^ permalink raw reply related
* [PATCH RESEND net-next] net/sun: Fix multiple typos in comments
From: Jakub Raczynski @ 2026-04-28 10:17 UTC (permalink / raw)
To: netdev; +Cc: kuba, linux-kernel, kernel-janitors, Jakub Raczynski
In-Reply-To: <CGME20260428102434eucas1p1dcf39fcb439687a062b0e41ffa3f7830@eucas1p1.samsung.com>
There are some typos in comments and while they are harmless and not visible,
there is no reason not to fix them. Fix the ones that are not register related,
which might have intentional naming convention.
Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
---
drivers/net/ethernet/sun/cassini.c | 8 ++++----
drivers/net/ethernet/sun/cassini.h | 16 ++++++++--------
drivers/net/ethernet/sun/sunbmac.h | 2 +-
drivers/net/ethernet/sun/sungem.c | 4 ++--
drivers/net/ethernet/sun/sungem.h | 4 ++--
drivers/net/ethernet/sun/sunhme.c | 2 +-
6 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/sun/cassini.c b/drivers/net/ethernet/sun/cassini.c
index fe00e7dd3fe4..74fb0de12d21 100644
--- a/drivers/net/ethernet/sun/cassini.c
+++ b/drivers/net/ethernet/sun/cassini.c
@@ -1029,7 +1029,7 @@ static int cas_pcs_link_check(struct cas *cp)
* point a bit earlier in the sequence. If we had
* generated a reset a short time ago, we'll wait for
* the link timer to check the status until a
- * timer expires (link_transistion_jiffies_valid is
+ * timer expires (link_transition_jiffies_valid is
* true when the timer is running.) Instead of using
* a system timer, we just do a check whenever the
* link timer is running - this clears the flag after
@@ -4547,7 +4547,7 @@ static int cas_get_link_ksettings(struct net_device *dev,
}
if (linkstate != link_up) {
/* Force these to "unknown" if the link is not up and
- * autonogotiation in enabled. We can set the link
+ * autonegotiation in enabled. We can set the link
* speed to 0, but not cmd->duplex,
* because its legal values are 0 and 1. Ethtool will
* print the value reported in parentheses after the
@@ -4799,7 +4799,7 @@ static void cas_program_bridge(struct pci_dev *cas_pdev)
*/
pci_write_config_word(pdev, 0x50, (5 << 10) | 0x3ff);
- /* The Read Prefecth Policy register is 16-bit and sits at
+ /* The Read Prefetch Policy register is 16-bit and sits at
* offset 0x52. It enables a "smart" pre-fetch policy. We
* enable it and max out all of the settings since only one
* device is sitting underneath and thus bandwidth sharing is
@@ -4906,7 +4906,7 @@ static int cas_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
/*
* On some architectures, the default cache line size set
- * by pci_try_set_mwi reduces perforamnce. We have to increase
+ * by pci_try_set_mwi reduces performance. We have to increase
* it for this case. To start, we'll print some configuration
* data.
*/
diff --git a/drivers/net/ethernet/sun/cassini.h b/drivers/net/ethernet/sun/cassini.h
index 2d91f4936d52..0c24547a4534 100644
--- a/drivers/net/ethernet/sun/cassini.h
+++ b/drivers/net/ethernet/sun/cassini.h
@@ -259,7 +259,7 @@
/* output enables are provided for each device's chip select and for the rest
* of the outputs from cassini to its local bus devices. two sw programmable
- * bits are connected to general purpus control/status bits.
+ * bits are connected to general purpose control/status bits.
* DEFAULT: 0x7
*/
#define REG_BIM_LOCAL_DEV_EN 0x1020 /* BIM local device
@@ -404,7 +404,7 @@
GMII on SERDES pins for
monitoring. */
#define SATURN_PCFG_FSI 0x00000200 /* 1 = freeze serdes/gmii. all
- pins configed as outputs.
+ pins configured as outputs.
for power saving when using
internal phy. */
#define SATURN_PCFG_LAD 0x00000800 /* 0 = mac core led ctrl
@@ -622,7 +622,7 @@
enabled */
#define RX_CFG_SWIVEL_MASK 0x00001C00 /* byte offset of the 1st
data byte of the packet
- w/in 8 byte boundares.
+ w/in 8 byte boundaries.
this swivels the data
DMA'ed to header
buffers, jumbo buffers
@@ -1248,7 +1248,7 @@
*/
#define REG_MAC_TX_STATUS 0x6010 /* TX MAC status reg */
#define MAC_TX_FRAME_XMIT 0x0001 /* successful frame
- transmision */
+ transmission */
#define MAC_TX_UNDERRUN 0x0002 /* terminated frame
transmission due to
data starvation in the
@@ -1414,7 +1414,7 @@
* when passed to the host. to ensure proper operation, need to wait 3.2ms
* after clearing RX_CFG_EN before writing to any other RX MAC registers
* or other MAC parameters. alternatively, poll RX_CFG_EN until it clears
- * to 0. similary, HASH_FILTER_EN and ADDR_FILTER_EN have the same
+ * to 0. Similarly, HASH_FILTER_EN and ADDR_FILTER_EN have the same
* restrictions as CFG_EN.
*/
#define REG_MAC_RX_CFG 0x6034 /* RX MAC config reg */
@@ -1670,7 +1670,7 @@
* programmed in frame mode. load this register w/ a valid instruction
* (as per IEEE 802.3u MII spec). poll this register to check for instruction
* execution completion. during a read operation, this register will also
- * contain the 16-bit data returned by the tranceiver. unless specified
+ * contain the 16-bit data returned by the transceiver. unless specified
* otherwise, fields are considered "don't care" when polling for
* completion.
*/
@@ -1734,7 +1734,7 @@
#define MIF_CFG_POLL_REG_SHIFT 3
#define MIF_CFG_MDIO_0 0x0100 /* (ro) dual purpose.
when MDIO_0 is idle,
- 1 -> tranceiver is
+ 1 -> transceiver is
connected to MDIO_0.
when MIF is communicating
w/ MDIO_0 in bit-bang
@@ -1750,7 +1750,7 @@
mode, this bit indicates
the incoming bit stream
during a read op */
-#define MIF_CFG_POLL_PHY_MASK 0x7C00 /* tranceiver address to
+#define MIF_CFG_POLL_PHY_MASK 0x7C00 /* transceiver address to
be polled */
#define MIF_CFG_POLL_PHY_SHIFT 10
diff --git a/drivers/net/ethernet/sun/sunbmac.h b/drivers/net/ethernet/sun/sunbmac.h
index d379bd407eca..85778edcf8dc 100644
--- a/drivers/net/ethernet/sun/sunbmac.h
+++ b/drivers/net/ethernet/sun/sunbmac.h
@@ -205,7 +205,7 @@
#define FRAME_WRITE 0x50020000
#define FRAME_READ 0x60020000
-/* Tranceiver registers. */
+/* Transceiver registers. */
#define TCVR_PAL_SERIAL 0x00000001 /* Enable serial mode */
#define TCVR_PAL_EXTLBACK 0x00000002 /* Enable external loopback */
#define TCVR_PAL_MSENSE 0x00000004 /* Media sense */
diff --git a/drivers/net/ethernet/sun/sungem.c b/drivers/net/ethernet/sun/sungem.c
index 8e69d917d827..35c3226ce719 100644
--- a/drivers/net/ethernet/sun/sungem.c
+++ b/drivers/net/ethernet/sun/sungem.c
@@ -2187,7 +2187,7 @@ static void gem_do_stop(struct net_device *dev, int wol)
* if we did. This is not an issue however as the reset
* task is synchronized vs. us (rtnl_lock) and will do
* nothing if the device is down or suspended. We do
- * still clear reset_task_pending to avoid a spurrious
+ * still clear reset_task_pending to avoid a spurious
* reset later on in case we do resume before it gets
* scheduled.
*/
@@ -2370,7 +2370,7 @@ static int __maybe_unused gem_resume(struct device *dev_d)
gem_do_start(dev);
/* If we had WOL enabled, the cell clock was never turned off during
- * sleep, so we end up beeing unbalanced. Fix that here
+ * sleep, so we end up being unbalanced. Fix that here
*/
if (gp->asleep_wol)
gem_put_cell(gp);
diff --git a/drivers/net/ethernet/sun/sungem.h b/drivers/net/ethernet/sun/sungem.h
index 626302a9bc89..b921d3074017 100644
--- a/drivers/net/ethernet/sun/sungem.h
+++ b/drivers/net/ethernet/sun/sungem.h
@@ -352,7 +352,7 @@
#define MAC_HASH14 0x60F8UL /* Hash Table 14 Register */
#define MAC_HASH15 0x60FCUL /* Hash Table 15 Register */
#define MAC_NCOLL 0x6100UL /* Normal Collision Counter */
-#define MAC_FASUCC 0x6104UL /* First Attmpt. Succ Coll Ctr. */
+#define MAC_FASUCC 0x6104UL /* First Attempt. Succ Coll Ctr.*/
#define MAC_ECOLL 0x6108UL /* Excessive Collision Counter */
#define MAC_LCOLL 0x610CUL /* Late Collision Counter */
#define MAC_DTIMER 0x6110UL /* Defer Timer */
@@ -657,7 +657,7 @@
/* MIF Frame/Output Register. This 32-bit register allows the host to
* communicate with a transceiver in frame mode (as opposed to big-bang
- * mode). Writes by the host specify an instrution. After being issued
+ * mode). Writes by the host specify an instruction. After being issued
* the host must poll this register for completion. Also, after
* completion this register holds the data returned by the transceiver
* if applicable.
diff --git a/drivers/net/ethernet/sun/sunhme.c b/drivers/net/ethernet/sun/sunhme.c
index 4c9d5d4dd8a0..efbf042e9352 100644
--- a/drivers/net/ethernet/sun/sunhme.c
+++ b/drivers/net/ethernet/sun/sunhme.c
@@ -1118,7 +1118,7 @@ static void happy_meal_transceiver_check(struct happy_meal *hp, void __iomem *tr
*
* We use skb_reserve() to align the data block we get in the skb. We
* also program the etxregs->cfg register to use an offset of 2. This
- * imperical constant plus the ethernet header size will always leave
+ * emperical constant plus the ethernet header size will always leave
* us with a nicely aligned ip header once we pass things up to the
* protocol layers.
*
--
2.34.1
^ permalink raw reply related
* [PATCH RESEND net-next] net/intel/e100: Make read-only param_range struct static const
From: Jakub Raczynski @ 2026-04-28 10:26 UTC (permalink / raw)
To: netdev; +Cc: kuba, linux-kernel, kernel-janitors, Jakub Raczynski
In-Reply-To: <CGME20260428102655eucas1p1786b9974056b896017eed056a1fbac91@eucas1p1.samsung.com>
No need to use stack for single use read-only struct,
just make it static const.
Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
---
drivers/net/ethernet/intel/e100.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e100.c b/drivers/net/ethernet/intel/e100.c
index 9074b558de35..6bce22e15a97 100644
--- a/drivers/net/ethernet/intel/e100.c
+++ b/drivers/net/ethernet/intel/e100.c
@@ -1034,8 +1034,8 @@ static inline int e100_phy_supports_mii(struct nic *nic)
static void e100_get_defaults(struct nic *nic)
{
- struct param_range rfds = { .min = 16, .max = 256, .count = 256 };
- struct param_range cbs = { .min = 64, .max = 256, .count = 128 };
+ static const struct param_range rfds = { .min = 16, .max = 256, .count = 256 };
+ static const struct param_range cbs = { .min = 64, .max = 256, .count = 128 };
/* MAC type is encoded as rev ID; exception: ICH is treated as 82559 */
nic->mac = (nic->flags & ich) ? mac_82559_D101M : nic->pdev->revision;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/5] selftests/xsk: Introduce helpers for setting UMEM properties
From: bot+bpf-ci @ 2026-04-28 10:28 UTC (permalink / raw)
To: tushar.vyavahare, netdev, magnus.karlsson, maciej.fijalkowski,
stfomichev, kernelxing, davem, kuba, pabeni, ast, daniel,
tirthendu.sarkar, tushar.vyavahare
Cc: bpf, ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260428080317.702124-2-tushar.vyavahare@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3703 bytes --]
> diff --git a/tools/testing/selftests/bpf/prog_tests/test_xsk.c b/tools/testing/selftests/bpf/prog_tests/test_xsk.c
> index 7950c504ed28..d5cd8f590b25 100644
> --- a/tools/testing/selftests/bpf/prog_tests/test_xsk.c
> +++ b/tools/testing/selftests/bpf/prog_tests/test_xsk.c
> @@ -303,6 +303,22 @@ static void test_spec_reset(struct test_spec *test)
> __test_spec_init(test, test->ifobj_tx, test->ifobj_rx);
> }
>
> +static void test_spec_set_unaligned(struct test_spec *test)
> +{
> + test_spec_set_unaligned(test);
> +}
Does this function recurse unconditionally? Looking at the functions
this helper replaces, the body should set unaligned_mode = true on
both ifobj_tx->umem and ifobj_rx->umem. Instead, every call to
test_spec_set_unaligned() recurses into itself with the same argument
until the stack is exhausted.
Five tests introduced in this commit call the broken helper:
testapp_send_receive_unaligned()
testapp_send_receive_unaligned_mb()
testapp_unaligned_inv_desc()
testapp_unaligned_inv_desc_4001_frame()
testapp_unaligned_inv_desc_mb()
Each previously worked by directly setting the unaligned_mode fields.
After this patch, those direct assignments are replaced with calls to
test_spec_set_unaligned(), which crashes via stack overflow instead
of running the test.
> +
> +static void test_spec_set_frame_size(struct test_spec *test, u32 size)
> +{
> + test->ifobj_tx->umem->frame_size = size;
> + test->ifobj_rx->umem->frame_size = size;
> +}
> +
> +static void test_spec_set_frame_headroom(struct test_spec *test, u32 size)
> +{
> + test->ifobj_rx->umem->frame_headroom = size;
> +}
> +
[ ... ]
> @@ -2025,8 +2041,7 @@ int testapp_stats_fill_empty(struct test_spec *test)
>
> int testapp_send_receive_unaligned(struct test_spec *test)
> {
> - test->ifobj_tx->umem->unaligned_mode = true;
> - test->ifobj_rx->umem->unaligned_mode = true;
> + test_spec_set_unaligned(test);
> /* Let half of the packets straddle a 4K buffer boundary */
> if (pkt_stream_replace_half(test, MIN_PKT_SIZE, -MIN_PKT_SIZE / 2))
> return TEST_FAILURE;
> @@ -2037,8 +2052,7 @@ int testapp_send_receive_unaligned(struct test_spec *test)
> int testapp_send_receive_unaligned_mb(struct test_spec *test)
> {
> test->mtu = MAX_ETH_JUMBO_SIZE;
> - test->ifobj_tx->umem->unaligned_mode = true;
> - test->ifobj_rx->umem->unaligned_mode = true;
> + test_spec_set_unaligned(test);
> if (pkt_stream_replace(test, DEFAULT_PKT_CNT, MAX_ETH_JUMBO_SIZE))
> return TEST_FAILURE;
> return testapp_validate_traffic(test);
[ ... ]
> @@ -2380,10 +2391,8 @@ int testapp_unaligned_inv_desc_4001_frame(struct test_spec *test)
> u64 page_size, umem_size;
>
> /* Odd frame size so the UMEM doesn't end near a page boundary. */
> - test->ifobj_tx->umem->frame_size = 4001;
> - test->ifobj_rx->umem->frame_size = 4001;
> - test->ifobj_tx->umem->unaligned_mode = true;
> - test->ifobj_rx->umem->unaligned_mode = true;
> + test_spec_set_frame_size(test, 4001);
> + test_spec_set_unaligned(test);
> /* This test exists to test descriptors that staddle the end of
> * the UMEM but not a page.
> */
[ ... ]
> @@ -2411,8 +2422,7 @@ int testapp_aligned_inv_desc_mb(struct test_spec *test)
>
> int testapp_unaligned_inv_desc_mb(struct test_spec *test)
> {
> - test->ifobj_tx->umem->unaligned_mode = true;
> - test->ifobj_rx->umem->unaligned_mode = true;
> + test_spec_set_unaligned(test);
> return testapp_invalid_desc_mb(test);
> }
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/25045852068
^ permalink raw reply
* [PATCH v3 net-next] net/intel: Replace manual array size calculation with ARRAY_SIZE
From: Jakub Raczynski @ 2026-04-28 10:36 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, kuba, linux-kernel, kernel-janitors, przemyslaw.kitszel,
error27, Jakub Raczynski
In-Reply-To: <CGME20260428103757eucas1p132f3f1123fae21d596a51cbdce72c931@eucas1p1.samsung.com>
There are still places in the code where manual calculation of array size
exist, but it is good to enforce usage of single macro through the whole
code as it makes code bit more readable.
While at it, beautify condition surrounding it by reversing check and remove
unnecessary casting.
Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
Reviewed-by: Dan Carpenter <error27@gmail.com>
---
Link to v1/v2:
https://lore.kernel.org/kernel-janitors/20260421114029.2689961-1-j.raczynski@samsung.com/
Changes in v3:
- Add 'Reviewed-by' from previous thread
Changes in v2:
- Beautify code by removing excessive parentheses
- Reverse if condition to remove negation of whole check
drivers/net/ethernet/intel/i40e/i40e_adminq.h | 2 +-
drivers/net/ethernet/intel/iavf/iavf_adminq.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_adminq.h b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
index 1be97a3a86ce..dcf3baec7b73 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_adminq.h
+++ b/drivers/net/ethernet/intel/i40e/i40e_adminq.h
@@ -109,7 +109,7 @@ static inline int i40e_aq_rc_to_posix(int aq_ret, int aq_rc)
-EFBIG, /* I40E_AQ_RC_EFBIG */
};
- if (!((u32)aq_rc < (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0]))))
+ if (aq_rc >= ARRAY_SIZE(aq_to_posix))
return -ERANGE;
return aq_to_posix[aq_rc];
diff --git a/drivers/net/ethernet/intel/iavf/iavf_adminq.h b/drivers/net/ethernet/intel/iavf/iavf_adminq.h
index bbf5c4b3a2ae..dd2f61172157 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_adminq.h
+++ b/drivers/net/ethernet/intel/iavf/iavf_adminq.h
@@ -113,7 +113,7 @@ static inline int iavf_aq_rc_to_posix(int aq_ret, int aq_rc)
if (aq_ret == IAVF_ERR_ADMIN_QUEUE_TIMEOUT)
return -EAGAIN;
- if (!((u32)aq_rc < (sizeof(aq_to_posix) / sizeof((aq_to_posix)[0]))))
+ if (aq_rc >= ARRAY_SIZE(aq_to_posix))
return -ERANGE;
return aq_to_posix[aq_rc];
--
2.34.1
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH iwl-next v4 1/3] igc: remove unused autoneg_failed field
From: Abdul Rahim, Faizal @ 2026-04-28 10:39 UTC (permalink / raw)
To: Paul Menzel, khai.wen.tan
Cc: anthony.l.nguyen, andrew+netdev, davem, edumazet, kuba, pabeni,
intel-wired-lan, netdev, linux-kernel, faizal.abdul.rahim,
hong.aun.looi, khai.wen.tan, Aleksandr Loktionov
In-Reply-To: <a9cfe2dc-f4dc-48fb-a374-0d2902baa0c5@molgen.mpg.de>
Hi Paul,
Thank you for your review.
On 28/4/2026 2:56 pm, Paul Menzel wrote:
> [Cc: Removed stray *Looi*]
>
> Dear Khai Wen Tan,
>
>
> Thank you for your patch.
>
>
> Am 28.04.26 um 08:00 schrieb KhaiWenTan:
>
> (Should spaces be added in your name?)
>
>> From: Faizal Rahim <faizal.abdul.rahim@linux.intel.com>
>>
>> autoneg_failed in struct igc_mac_info is never set in the igc driver.
>> Remove the field and the dead code checking it in
>> igc_config_fc_after_link_up().
>
> Could you please elaborate. Why is removal the correct fix, and it’s not an
> incomplete feature? Does auto-negotiation always succeed?
>
Auto-negotiation does not always succeed, but igc does not use
autoneg_failed to handle that case, the field was never set anywhere
in the igc driver.
Before this patch, the only igc references to autoneg_failed were
the struct member declaration and the read in
igc_config_fc_after_link_up(). No igc code ever assigned it to true,
and git history shows no commit that added a setter since the code
creation in 2018.
The field originates from the e1000/e1000e fiber/serdes forced-link
path: when MAC-level auto-negotiation on fiber times out, the driver
forces link up and sets autoneg_failed so the flow-control code knows
pause was not negotiated and must be forced. igc has no fiber or
serdes media, it only supports copper (igc_media_type_copper), so
the code that sets autoneg_failed was never ported.
On copper, PHY auto-negotiation failure is handled differently:
- No link at all: igc_check_for_copper_link() returns before reaching
flow-control configuration, there's nothing to configure FC on.
- Link present but autoneg not yet complete:
igc_config_fc_after_link_up() checks MII_SR_AUTONEG_COMPLETE and
returns early without resolving pause. The next link-status event
re-triggers the check.
- Autoneg completes (including via parallel detection fallback when
the link partner doesn't autoneg): the PHY still sets
AUTONEG_COMPLETE but LP_ABILITY won't have PAUSE bits since the
partner never sent autoneg pages. The existing flow-control logic
in igc_config_fc_after_link_up() handles that correctly, it falls
through to igc_fc_none or igc_fc_rx_pause based on requested_mode.
None of these paths need autoneg_failed. Keeping the field would be
misleading to reader.
>> Reviewed-by: Looi, Hong Aun <hong.aun.looi@intel.com>
>
> Please order it to not use the comma: Hong Aun Looi
>
Will do, thanks.
>> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@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_hw.h | 1 -
>> drivers/net/ethernet/intel/igc/igc_mac.c | 16 +---------------
>> 2 files changed, 1 insertion(+), 16 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/intel/igc/igc_hw.h b/drivers/net/
>> ethernet/intel/igc/igc_hw.h
>> index be8a49a86d09..86ab8f566f44 100644
>> --- a/drivers/net/ethernet/intel/igc/igc_hw.h
>> +++ b/drivers/net/ethernet/intel/igc/igc_hw.h
>> @@ -92,7 +92,6 @@ struct igc_mac_info {
>> bool asf_firmware_present;
>> bool arc_subsystem_valid;
>>
>> - bool autoneg_failed;
>> bool get_link_status;
>> };
>>
>> diff --git a/drivers/net/ethernet/intel/igc/igc_mac.c b/drivers/net/
>> ethernet/intel/igc/igc_mac.c
>> index 7ac6637f8db7..142beb9ae557 100644
>> --- a/drivers/net/ethernet/intel/igc/igc_mac.c
>> +++ b/drivers/net/ethernet/intel/igc/igc_mac.c
>> @@ -438,28 +438,14 @@ void igc_config_collision_dist(struct igc_hw *hw)
>> * Checks the status of auto-negotiation after link up to ensure that the
>> * speed and duplex were not forced. If the link needed to be forced,
>> then
>> * flow control needs to be forced also. If auto-negotiation is enabled
>> - * and did not fail, then we configure flow control based on our link
>> - * partner.
>> + * then we configure flow control based on our link partner.
>> */
>> s32 igc_config_fc_after_link_up(struct igc_hw *hw)
>> {
>> u16 mii_status_reg, mii_nway_adv_reg, mii_nway_lp_ability_reg;
>> - struct igc_mac_info *mac = &hw->mac;
>> u16 speed, duplex;
>> s32 ret_val = 0;
>>
>> - /* Check for the case where we have fiber media and auto-neg failed
>> - * 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)
>> - ret_val = igc_force_mac_fc(hw);
>> -
>> - if (ret_val) {
>> - hw_dbg("Error forcing flow control settings\n");
>> - goto out;
>> - }
>> -
>> /* In auto-neg, we need to check and see if Auto-Neg has completed,
>> * and if so, how the PHY and link partner has flow control
>> * configured.
>
>
> Kind regards,
>
> Paul
>
^ permalink raw reply
* Re: [PATCH net v6] net: stmmac: Prevent NULL deref when RX memory exhausted
From: Paolo Abeni @ 2026-04-28 10:40 UTC (permalink / raw)
To: Sam Edwards, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski
Cc: Maxime Coquelin, Alexandre Torgue, Russell King (Oracle),
Maxime Chevallier, Ovidiu Panait, Vladimir Oltean, Baruch Siach,
Serge Semin, Giuseppe Cavallaro, netdev, linux-stm32,
linux-arm-kernel, linux-kernel, stable, Russell King
In-Reply-To: <20260422044503.5349-1-CFSworks@gmail.com>
On 4/22/26 6:45 AM, Sam Edwards wrote:
> The CPU receives frames from the MAC through conventional DMA: the CPU
> allocates buffers for the MAC, then the MAC fills them and returns
> ownership to the CPU. For each hardware RX queue, the CPU and MAC
> coordinate through a shared ring array of DMA descriptors: one
> descriptor per DMA buffer. Each descriptor includes the buffer's
> physical address and a status flag ("OWN") indicating which side owns
> the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set
> the flag and the MAC is only allowed to clear it, and both must move
> through the ring in sequence: thus the ring is used for both
> "submissions" and "completions."
>
> In the stmmac driver, stmmac_rx() bookmarks its position in the ring
> with the `cur_rx` index. The main receive loop in that function checks
> for rx_descs[cur_rx].own=0, gives the corresponding buffer to the
> network stack (NULLing the pointer), and increments `cur_rx` modulo the
> ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its
> position with `dirty_rx`, allocates fresh buffers and rearms the
> descriptors (setting OWN=1). If it fails any allocation, it simply stops
> early (leaving OWN=0) and will retry where it left off when next called.
>
> This means descriptors have a three-stage lifecycle (terms my own):
> - `empty` (OWN=1, buffer valid)
> - `full` (OWN=0, buffer valid and populated)
> - `dirty` (OWN=0, buffer NULL)
>
> But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In
> the past (see 'Fixes:'), there was a bug where the loop could cycle
> `cur_rx` all the way back to the first descriptor it dirtied, resulting
> in a NULL dereference when mistaken for `full`. The aforementioned
> commit resolved that *specific* failure by capping the loop's iteration
> limit at `dma_rx_size - 1`, but this is only a partial fix: if the
> previous stmmac_rx_refill() didn't complete, then there are leftover
> `dirty` descriptors that the loop might encounter without needing to
> cycle fully around. The current code therefore panics (see 'Closes:')
> when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to
> catch up to `dirty_rx`.
>
> Fix this by explicitly checking, before advancing `cur_rx`, if the next
> entry is dirty; exit the loop if so. This prevents processing of the
> final, used descriptor until stmmac_rx_refill() succeeds, but
> fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix
> intended: so remove the clamp as well. Since stmmac_rx_zc() is a
> copy-paste-and-tweak of stmmac_rx() and the code structure is identical,
> any fix to stmmac_rx() will also need a corresponding fix for
> stmmac_rx_zc(). Therefore, apply the same check there.
>
> In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the
> MAC sets OWN=0 on the final descriptor, it will be unable to send any
> further DMA-complete IRQs until it's given more `empty` descriptors.
> Currently, the driver simply *hopes* that the next stmmac_rx_refill()
> succeeds, risking an indefinite stall of the receive process if not. But
> this is not a regression, so it can be addressed in a future change.
>
> Fixes: b6cb4541853c7 ("net: stmmac: avoid rx queue overrun")
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221010
> Cc: stable@vger.kernel.org
> Suggested-by: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Sam Edwards <CFSworks@gmail.com>
> ---
>
> This is v6 of [1], which was itself split out of [2]. This patch prevents a
> NULL dereference in the stmmac receive path, and (at Russell's suggestion) in
> the zero-copy path as well.
>
> The approach is different from the previous version and checks the dirty_rx
> index in the loop proper, copied directly from Russell's suggestion [3]. Parts
> of the commit message also use his phrasing. For these reasons he is credited
> with `Suggested-by`.
>
> The commit message now acknowledges the pipeline stall that can occur in case
> of failure of the next stmmac_rx_refill() after the MAC consumes the final
> descriptor. I still intend to fix that bug when I can find the time to finish
> investigating and implement the timer as requested by Jakub, however I'm
> sending this patch now to resolve the outright _panic_ and simplify review.
> The stmmac_rx_zc() path is not affected by this stall.
>
> [1] https://lore.kernel.org/netdev/20260415023947.7627-1-CFSworks@gmail.com/
> [2] https://lore.kernel.org/netdev/20260401041929.12392-1-CFSworks@gmail.com/
> [3] https://lore.kernel.org/netdev/ad-LAB08-_rpmMzK@shell.armlinux.org.uk/
>
> ---
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index ca68248dbc78..3591755ea30b 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -5549,9 +5549,12 @@ static int stmmac_rx_zc(struct stmmac_priv *priv, int limit, u32 queue)
> break;
>
> /* Prefetch the next RX descriptor */
> - rx_q->cur_rx = STMMAC_NEXT_ENTRY(rx_q->cur_rx,
> - priv->dma_conf.dma_rx_size);
> - next_entry = rx_q->cur_rx;
> + next_entry = STMMAC_NEXT_ENTRY(rx_q->cur_rx,
> + priv->dma_conf.dma_rx_size);
> + if (unlikely(next_entry == rx_q->dirty_rx))
> + break;
Sashiko notes that breaking the loop of DMA descriptors owned by the CPU
may cause double accounting for the ingress stats by stmmac_rx_status().
AFAICS that is not a regression, as the existing later XDP check already
does the same, so I think that problem should be addressed separately.
/P
^ permalink raw reply
* [PATCH AUTOSEL 7.0-5.10] selftests: fib_nexthops: test stale has_v4 on nexthop replace
From: Sasha Levin @ 2026-04-28 10:41 UTC (permalink / raw)
To: patches, stable
Cc: Jiayuan Chen, David Ahern, Paolo Abeni, Sasha Levin, davem,
edumazet, kuba, shuah, netdev, linux-kselftest, linux-kernel
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>
From: Jiayuan Chen <jiayuan.chen@linux.dev>
[ Upstream commit 104f082f5ed6d19c5d85ca905ccd4e4d01aef66e ]
Add test cases that exercise the scenario where an IPv6 nexthop is
replaced with an IPv4 nexthop while being part of a group. The group's
has_v4 flag must be updated so that subsequent IPv6 route additions are
properly rejected.
Two cases are covered:
1. Gateway nexthop replaced across families with an existing IPv6
route on the group (rejected by fib6_check_nh_list).
2. Blackhole nexthop replaced across families with no existing IPv6
route on the group (fib6_check_nh_list returns early) — this is
the path that triggers a NULL ptr deref without the kernel fix.
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://patch.msgid.link/20260413114522.147784-2-jiayuan.chen@linux.dev
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have enough information to make my analysis. Let me synthesize the
findings.
## Phase 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject line parse**
- Record: Subsystem `selftests: fib_nexthops:`, action verb `test`,
summary: adds test cases for the "stale has_v4 on nexthop replace"
scenario.
**Step 1.2: Tags**
- Record: `Signed-off-by: Jiayuan Chen` (author), `Reviewed-by: David
Ahern` (subsystem maintainer), `Link:` to lore patch.msgid.link (patch
2 of 2), `Signed-off-by: Paolo Abeni` (netdev maintainer). No explicit
Cc: stable (expected, not a negative signal).
**Step 1.3: Body analysis**
- Record: Commit body explicitly references the kernel bug fixed by
patch 1/2 (sibling commit). It describes two test cases: a gateway-
family swap (caught by `fib6_check_nh_list`) and a blackhole-family
swap that "triggers a NULL ptr deref without the kernel fix". This
selftest is the test companion to a syzbot-reported NULL deref fix.
**Step 1.4: Hidden bug fix detection**
- Record: Not a hidden fix - this is explicitly a test-only commit. The
kernel bug fix is in the paired commit (patch 1/2).
## Phase 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- Record: Single file change
`tools/testing/selftests/net/fib_nexthops.sh`, +22 lines, 0 removed.
Function modified: `ipv6_fcnal_runtime()`. Scope: pure test additions
to an existing test function.
**Step 2.2: Code flow change**
- Record: Adds two new test scenarios appended to the existing test
series in `ipv6_fcnal_runtime()`. No existing code changed. New tests
use existing helper `run_cmd` and `log_test`.
**Step 2.3: Bug mechanism**
- Record: No bug mechanism - this is a test file, not kernel code. The
tests exercise:
1. `ip nexthop replace id 89 via 172.16.1.1` (IPv6→IPv4 gateway
replace), expects route rejection (exit 2)
2. `ip nexthop replace id 90 blackhole` after `ip -6 nexthop add id 90
blackhole` (IPv6→IPv4 blackhole), expects IPv6 route rejection and
unreachable ping
**Step 2.4: Fix quality**
- Record: Test additions are small, appended at a safe location (right
after the existing related test block and before `$IP nexthop flush`).
No regression risk to kernel runtime - only affects test output.
## Phase 3: GIT HISTORY INVESTIGATION
**Step 3.1: File history**
- Record: `tools/testing/selftests/net/fib_nexthops.sh` has accumulated
many test additions over the years. Recent stable-backported selftests
include `44741e9de29b` (Add test cases for error routes deletion) and
`46c1ef0cfcea5` (add test for IPv4 route with loopback IPv6 nexthop),
confirming that this file receives selftest backports.
**Step 3.2: The kernel fix paired with this test**
- Record: The kernel fix is `29c95185ba32b nexthop: fix IPv6 route
referencing IPv4 nexthop` (patch 1/2, immediately preceding this
commit in git history). That fix has:
- `Fixes: 7bf4796dd099 ("nexthops: add support for replace")` — buggy
code introduced in v5.3, present in all active stable trees (v5.10+,
v5.15+, v6.1+, v6.6+, v6.12+, v6.17+, v6.18+, v6.19+).
- Two syzbot reports referenced.
- 2-line `AF_INET == && AF_INET6 ==` → `!=` change; trivially correct.
- Reviewed-by David Ahern (nexthop subsystem maintainer).
**Step 3.3: Related changes**
- Record: Historically, similar 2-patch series (fix + selftest) have
been backported together to stable. The broader `ipv6_fcnal_runtime`
section uses infrastructure present in all stable trees.
**Step 3.4: Author**
- Record: Jiayuan Chen is an active contributor who has been submitting
many syzbot-related fixes recently (network UAF/NULL deref/race fixes,
etc.)
**Step 3.5: Dependencies**
- Record: This selftest depends on the kernel fix being present -
without it, the second test case would trigger the exact NULL pointer
dereference panic the fix addresses. If backported without the kernel
fix, running the test would crash the kernel.
## Phase 4: MAILING LIST RESEARCH
**Step 4.1: b4 dig on 104f082f5ed6d**
- Record: `b4 dig -c 104f082f5ed6d` matched exactly. Series is `[PATCH
net v1 1/2, 2/2]`. Only v1 exists. URL: https://lore.kernel.org/all/20
260413114522.147784-2-jiayuan.chen@linux.dev/
**Step 4.2: Recipients (b4 dig -w)**
- Record: Jiayuan Chen, netdev@vger.kernel.org, David Ahern (nexthop
maintainer), David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo
Abeni, Simon Horman, Shuah Khan, linux-kernel, linux-kselftest. All
appropriate.
**Step 4.3: Bug report**
- Record: Thread content (saved mbox) shows David Ahern's Reviewed-by
for both patches. Paolo Abeni applied both. The series was applied to
netdev/net.git (the -net tree for bug fixes, not net-next which is for
new features) - a strong indicator that this is treated as a bugfix,
not feature.
**Step 4.4: Related patches**
- Record: Only 2 patches in the series. The selftest (2/2) is the direct
companion to the kernel fix (1/2).
**Step 4.5: Stable discussion**
- Record: No explicit stable Cc in thread; none needed because the fix
has a Fixes: tag and Greg KH's AUTOSEL will consider both.
## Phase 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions modified**
- Record: Only `ipv6_fcnal_runtime()` in a shell test script. No C code
changes.
**Step 5.2-5.5: Impact surface**
- Record: This test is invoked when running the `fib_nexthops.sh`
selftest. No kernel-side impact. The test validates the kernel-side
`replace_nexthop_single()` function's handling of cross-family
(AF_INET6 → AF_INET) nexthop replacement within groups.
## Phase 6: STABLE TREE ANALYSIS
**Step 6.1: Code in stable**
- Record: The kernel bug exists since v5.3 (verified via `git tag
--contains 7bf4796dd099`). The `ipv6_fcnal_runtime` test function
exists in all active stable trees (v5.10+). Context lines in the diff
are present in stable.
**Step 6.2: Backport complications**
- Record: The surrounding `ipv6_fcnal_runtime` test body in
stable/linux-6.19.y matches (verified indirectly through file
history). The test should apply cleanly or with minor line-offset
adjustment. Test uses existing `$IP`, `run_cmd`, `log_test`,
`PING_TIMEOUT`, `$me` infrastructure all present in stable.
**Step 6.3: Related in stable**
- Record: No existing backport of this test. Similar companion selftests
(e.g., 44741e9de29b for error routes deletion fix) were backported
alongside their kernel fixes.
## Phase 7: SUBSYSTEM CONTEXT
**Step 7.1: Subsystem**
- Record: `tools/testing/selftests/net/` - network subsystem test.
Criticality: test-only, but validates IMPORTANT subsystem
(networking/nexthop API).
**Step 7.2: Activity**
- Record: The nexthop subsystem is actively developed; selftests are
regularly added.
## Phase 8: IMPACT AND RISK
**Step 8.1: Who affected**
- Record: The test-only change affects anyone running selftests. It's
not a runtime change.
**Step 8.2: Trigger conditions**
- Record: Only triggered when `fib_nexthops.sh` is explicitly run.
**Step 8.3: Failure mode**
- Record: Without the paired kernel fix in stable, running this selftest
WOULD trigger the NULL pointer dereference (test scenario 2 exercises
the exact reproducer). With the fix, the test passes silently.
**Step 8.4: Risk-benefit**
- Record:
- BENEFIT: Validates that the syzbot NULL-deref fix works in stable;
prevents regressions. Low-medium.
- RISK: Very low runtime risk (test-only). However, there is a
**dependency risk**: if the selftest is backported WITHOUT the
kernel fix (`29c95185ba32b`), running the test will crash the
kernel. This means the two commits must travel together.
## Phase 9: FINAL SYNTHESIS
**Step 9.1: Evidence**
- FOR: Companion to an important syzbot NULL-deref fix; small (22 lines)
self-contained test; adds to existing test file; accompanies fix that
is strongly stable-worthy; reviewed by subsystem maintainer; submitted
to -net tree (bugfix tree).
- AGAINST: Test-only commits don't themselves fix bugs; depends on the
kernel fix being present to avoid panic.
- UNRESOLVED: None material.
**Step 9.2: Stable rules**
- Obviously correct? Yes, pure test additions.
- Fixes a real bug? No (test only), but validates one.
- Important issue? Indirectly - validates a NULL-deref fix.
- Small and contained? Yes - 22 lines, one file, tools/ only.
- No new features? Yes - adds test cases, not new behavior.
- Can apply to stable? Yes - should apply cleanly to all active stable
trees.
**Step 9.3: Exceptions**
- Falls under the "test-only companion to a backport-worthy fix"
pattern. Historical precedent (e.g., `44741e9de29b`) shows such tests
are backported.
**Step 9.4: Decision**
This is a selftest commit that accompanies an important kernel fix
(`29c95185ba32b`, "nexthop: fix IPv6 route referencing IPv4 nexthop")
for a syzbot-reported NULL pointer dereference. The kernel fix itself is
a textbook stable candidate: 2-line surgical change, syzbot-reported,
Fixes: tag pointing to v5.3, reviewed by subsystem maintainer, applied
to the -net bugfix tree. Selftests that validate specific bug fixes are
commonly backported alongside those fixes (as demonstrated by
`44741e9de29b` already in stable), and stable maintainers generally want
such tests to be able to verify the backported fix works. The test is
small, self-contained, adds cases to an existing test file, uses only
pre-existing test infrastructure, and doesn't affect kernel runtime
behavior. Its only requirement is that it travel alongside the kernel
fix (which should also be selected).
## Verification
- [Phase 1] Parsed tags: `Signed-off-by: Jiayuan Chen`, `Reviewed-by:
David Ahern`, `Link:` to msgid.link, `Signed-off-by: Paolo Abeni`. No
Cc: stable (expected).
- [Phase 1] Body reference to "kernel fix" confirmed by reading mbox:
patch 2/2 is explicit companion to patch 1/2.
- [Phase 2] Diff inventory:
`tools/testing/selftests/net/fib_nexthops.sh` +22/-0 lines, only
function `ipv6_fcnal_runtime()` touched.
- [Phase 2] Read lines 1180-1246 of current `fib_nexthops.sh`: verified
the test insertion point is after existing replace-related tests and
before `$IP nexthop flush` / "weird IPv6 cases".
- [Phase 3] `git log --grep="stale has_v4"`: identified paired commits
`29c95185ba32b` (fix) and `104f082f5ed6d` (this selftest).
- [Phase 3] `git show 29c95185ba32b`: confirmed kernel fix is 2-line
AF_INET/AF_INET6 comparison change with Fixes: tag and syzbot reports.
- [Phase 3] `git show 7bf4796dd099 --stat`: buggy code in
`net/ipv4/nexthop.c` from Jun 2019.
- [Phase 3] `git tag --contains 7bf4796dd099 | grep v5`: buggy code
present from v5.3 onward.
- [Phase 4] `b4 dig -c 104f082f5ed6d`: matched original submission;
patch 2/2 of a 2-patch series.
- [Phase 4] `b4 dig -c 104f082f5ed6d -a`: only v1 of the series exists
(no revisions).
- [Phase 4] `b4 dig -c 104f082f5ed6d -w`: appropriate reviewers
including David Ahern (nexthop maintainer).
- [Phase 4] Read saved mbox `/tmp/selftest_thread.mbox`: found David
Ahern's `Reviewed-by` on both patches and patchwork-bot confirmation
that series was applied to netdev/net.git (bugfix tree).
- [Phase 6] `git log stable/linux-6.19.y --
tools/testing/selftests/net/fib_nexthops.sh`: confirmed `44741e9de29b`
and prior selftests were accepted into stable, establishing precedent.
- [Phase 6] `git log stable/linux-6.19.y --grep="has_v4"`: the new
kernel fix `29c95185ba32b` is not yet in stable (expected - just
merged to mainline).
- [Phase 8] Failure mode without accompanying kernel fix: running the
test would panic the kernel (verified by reading commit body and
reproducer).
- UNVERIFIED: Exact line-offset applicability to all stable trees not
tested with `git apply`, but surrounding function structure appears
stable across trees.
**YES**
tools/testing/selftests/net/fib_nexthops.sh | 22 +++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/tools/testing/selftests/net/fib_nexthops.sh b/tools/testing/selftests/net/fib_nexthops.sh
index 6eb7f95e70e15..ac868a7316946 100755
--- a/tools/testing/selftests/net/fib_nexthops.sh
+++ b/tools/testing/selftests/net/fib_nexthops.sh
@@ -1209,6 +1209,28 @@ ipv6_fcnal_runtime()
run_cmd "$IP ro replace 2001:db8:101::1/128 nhid 124"
log_test $? 0 "IPv6 route using a group after replacing v4 gateways"
+ # Replacing an IPv6 nexthop with an IPv4 nexthop should update has_v4
+ # for all groups using it, preventing IPv6 routes from referencing the
+ # group after the replace.
+ run_cmd "$IP nexthop add id 89 via 2001:db8:91::2 dev veth1"
+ run_cmd "$IP nexthop add id 125 group 89"
+ run_cmd "$IP nexthop replace id 89 via 172.16.1.1 dev veth1"
+ run_cmd "$IP ro replace 2001:db8:101::1/128 nhid 125"
+ log_test $? 2 "IPv6 route can not use group after v6 nexthop replaced by v4"
+
+ # Same scenario but with a blackhole nexthop: the group has no IPv6
+ # routes yet when the replace happens, so fib6_check_nh_list returns
+ # early without checking. has_v4 must still be updated to block
+ # subsequent IPv6 route additions.
+ run_cmd "$IP nexthop flush >/dev/null 2>&1"
+ run_cmd "$IP -6 nexthop add id 90 blackhole"
+ run_cmd "$IP nexthop add id 125 group 90"
+ run_cmd "$IP nexthop replace id 90 blackhole"
+ run_cmd "$IP -6 ro add 2001:db8:101::1/128 nhid 125"
+ log_test $? 2 "IPv6 route reject v6 blackhole replaced by v4 blackhole"
+ run_cmd "ip netns exec $me ping -6 2001:db8:101::1 -c1 -w$PING_TIMEOUT"
+ log_test $? 2 "Ping unreachable after rejected route"
+
$IP nexthop flush >/dev/null 2>&1
#
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.12] 9p/trans_xen: make cleanup idempotent after dataring alloc errors
From: Sasha Levin @ 2026-04-28 10:41 UTC (permalink / raw)
To: patches, stable
Cc: Yufan Chen, Stefano Stabellini, Dominique Martinet, Sasha Levin,
ericvh, lucho, davem, edumazet, kuba, pabeni, v9fs, netdev,
linux-kernel
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>
From: Yufan Chen <ericterminal@gmail.com>
[ Upstream commit 72cb9ee4f6d80962df17c9763b14e62e28fd85a2 ]
xen_9pfs_front_alloc_dataring() tears down resources on failure but
leaves ring fields stale. If xen_9pfs_front_init() later jumps to the
common error path, xen_9pfs_front_free() may touch the same resources
again, causing duplicate/invalid gnttab_end_foreign_access() calls and
potentially dereferencing a freed intf pointer.
Initialize dataring sentinels before allocation, gate teardown on those
sentinels, and clear ref/intf/data/irq immediately after each release.
This keeps cleanup idempotent for partially initialized rings and
prevents repeated teardown during init failure handling.
Signed-off-by: Yufan Chen <ericterminal@gmail.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Message-ID: <20260324153023.86853-2-ericterminal@gmail.com>
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have enough information to make a thorough analysis.
## Phase 1: Commit Message Forensics
**Step 1.1 — Subject line:**
- Record: subsystem=`9p/trans_xen`, action verb=`make` (with implicit
"fix"), summary=make cleanup idempotent after dataring alloc errors.
The phrase "make cleanup idempotent" is a classic disguised bug-fix
verb pattern — it's preventing duplicate teardown.
**Step 1.2 — Tags parsing:**
- Record: `Signed-off-by: Yufan Chen` (author), `Reviewed-by: Stefano
Stabellini <sstabellini@kernel.org>` (the original author/maintainer
of trans_xen.c — strong endorsement), `Message-ID:` to lore, `Signed-
off-by: Dominique Martinet <asmadeus@codewreck.org>` (9p maintainer).
No `Fixes:`, no `Cc: stable` (expected — that's why this is being
reviewed). No syzbot, no Reported-by.
**Step 1.3 — Body analysis:**
- Record: Body explains the mechanism precisely —
`xen_9pfs_front_alloc_dataring()` releases resources on failure but
leaves pointer/ref fields stale. If init then jumps to common error
path, `xen_9pfs_front_free()` re-touches them, causing
"duplicate/invalid `gnttab_end_foreign_access()` calls and potentially
dereferencing a freed `intf` pointer". Symptom = double teardown + UAF
on partially initialized rings during init failure.
**Step 1.4 — Hidden bug fix detection:**
- Record: Yes — "make cleanup idempotent" is a textbook hidden bug-fix
subject. The phrase "potentially dereferencing a freed intf pointer"
makes the use-after-free explicit. Cover letter (PATCH v3 0/2) states:
"Patch 1 fixes a potential double-free/Oops during initialization
failure" and "Tested error paths by forcing init failures on non-Xen
systems; dmesg confirms the new sentinel-based cleanup correctly
prevents Oops." So an actual Oops was observed.
## Phase 2: Diff Analysis
**Step 2.1 — Inventory:**
- Record: One file `net/9p/trans_xen.c`, +37/-14 lines, two functions
changed: `xen_9pfs_front_free()` and
`xen_9pfs_front_alloc_dataring()`. Single-file surgical fix, scope =
error path / cleanup only.
**Step 2.2 — Code flow:**
- Record (alloc_dataring): Before — fields are not initialized to
sentinels; on `out:` path, frees `bytes`/`intf` and revokes
`ring->ref` unconditionally without clearing the fields. After —
fields set to NULL/`INVALID_GRANT_REF`/-1 at the top; `out:` only
frees what's set, then clears the fields after each release.
- Record (front_free): Before — uses `if (priv->rings[i].irq > 0)` and
unconditionally calls `gnttab_end_foreign_access(ring->ref, NULL)` and
`free_page(ring->intf)`. After — uses `if (ring->irq >= 0)` then
resets to -1; checks `ring->ref != INVALID_GRANT_REF`; clears
intf/ref/data.in/data.out/irq after each release.
**Step 2.3 — Bug mechanism:**
- Record: This is BOTH (a) error path / resource leak fixes AND (d)
memory safety fixes:
- **Double-free of `ring->intf`**: `xen_9pfs_front_alloc_dataring()`
calls `free_page((unsigned long)ring->intf)` on failure but leaves
the pointer pointing to freed memory. Init then calls
`xen_9pfs_front_free()` whose check `if (!priv->rings[i].intf)
break;` does NOT trip (stale non-NULL pointer), so
`free_page((unsigned long)priv->rings[i].intf)` runs again → kernel
page double-free.
- **Double `gnttab_end_foreign_access` on `ring->ref`**: same path re-
revokes a stale grant ref.
- **Use-after-free of `ring->intf`**: if alloc failed at the
`xenbus_alloc_evtchn` stage, `ring->data.in` was set, then `bytes`
was freed by alloc_dataring's cleanup. On the second pass through
front_free, the `if (ring->data.in)` branch dereferences
`ring->intf->ring_order` and `ring->intf->ref[j]` (already-freed
page) → UAF read; then calls `gnttab_end_foreign_access` on stale
grant refs and `free_pages_exact` on already-freed `data.in`.
**Step 2.4 — Fix quality:**
- Record: Obviously correct — sentinel-based teardown is a standard
idempotent-cleanup pattern. Each release is gated by a sentinel and
the field is invalidated afterward. The change `irq > 0` → `irq >= 0`
is also a defensive correction (with explicit `-1` init, this is the
proper check). No new locking, no new APIs, no behaviour change on the
success path. Regression risk is very low.
## Phase 3: Git History Investigation
**Step 3.1 — Blame:**
- Record: The buggy alloc_dataring code came from `71ebd71921e45`
("xen/9pfs: connect to the backend"), part of v4.12-rc1 (Apr 2017).
Bug has been latent in every kernel since v4.12, so all currently-
supported LTS trees (5.4, 5.10, 5.15, 6.1, 6.6, 6.12, 6.18+) carry it.
**Step 3.2 — Fixes: target:**
- Record: No `Fixes:` tag in the commit. The introducing commit
`71ebd71921e45` is in mainline since v4.12, so it definitely exists in
every active stable tree.
**Step 3.3 — File history:**
- Record: Recent related fixes on this file that are already in stable:
`e43c608f40c06` ("9p/xen: fix release of IRQ"), `7ef3ae82a6ebb`
("9p/xen: fix init sequence"), `ea4f1009408ef` ("9p/xen: Fix UAF in
xen_9pfs_front_remove"), `ce8ded2e61f47` ("9p/xen: protect
xen_9pfs_front_free against concurrent calls"). All are small
stability fixes. The current patch is standalone and not part of a
multi-patch dependent series; series cover letter shows it splits into
2/2 patches but patch 2 (parser cleanup with kstrtouint) is
independent.
**Step 3.4 — Author context:**
- Record: Yufan Chen is a contributor; the patch was reviewed by Stefano
Stabellini who is the original author/long-time maintainer of
`trans_xen.c` (copyright at top of file). Authoritative review.
**Step 3.5 — Dependencies:**
- Record: Uses `INVALID_GRANT_REF`, defined in
`include/xen/grant_table.h` since `bce21a2b48ede` (v5.12-rc3). This
macro is present in all current stable LTS trees (verified in 5.15 —
`#define INVALID_GRANT_REF ((grant_ref_t)-1)` at line 57). No other
dependencies. Self-contained patch.
## Phase 4: Mailing List Research
**Step 4.1 — b4 dig:**
- Record: `b4 dig -c 72cb9ee4f6d80` matched by patch-id, returned `https
://lore.kernel.org/all/20260324153023.86853-2-ericterminal@gmail.com/`
(v3 1/2).
- `b4 dig -a` showed evolution: v1 (single patch, 2026-02-25), v2 (1/4
in mixed series, 2026-02-25), v3 (1/2 in dedicated 9p/trans_xen
series, 2026-03-24). Applied version is the latest.
- v3 cover letter: "Patch 1 fixes a potential double-free/Oops during
initialization failure by making the dataring cleanup idempotent."
Confirms the author treats this as a stability/bug fix.
**Step 4.2 — Reviewers:**
- Record: Reviewed-by Stefano Stabellini (subsystem maintainer), CC'd
Eric Van Hensbergen (ericvh@kernel.org), Lucho Ionkov
(lucho@ionkov.net), and the v9fs list. The right people reviewed it.
**Step 4.3 — Bug report:**
- Record: No external bug report. Bug discovered by code inspection and
confirmed by deliberate fault injection during testing (per the v3
cover letter). No syzbot.
**Step 4.4 — Series context:**
- Record: 2-patch series. Patch 2 ("replace simple_strto* with
kstrtouint") is unrelated parser modernization and not stable
material. This patch (1/2) is fully standalone — no dependency on
patch 2.
**Step 4.5 — Stable list:**
- Record: No prior discussion on stable list found via b4 dig. Author
did not Cc stable, but recent precedent shows similar 9p/xen
idempotency-style fixes (`e43c608`, `7ef3ae82`, `ea4f1009`,
`ce8ded2e`) were backported to 5.15.y, 6.1.y, 6.6.y, 6.12.y as stable-
eligible bug fixes.
## Phase 5: Code Semantic Analysis
**Step 5.1 — Functions modified:**
- Record: `xen_9pfs_front_free()`, `xen_9pfs_front_alloc_dataring()`.
**Step 5.2 — Callers:**
- Record: `xen_9pfs_front_alloc_dataring` is called from
`xen_9pfs_front_init` (in a loop over `XEN_9PFS_NUM_RINGS`).
`xen_9pfs_front_free` is called from `xen_9pfs_front_remove` (xenbus
driver remove callback) AND from `xen_9pfs_front_init` error path.
Critical: both callers are in the device probe/teardown flow, which is
exactly the scenario the patch protects against.
**Step 5.3 — Callees:**
- Record: `gnttab_end_foreign_access`, `free_page`, `free_pages_exact`,
`unbind_from_irqhandler`, `cancel_work_sync`.
`gnttab_end_foreign_access(ref, NULL)` calls into
`gnttab_try_end_foreign_access` → `_gnttab_end_foreign_access_ref` →
indirect into the gnttab interface; reentering with stale ref produces
warnings or worse on backend interaction.
**Step 5.4 — Reachability:**
- Record: Triggered from `xenbus_driver` callback chain when a 9pfs
frontend tries to come up and any of these fails: `get_zeroed_page`
(memory pressure), `gnttab_grant_foreign_access` (grant-table
exhaustion — realistic on busy Xen guests), `alloc_pages_exact`,
`xenbus_alloc_evtchn` (event-channel exhaustion),
`bind_evtchn_to_irqhandler`. Reachable on every 9pfs frontend probe
under resource pressure or hostile/buggy backend.
**Step 5.5 — Similar patterns:**
- Record: Idempotent-cleanup-with-sentinels is the same pattern used
throughout xen frontends. The previous 9p/xen fixes (`e43c608`,
`ce8ded2e`) target the same teardown function and were backported to
stable.
## Phase 6: Cross-Referencing & Stable Tree Analysis
**Step 6.1 — Code presence:**
- Record: Verified by reading `git show
stable/linux-6.6.y:net/9p/trans_xen.c` and `git show
stable/linux-6.12.y:net/9p/trans_xen.c` — both contain the same buggy
`xen_9pfs_front_alloc_dataring()` cleanup pattern and the same
`xen_9pfs_front_free()` un-gated double-teardown. Bug present in 5.4,
5.10, 5.15, 6.1, 6.6, 6.12, 6.18 (all active LTS).
**Step 6.2 — Backport complications:**
- Record: 6.12.y file matches mainline structure almost exactly — minor
context-only deltas. 6.6.y / 6.1.y / 5.15.y use `priv->num_rings`
instead of the constant in the loop and have a slightly different
`xen_9pfs_front_free` outline (no `priv->rings` NULL check at the top
in 6.6) — those need trivial mechanical adjustment.
`INVALID_GRANT_REF` is available in all active LTS. Expected
difficulty: clean-to-minor.
**Step 6.3 — Related fixes already in stable:**
- Record: Verified — `2bb3ee1bf2375` (6.6), `b9e26059664bd` (6.1),
`4950408793b11` (5.15), `530bc9f03a102` (6.12) are the IRQ-double-free
fix; `592fb738d8682`/`91b4763da3ee6`/`db94e06c24cd4`/`e978643c4c9c0`
are the init-sequence fix; `a5d00dff97118` is the concurrent-
front_free protection. None of these address the alloc-failure
idempotency bug — this patch fills a remaining gap.
## Phase 7: Subsystem Context
**Step 7.1 — Subsystem:**
- Record: `net/9p/` — 9P virtual filesystem transport, Xen-specific.
Criticality: PERIPHERAL globally but IMPORTANT for users who actually
use 9P over Xen (e.g., Edera and other Xen-based confidential-
computing/lightweight-VM stacks who recently submitted other 9p/xen
fixes).
**Step 7.2 — Activity:**
- Record: Active subsystem with periodic stability-fix submissions in
2024–2026; multiple recent patches went to stable.
## Phase 8: Impact and Risk
**Step 8.1 — Affected population:**
- Record: Users of Xen 9pfs frontend. Niche but real (Edera, others
using 9p mounts in Xen guests).
**Step 8.2 — Trigger conditions:**
- Record: Failure during second-ring allocation in
`xen_9pfs_front_init`. Triggers include memory pressure, grant-table
exhaustion, evtchn exhaustion, malicious/buggy Xen backend. Not user-
triggerable from unprivileged userspace, but a malicious backend can
deliberately starve the frontend (Xen security model assumes the
backend is more privileged but a frontend should not crash on backend
misbehaviour).
**Step 8.3 — Severity:**
- Record: When triggered → kernel page double-free + grant ref double-
revoke + use-after-free read on a freed page. Failure mode: kernel
oops / panic / memory corruption. Severity: CRITICAL.
**Step 8.4 — Risk-benefit:**
- Record: Benefit = high (eliminates a confirmed Oops on init failure,
idempotent cleanup is universally desirable). Risk = very low — pure
error-path tightening, sentinel-based, no behaviour change on success
path, reviewed by the original author Stefano Stabellini, tested with
deliberate fault injection.
## Phase 9: Final Synthesis
**Evidence FOR backport:**
- Real bug — double-free of kernel page, use-after-free, double grant-
ref revoke during init failure (CRITICAL severity)
- Reproduced (Oops) by author with fault injection in virtme-ng
- Reviewed by the original author/maintainer of the file (Stefano
Stabellini)
- Small, surgical, single file (+37/-14)
- Bug present since v4.12 — affects every active LTS
- All dependencies (`INVALID_GRANT_REF`) present in stable trees
- Recent precedent: 4 similar 9p/xen fixes have been backported to
5.15/6.1/6.6/6.12
- Idempotent cleanup is a textbook stable-friendly pattern, no
behavioural change on success path
**Evidence AGAINST:**
- No `Fixes:` tag, no `Cc: stable` (expected, not a real negative
signal)
- No external user bug report (but author observed Oops during testing)
- Niche subsystem (9p over Xen)
**Stable rules checklist:**
1. Obviously correct and tested? Yes — sentinel pattern, reviewed by
maintainer, fault-injected by author.
2. Real bug? Yes — confirmed Oops.
3. Important issue? Yes — double-free / UAF (CRITICAL).
4. Small and contained? Yes — 51 lines, one file.
5. No new features? Correct — pure cleanup hardening.
6. Applies to stable? Yes for 6.12.y essentially clean; 6.6/6.1/5.15
need trivial loop-variable adjustment.
**Decision:** This is a small, well-reviewed, fault-injection-confirmed
fix for a memory-safety bug (double-free + UAF) that has been latent in
Xen 9p frontend code since 2017 and exists in every active LTS tree. It
matches the pattern of multiple similar 9p/xen stability fixes already
backported to stable. Backport-worthy.
## Verification
- [Phase 1] Read commit message and v3 cover letter from saved mbox
`/tmp/9pxen-thread.mbox` — confirmed "fixes a potential double-
free/Oops during initialization failure" and "Tested error paths by
forcing init failures... dmesg confirms the new sentinel-based cleanup
correctly prevents Oops".
- [Phase 1] Confirmed Reviewed-by from Stefano Stabellini in the mbox
thread.
- [Phase 2] Read full pre-fix `net/9p/trans_xen.c` and post-fix;
manually traced ring-1 alloc failure scenarios at four distinct
failure points and confirmed each leads to either double
`free_page(intf)`, double `gnttab_end_foreign_access(ref)`, or UAF
read of `ring->intf->ring_order`/`ring->intf->ref[j]`.
- [Phase 3] `git log --oneline --follow net/9p/trans_xen.c` showed
`71ebd71921e45` as origin; `git describe --contains 71ebd71921e45` →
`v4.12-rc1~103^2~31`.
- [Phase 3] `git show 71ebd71921e45` confirmed the pre-existing buggy
`xen_9pfs_front_alloc_dataring`+`xen_9pfs_front_free` cleanup pattern
was introduced in 2017.
- [Phase 3] Found prior related fixes (`e43c608`, `7ef3ae82`,
`ea4f1009`, `ce8ded2e`) on the same file with their stable tree
counterparts.
- [Phase 4] `b4 dig -c 72cb9ee4f6d80` returned the lore URL for v3 1/2.
- [Phase 4] `b4 dig -c 72cb9ee4f6d80 -a` showed v1 → v2 → v3 evolution;
applied version is latest.
- [Phase 4] `b4 dig -m /tmp/9pxen-thread.mbox` saved full thread; read
entire mbox with Read tool.
- [Phase 4] No `Cc: stable` and no NAKs in the thread; only Reviewed-by
from Stefano.
- [Phase 5] Confirmed `xen_9pfs_front_alloc_dataring` is called from
`xen_9pfs_front_init` (loop over rings) and `xen_9pfs_front_free` is
called from both `xen_9pfs_front_init` error path and
`xen_9pfs_front_remove`.
- [Phase 5] Read `drivers/xen/grant-table.c` to confirm
`gnttab_end_foreign_access` chain — invoking on a stale ref re-enters
the gnttab interface.
- [Phase 6] Verified `INVALID_GRANT_REF` exists in
`include/xen/grant_table.h` of mainline (line 57) and
`stable/linux-5.15.y` — backport-friendly.
- [Phase 6] Read `stable/linux-6.6.y:net/9p/trans_xen.c` and
`stable/linux-6.12.y:net/9p/trans_xen.c` and confirmed the buggy code
pattern is present in both.
- [Phase 6] Verified previous 9p/xen fixes were backported to
5.15/6.1/6.6/6.12 stable branches via `git log <branch> --
net/9p/trans_xen.c`.
- [Phase 8] Failure mode verified by manual trace: double-free of a
kernel page + use-after-free read on stale `ring->intf` + double
grant-revoke → CRITICAL.
- UNVERIFIED: No external bug report or syzbot reproducer; severity
rests on author's fault-injection result and direct code analysis
(both consistent with each other).
**YES**
net/9p/trans_xen.c | 51 +++++++++++++++++++++++++++++++++-------------
1 file changed, 37 insertions(+), 14 deletions(-)
diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
index 47af5a10e9212..85b9ebfaa17a6 100644
--- a/net/9p/trans_xen.c
+++ b/net/9p/trans_xen.c
@@ -283,25 +283,33 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
cancel_work_sync(&ring->work);
- if (!priv->rings[i].intf)
+ if (!ring->intf)
break;
- if (priv->rings[i].irq > 0)
- unbind_from_irqhandler(priv->rings[i].irq, ring);
- if (priv->rings[i].data.in) {
- for (j = 0;
- j < (1 << priv->rings[i].intf->ring_order);
+ if (ring->irq >= 0) {
+ unbind_from_irqhandler(ring->irq, ring);
+ ring->irq = -1;
+ }
+ if (ring->data.in) {
+ for (j = 0; j < (1 << ring->intf->ring_order);
j++) {
grant_ref_t ref;
- ref = priv->rings[i].intf->ref[j];
+ ref = ring->intf->ref[j];
gnttab_end_foreign_access(ref, NULL);
+ ring->intf->ref[j] = INVALID_GRANT_REF;
}
- free_pages_exact(priv->rings[i].data.in,
- 1UL << (priv->rings[i].intf->ring_order +
- XEN_PAGE_SHIFT));
+ free_pages_exact(ring->data.in,
+ 1UL << (ring->intf->ring_order +
+ XEN_PAGE_SHIFT));
+ ring->data.in = NULL;
+ ring->data.out = NULL;
+ }
+ if (ring->ref != INVALID_GRANT_REF) {
+ gnttab_end_foreign_access(ring->ref, NULL);
+ ring->ref = INVALID_GRANT_REF;
}
- gnttab_end_foreign_access(priv->rings[i].ref, NULL);
- free_page((unsigned long)priv->rings[i].intf);
+ free_page((unsigned long)ring->intf);
+ ring->intf = NULL;
}
kfree(priv->rings);
}
@@ -334,6 +342,12 @@ static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
int ret = -ENOMEM;
void *bytes = NULL;
+ ring->intf = NULL;
+ ring->data.in = NULL;
+ ring->data.out = NULL;
+ ring->ref = INVALID_GRANT_REF;
+ ring->irq = -1;
+
init_waitqueue_head(&ring->wq);
spin_lock_init(&ring->lock);
INIT_WORK(&ring->work, p9_xen_response);
@@ -379,9 +393,18 @@ static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
for (i--; i >= 0; i--)
gnttab_end_foreign_access(ring->intf->ref[i], NULL);
free_pages_exact(bytes, 1UL << (order + XEN_PAGE_SHIFT));
+ ring->data.in = NULL;
+ ring->data.out = NULL;
+ }
+ if (ring->ref != INVALID_GRANT_REF) {
+ gnttab_end_foreign_access(ring->ref, NULL);
+ ring->ref = INVALID_GRANT_REF;
+ }
+ if (ring->intf) {
+ free_page((unsigned long)ring->intf);
+ ring->intf = NULL;
}
- gnttab_end_foreign_access(ring->ref, NULL);
- free_page((unsigned long)ring->intf);
+ ring->irq = -1;
return ret;
}
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] ipv6: Cap TLV scan in ip6_tnl_parse_tlv_enc_lim
From: Sasha Levin @ 2026-04-28 10:41 UTC (permalink / raw)
To: patches, stable
Cc: Daniel Borkmann, Ido Schimmel, Justin Iurman, Jakub Kicinski,
Sasha Levin, davem, dsahern, edumazet, pabeni, netdev,
linux-kernel
In-Reply-To: <20260428104133.2858589-1-sashal@kernel.org>
From: Daniel Borkmann <daniel@iogearbox.net>
[ Upstream commit 076b8cad77aa96557719fb5effe8703bfb64df00 ]
Commit 47d3d7ac656a ("ipv6: Implement limits on Hop-by-Hop and
Destination options") added net.ipv6.max_{hbh,dst}_opts_{cnt,len}
and applied them in ip6_parse_tlv(), the generic TLV walker
invoked from ipv6_destopt_rcv() and ipv6_parse_hopopts().
ip6_tnl_parse_tlv_enc_lim() does not go through ip6_parse_tlv();
it has its own hand-rolled TLV scanner inside its NEXTHDR_DEST
branch which looks for IPV6_TLV_TNL_ENCAP_LIMIT. That inner
loop is bounded only by optlen, which can be up to 2048 bytes.
Stuffing the Destination Options header with 2046 Pad1 (type=0)
entries advances the scanner a single byte at a time, yielding
~2000 TLV iterations per extension header.
Reusing max_dst_opts_cnt to bound the TLV iterations, matching
the semantics from 47d3d7ac656a, would require duplicating
ip6_parse_tlv() to also validate Pad1/PadN payload. It would
also mandate enforcing max_dst_opts_len, since otherwise an
attacker shifts the axis to few options with a giant PadN and
recovers the original DoS. Allowing up to 8 options before the
tunnel encapsulation limit TLV is liberal enough; in practice
encap limit is the first TLV. Thus, go with a hard-coded limit
IP6_TUNNEL_MAX_DEST_TLVS (8).
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information I need. Let me compile the comprehensive
analysis.
# Phase-by-Phase Analysis
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1 - Subject Line Parse:**
- Subsystem prefix: `ipv6:`
- Action verb: "Cap" (limit/bound) — implicit bug fix verb
- Summary: Add a hard cap on TLV iterations in
`ip6_tnl_parse_tlv_enc_lim()`
- Record: `[ipv6] [Cap] [Bound the TLV scan loop to prevent excessive
iterations]`
**Step 1.2 - Tag Parsing:**
- Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> (author)
- Reviewed-by: Ido Schimmel <idosch@nvidia.com>
- Reviewed-by: Justin Iurman <justin.iurman@gmail.com>
- Signed-off-by: Jakub Kicinski <kuba@kernel.org> (netdev maintainer)
- No explicit Fixes: tag, no Cc: stable, no Reported-by, no Link:
- References commit `47d3d7ac656a` ("ipv6: Implement limits on Hop-by-
Hop and Destination options") in message body
- Record: Two independent Reviewed-by tags, applied by subsystem
maintainer Kicinski. Pedigree is strong.
**Step 1.3 - Commit Body Analysis:**
- Describes bug: `ip6_tnl_parse_tlv_enc_lim()` has a hand-rolled TLV
scanner in its `NEXTHDR_DEST` branch, bounded only by `optlen` (up to
2048 bytes)
- Attack: "Stuffing the Destination Options header with 2046 Pad1
(type=0) entries advances the scanner a single byte at a time,
yielding ~2000 TLV iterations per extension header"
- Symptom: CPU-consuming DoS — an attacker can force ~2000 iterations
per IPv6 extension header in a received packet
- Mentions that commit `47d3d7ac656a` already fixed the same class of
bug in `ip6_parse_tlv()` (the generic TLV walker), but this separate
hand-rolled scanner was missed
- Record: Clear DoS vector description, author's understanding of the
bug mechanism is thorough
**Step 1.4 - Hidden Bug Fix Detection:**
- Subject says "Cap" rather than "Fix" but body makes explicit that this
is a DoS fix
- This is NOT a hidden fix — the DoS mechanism is described openly
- Record: Commit is a clear bug fix despite neutral-sounding subject
verb
## PHASE 2: DIFF ANALYSIS
**Step 2.1 - Inventory:**
- Single file: `net/ipv6/ip6_tunnel.c`
- +6 lines, 0 removed
- Function modified: `ip6_tnl_parse_tlv_enc_lim()`
- Scope: single-file surgical fix
- Record: 6 lines in 1 file, 1 function — minimal scope
**Step 2.2 - Code Flow:**
- Before: `while (1)` loop with break only when `i + sizeof(*tel) >
optlen` — can iterate up to ~optlen/1 times when all entries are Pad1
(type=0 advances `i` by 1 byte)
- After: new local `int tlv_cnt = 0;` declared; `if (unlikely(tlv_cnt++
>= IP6_TUNNEL_MAX_DEST_TLVS)) break;` added at top of loop
- New macro `#define IP6_TUNNEL_MAX_DEST_TLVS 8` at file scope
- Record: Loop now breaks after at most 8 TLVs scanned per extension
header
**Step 2.3 - Bug Mechanism Classification:**
- Category: (h) Hardware workarounds? No. This is category close to
"bounds check" / DoS prevention — fits between logic/correctness (g)
and memory safety (d)
- Specific: A counter-based upper bound on a while loop prevents
attacker-controlled iteration count from causing excessive CPU use per
received packet
- Record: DoS/CPU-exhaustion fix via iteration bound
**Step 2.4 - Fix Quality:**
- Obviously correct: the counter is incremented unconditionally,
compared with constant 8
- Minimal: 6 lines, self-contained inside existing function
- Regression risk: In practice the encap limit TLV is the first TLV. 8
is generous. Legitimate traffic never hits this cap. Extremely low
risk.
- Record: High-quality, obviously-correct, minimal fix
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1 - Git Blame:**
- Ran `git blame -L 430,456 net/ipv6/ip6_tunnel.c`
- Core `while (1)` loop and TLV scanning logic attributed to
`1da177e4c3f4` ("Linux-2.6.12-rc2", 2005-04-16) — the very beginning
of git history
- Surrounding `nexthdr == NEXTHDR_DEST` check modified by
`d375b98e024898` (Eric Dumazet, 2024-01-05)
- Earlier pointer-math/bounds fixes: `fbfa743a9d2a0f` (2017),
`63117f09c768be` (2017)
- Record: **Buggy code present since git epoch (2005). Bug exists in all
supported stable trees.**
**Step 3.2 - Follow Fixes: Tag:**
- No Fixes: tag. In the lore discussion, Ido Schimmel explicitly
suggested: "Fixes: 1da177e4c3f4 ('Linux-2.6.12-rc2')"
- Referenced commit `47d3d7ac656a` (Tom Herbert, 2017-10-30) addressed
the same DoS in `ip6_parse_tlv()` by adding
`max_dst_opts_cnt`/`max_dst_opts_len` sysctls. It did not cover this
hand-rolled scanner.
- Record: Bug is as old as git history; the analogous fix for the
generic path is already in stable.
**Step 3.3 - File History:**
- Recent changes in this file are unrelated (DSCP handling, netns
conversion, GRO fixes, skb_vlan_inet_prepare, etc.) — no prerequisite
or competing fix
- `d375b98e024898` ("ip6_tunnel: fix NEXTHDR_FRAGMENT handling in
ip6_tnl_parse_tlv_enc_lim()", 2024) is the most recent change in this
function — itself a fix that went to stable
- Record: Standalone fix; no dependencies identified
**Step 3.4 - Author's Background:**
- Daniel Borkmann: networking/BPF maintainer, extensive
ipv6/netfilter/BPF history
- Not a new contributor
- Record: Author has deep kernel/networking expertise
**Step 3.5 - Dependencies:**
- Patch only adds a local counter and a new macro — no external symbol
dependencies
- Applies to the existing while loop that has been stable for decades
- Record: Standalone, self-contained
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1 - b4 dig:**
- `b4 dig -c 076b8cad77aa9` found the original submission at `https://lo
re.kernel.org/all/20260421202406.717885-1-daniel@iogearbox.net/`
- Subject: **[PATCH net v3]** — "net" tree tag signals this is a bug fix
targeting the current release cycle (not "net-next"), which is where
stable-candidate fixes go
- `b4 dig -a`: the v3 that was applied is the latest revision; changelog
in the patch shows v1->v2 (use abs(), remove unlikely), v2->v3 (hard
code limit of 8 vs max_dst_opts_cnt, per Ido)
- Record: Three-revision evolution; reviewers addressed; applied version
is final
**Step 4.2 - Reviewers (b4 dig -w):**
- To: kuba@kernel.org (Jakub Kicinski — netdev maintainer)
- Cc: edumazet@google.com (Eric Dumazet — networking maintainer),
dsahern@kernel.org (David Ahern — ipv6 maintainer),
tom@herbertland.com (Tom Herbert — author of the related 2017 fix),
willemdebruijn.kernel@gmail.com, idosch@nvidia.com,
justin.iurman@gmail.com, pabeni@redhat.com (Paolo Abeni — networking
maintainer), netdev@vger.kernel.org
- Record: All major networking maintainers included. Reviewed by Ido
Schimmel and Justin Iurman (IPv6 extension header reviewer)
**Step 4.3 - Bug Report:**
- No Reported-by/Link: tag — the DoS was likely identified by the author
through code review (he explicitly analyzed the disparity with the
already-patched `ip6_parse_tlv()`)
- Record: Proactive DoS discovery rather than user-reported
**Step 4.4 - Related Patches:**
- Single patch, not a series
- Record: Standalone
**Step 4.5 - Stable Discussion:**
- In the lore mbox: Ido Schimmel said "Given that you are targeting net
and that the issue was always present, I would use: Fixes:
1da177e4c3f4 ('Linux-2.6.12-rc2')"
- This strongly implies the fix is intended for stable (Fixes: tag is
the trigger for stable-autoselect)
- Record: Reviewer explicitly suggested adding a Fixes: tag pointing to
kernel epoch — a clear stable-backport signal
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1 - Key Functions:** `ip6_tnl_parse_tlv_enc_lim()` — the only
function modified.
**Step 5.2 - Callers (via `git grep`):**
- `net/ipv6/ip6_tunnel.c`:
- `ip6_tnl_err()` — ICMPv6 error handler for IPv6-over-IPv6 tunnels
- `__ip6_tnl_xmit()` — the transmit path (when protocol ==
IPPROTO_IPV6)
- `net/ipv6/ip6_gre.c`:
- `ip6gre_err()` — ICMPv6 error handler for GRE-over-IPv6
- `prepare_ip6gre_xmit_ipv6()` — GRE transmit path
- Record: Called from both transmit path and ICMPv6 error handling for
ip6 and ip6gre tunnels — network-reachable data paths on any system
using IPv6 tunnels
**Step 5.3 - Callees:** Reads `skb->data`, uses `pskb_may_pull`. No
external state changes inside the scanner.
**Step 5.4 - Call Chain / Reachability:**
- `__ip6_tnl_xmit()` is part of `ip6_tnl_start_xmit` / `ip6_tnl_rcv_ctl`
infrastructure — runs on every packet sent over an IPv6 tunnel when
the inner packet has Destination Options
- `ip6_tnl_err()` is invoked from `ip6_tnl_err_proto`, called by icmpv6
when an IPv6 tunnel packet triggers an error
- An attacker over the network can craft packets to exploit this as long
as the target has an IPv6 tunnel configured (ip6tnl, ip6gre modules)
- Record: Data path function, reachable from remote attacker when IPv6
tunnel is configured
**Step 5.5 - Similar Patterns:**
- The generic `ip6_parse_tlv()` in `net/ipv6/exthdrs.c` already has this
protection via `max_hbh_opts_cnt/max_dst_opts_cnt` (commit
47d3d7ac656a, 2017)
- This commit closes the last remaining scanner that didn't have such a
cap
- Record: This is the final instance; other instances already protected
## PHASE 6: CROSS-REFERENCING STABLE TREES
**Step 6.1 - Buggy code in stable trees?**
- The loop structure is in the codebase since `1da177e4c3f4`
(2.6.12-rc2)
- Present in 5.4, 5.10, 5.15, 6.1, 6.6, 6.12 and every other supported
stable tree
- Record: All supported stable trees contain the vulnerable code
**Step 6.2 - Backport Complications:**
- The function is modified by `d375b98e024898` (Jan 2024) — this is in
6.7+; older stable trees (5.4, 5.10, 5.15, 6.1) may have a slightly
different surrounding context (no `nexthdr ==
NEXTHDR_FRAGMENT`/`NEXTHDR_AUTH` branching exactly as today)
- However, the key hunk — the `if (nexthdr == NEXTHDR_DEST) { ...
while(1) { ... }}` block — is structurally unchanged since 2005
- The patch adds a new local variable and a new `if` inside the while
loop; this should apply cleanly or with trivial offset fuzzing
- Record: Expected to apply cleanly to all active stable trees; at worst
a trivial context adjustment
**Step 6.3 - Related fixes already in stable?**
- `47d3d7ac656a` is in stable trees (it was the original DoS hardening,
merged 2017)
- No previous fix for this specific hand-rolled scanner exists
- Record: No overlap; this closes a gap left by the 2017 fix
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1 - Subsystem:** `net/ipv6/` — core IPv6 networking. Affects
users of IPv6 tunnels (ip6tnl, ip6gre). IMPORTANT criticality.
**Step 7.2 - Activity:** Very active subsystem, but the specific scanner
has been stable for 20+ years. Record: Mature code, long-lived bug.
## PHASE 8: IMPACT AND RISK
**Step 8.1 - Affected Users:** All users running IPv6 tunnel drivers
(ip6tnl, ip6gre modules loaded) — common on IPv6 dual-stack routers,
tunnel endpoints, mobile backhauls, cloud overlay networks.
**Step 8.2 - Trigger Conditions:**
- Attacker sends IPv6 packet with Destination Options header containing
2046 Pad1 entries
- Per extension header, ~2000 CPU iterations in the scanner
- Can be triggered remotely without authentication — any reachable IPv6
tunnel endpoint
- Record: Unprivileged remote attacker can trigger; realistic DoS
**Step 8.3 - Failure Mode Severity:**
- CPU exhaustion in softirq context — affects packet processing
throughput
- With pipelined attack traffic, can starve other network processing
- Not a crash but a performance DoS — **MEDIUM-HIGH** severity
- Record: Remote DoS / CPU exhaustion, medium-high severity
**Step 8.4 - Risk-Benefit:**
- Benefit: Closes a 20-year-old remote DoS vector on IPv6 tunnel
endpoints; completes the hardening started by the 2017 fix
- Risk: Very low — 6-line cap at value 8, legitimate traffic never
approaches this limit (encap limit is typically the first TLV)
- Record: Strongly favorable benefit/risk ratio
## PHASE 9: SYNTHESIS
**Step 9.1 - Evidence:**
- FOR backport:
- Closes a known class of remote DoS (same class as 47d3d7ac656a,
which is in stable)
- Bug present since 2.6.12-rc2 (2005) — affects every supported stable
tree
- 6-line surgical fix, no new APIs, no functional change for
legitimate traffic
- Reviewed by two independent reviewers (Ido Schimmel, Justin Iurman),
applied by netdev maintainer to the `net` tree
- Reviewer explicitly suggested Fixes: 1da177e4c3f4 (signaling stable
relevance)
- Reachable from remote unauthenticated attacker on any IPv6 tunnel
endpoint
- Author (Borkmann) is a senior networking developer, patch went
through 3 review iterations
- AGAINST backport:
- No Fixes: tag in the applied commit (reviewer suggested one but it
was not added)
- No Cc: stable tag — but absence is expected per the prompt
- No user-filed bug report / CVE — the DoS is based on code analysis
of an analogous, already-fixed vector
**Step 9.2 - Stable Rules Checklist:**
1. Obviously correct and tested? YES — trivial counter, 2 Reviewed-by,
merged to net
2. Fixes a real bug? YES — remote DoS via crafted IPv6 Destination
Options
3. Important issue? YES — remote CPU exhaustion in softirq path
(security-relevant)
4. Small and contained? YES — 6 lines in one function, one file
5. No new features/APIs? YES — purely defensive counter
6. Applies to stable? YES (likely clean; minor context fuzz possible on
very old trees)
**Step 9.3 - Exception Category:** Not applicable by name, but fits the
spirit of "security hardening for known DoS class" — a strong stable
candidate on its own merits.
**Step 9.4 - Decision:** YES.
# Verification
- [Phase 1] Parsed tags: Reviewed-by: Ido Schimmel, Reviewed-by: Justin
Iurman, Signed-off-by: Daniel Borkmann, Signed-off-by: Jakub Kicinski.
No Fixes:, no Cc: stable, no Reported-by, no Link: — verified from
commit message and `git show 076b8cad77aa9 --format=fuller`
- [Phase 2] Diff analysis: `git diff 076b8cad77aa9^ 076b8cad77aa9` —
confirmed +6 lines (1 macro, 1 local var, 1 conditional break) in
`net/ipv6/ip6_tunnel.c`
- [Phase 3] `git blame -L 430,456 net/ipv6/ip6_tunnel.c`: core loop
attributed to `1da177e4c3f4` (2.6.12-rc2, 2005); surrounding context
modified by `d375b98e024898` (2024)
- [Phase 3] `git show 47d3d7ac656a`: confirmed the referenced prior
commit added `max_hbh/dst_opts_cnt/len` to `ip6_parse_tlv()` for an
identical DoS class in 2017
- [Phase 3] `git log --oneline --author="Daniel Borkmann" -- net/ipv6/`:
confirmed author has prior ipv6 work (e.g., `47e27d5e92c46`,
`e41b0bedba029`, `a824d0b83109e`)
- [Phase 4] `b4 dig -c 076b8cad77aa9`: found lore thread `https://lore.k
ernel.org/all/20260421202406.717885-1-daniel@iogearbox.net/`
- [Phase 4] `b4 dig -a`: confirmed v3 is the applied/final revision;
changelog shows v1->v2 dropping unlikely and using abs(), v2->v3 hard-
coding 8 instead of max_dst_opts_cnt per Ido's suggestion
- [Phase 4] `b4 dig -w`: confirmed Kicinski, Dumazet, Ahern, Herbert,
Abeni and netdev were recipients — proper maintainer review
- [Phase 4] mbox content (`/tmp/tlv_thread.mbox`) lines 340-347: Ido
Schimmel wrote "Given that you are targeting net and that the issue
was always present, I would use: Fixes: 1da177e4c3f4
('Linux-2.6.12-rc2')" — confirms bug is as old as git history and
stable-worthy
- [Phase 4] mbox lines 53-80: patchwork bot confirms patch was applied
to netdev/net.git (main) by Kicinski
- [Phase 5] `git grep "ip6_tnl_parse_tlv_enc_lim"`: confirmed 4 call
sites (ip6_tnl_err, __ip6_tnl_xmit, ip6gre_err,
prepare_ip6gre_xmit_ipv6) — all in data/error paths
- [Phase 6] Code since 2.6.12-rc2 → present in all active stable trees
(5.4, 5.10, 5.15, 6.1, 6.6, 6.12)
- [Phase 8] Failure mode: remote-triggerable CPU exhaustion (~2000
scanner iterations per extension header) — severity medium-high (DoS),
quoted directly from the commit message's documented attack
- UNVERIFIED: Exact patch-apply cleanliness on pre-6.7 stable branches
(the function body was restructured by d375b98e024898 in early 2024).
The hunk target is the inner `if (nexthdr == NEXTHDR_DEST)` block
which has been structurally unchanged since 2005, so clean apply is
expected, but I did not run `git apply` against the individual stable
branches.
- UNVERIFIED: Whether a CVE has been assigned for this specific scanner
(no public CVE reference in the commit message or lore thread).
The fix is small, surgical, fixes a real remote DoS, is well-reviewed,
affects a long-present bug in all stable trees, and was applied to the
`net` (bug-fix) tree by the netdev maintainer.
**YES**
net/ipv6/ip6_tunnel.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 0b53488a92290..b9d41b5d1853b 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -62,6 +62,8 @@ MODULE_LICENSE("GPL");
MODULE_ALIAS_RTNL_LINK("ip6tnl");
MODULE_ALIAS_NETDEV("ip6tnl0");
+#define IP6_TUNNEL_MAX_DEST_TLVS 8
+
#define IP6_TUNNEL_HASH_SIZE_SHIFT 5
#define IP6_TUNNEL_HASH_SIZE (1 << IP6_TUNNEL_HASH_SIZE_SHIFT)
@@ -428,11 +430,15 @@ __u16 ip6_tnl_parse_tlv_enc_lim(struct sk_buff *skb, __u8 *raw)
break;
}
if (nexthdr == NEXTHDR_DEST) {
+ int tlv_cnt = 0;
u16 i = 2;
while (1) {
struct ipv6_tlv_tnl_enc_lim *tel;
+ if (unlikely(tlv_cnt++ >= IP6_TUNNEL_MAX_DEST_TLVS))
+ break;
+
/* No more room for encapsulation limit */
if (i + sizeof(*tel) > optlen)
break;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2 7/9] wifi: rtw89: switch to using FIELD_GET_SIGNED()
From: David Laight @ 2026-04-28 10:43 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Yury Norov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H. Peter Anvin, Andy Lutomirski, Peter Zijlstra,
Jonathan Cameron, David Lechner, Johannes Berg, Nuno Sá,
Andy Shevchenko, Ping-Ke Shih, Richard Cochran, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexandre Belloni, Yury Norov, Rasmus Villemoes, Hans de Goede,
Linus Walleij, Sakari Ailus, Salah Triki, Achim Gratz,
Ben Collins, x86, linux-kernel, linux-iio, linux-wireless, netdev,
linux-rtc
In-Reply-To: <afBdXj_9r25Ssnz6@ashevche-desk.local>
On Tue, 28 Apr 2026 10:10:22 +0300
Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
> On Mon, Apr 27, 2026 at 05:41:24PM -0400, Yury Norov wrote:
> > Switch from sign_extend32(FIELD_GET()) to the dedicated
> > FIELD_GET_SIGNED() and don't calculate the fields length explicitly.
>
> ...
>
> > for (i = 0; i < ADDC_T_AVG; i++) {
> > tmp = rtw89_phy_read32_mask(rtwdev, R_DBG32_D, MASKDWORD);
> > - dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > - dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> > + dc_re += FIELD_GET_SIGNED(0xfff000, tmp);
> > + dc_im += FIELD_GET_SIGNED(0xfff, tmp);
>
> In the same driver the GENMASK() is being used, why not doing it here while at it?
To me those bit masks look more readable than the GENMASK() calls would be.
David
>
> > }
>
> ...
>
> > for (i = 0; i < ADDC_T_AVG; i++) {
> > tmp = rtw89_phy_read32_mask(rtwdev, R_DBG32_D, MASKDWORD);
> > - dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > - dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> > + dc_re += FIELD_GET_SIGNED(0xfff000, tmp);
> > + dc_im += FIELD_GET_SIGNED(0xfff, tmp);
> > }
>
> Ditto, and it even looks like the same piece repeating twice in different
> compilation units of the same driver...
>
^ 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