* [PATCH net-next v3] selftests/net: Skip srv6_end_dt46_l3vpn_test if iproute2 too old
From: Alessio Faina @ 2026-07-15 12:28 UTC (permalink / raw)
To: netdev, linux-kselftest, Andrea Mayer
Cc: Po-Hsu Lin, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan
In case iproute2 is older than version 5.14.0, released ~Sept 1, 2021,
the End.DT46 support is not available and the host_vpn_tests test contained
in the srv6_end_dt46_l3vpn_test.sh file is failing in some kernel backports.
This is the result of those tests:
################################################################################
TEST SECTION: SRv6 VPN connectivity test among hosts in the same tenant
################################################################################
TEST: IPv6 Hosts connectivity: hs-t100-1 -> hs-t100-2 (tenant 100) [ FAIL ]
TEST: IPv4 Hosts connectivity: hs-t100-1 -> hs-t100-2 (tenant 100) [ FAIL ]
TEST: IPv6 Hosts connectivity: hs-t100-2 -> hs-t100-1 (tenant 100) [ FAIL ]
TEST: IPv4 Hosts connectivity: hs-t100-2 -> hs-t100-1 (tenant 100) [ FAIL ]
TEST: IPv6 Hosts connectivity: hs-t200-3 -> hs-t200-4 (tenant 200) [ FAIL ]
TEST: IPv4 Hosts connectivity: hs-t200-3 -> hs-t200-4 (tenant 200) [ FAIL ]
TEST: IPv6 Hosts connectivity: hs-t200-4 -> hs-t200-3 (tenant 200) [ FAIL ]
TEST: IPv4 Hosts connectivity: hs-t200-4 -> hs-t200-3 (tenant 200) [ FAIL ]
To amend this, check the current running iproute2 supports the required
feature and, if not, just skip the entire test to avoid a failure.
Signed-off-by: Alessio Faina <alessio.faina@canonical.com>
---
v3:
- fix indentation in test_iproute2_supp_or_ksft_skip()
- fix subject to reflect full test suite skip
- https://lore.kernel.org/netdev/20260713095750.2671173-1-alessio.faina@canonical.com/
v2:
- skip entire test suite if iproute2 is too old
v1: https://lore.kernel.org/netdev/20260708152745.2430714-1-alessio.faina@canonical.com/
.../testing/selftests/net/srv6_end_dt46_l3vpn_test.sh | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh b/tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh
index a5e959a080bb..50e37d3217ea 100755
--- a/tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh
+++ b/tools/testing/selftests/net/srv6_end_dt46_l3vpn_test.sh
@@ -536,6 +536,14 @@ host_vpn_isolation_tests()
done
}
+test_iproute2_supp_or_ksft_skip()
+{
+ if ! ip route add help 2>&1 | grep -qo "End.DT46"; then
+ echo "SKIP: Missing SRv6 End.DT46 support in iproute2"
+ exit "${ksft_skip}"
+ fi
+}
+
if [ "$(id -u)" -ne 0 ];then
echo "SKIP: Need root privileges"
exit $ksft_skip
@@ -546,6 +554,8 @@ if [ ! -x "$(command -v ip)" ]; then
exit $ksft_skip
fi
+test_iproute2_supp_or_ksft_skip
+
modprobe vrf &>/dev/null
if [ ! -e /proc/sys/net/vrf/strict_mode ]; then
echo "SKIP: vrf sysctl does not exist"
--
2.43.0
^ permalink raw reply related
* Re: [PATCH iwl-next v3] ixgbe: E610: force phy link to get down when interface is down
From: Simon Horman @ 2026-07-15 12:29 UTC (permalink / raw)
To: Jedrzej Jagielski
Cc: intel-wired-lan, anthony.l.nguyen, netdev, pmenzel,
Aleksandr Loktionov
In-Reply-To: <20260708100609.331976-1-jedrzej.jagielski@intel.com>
On Wed, Jul 08, 2026 at 12:06:09PM +0200, Jedrzej Jagielski wrote:
> For the E610 family, similarly to the E8xx adapters, the default behavior
> is for the PHY link to remain up even when the corresponding OS interface
> is down.
>
> Add function setting down the PHY config IXGBE_ACI_PHY_ENA_LINK bit
> what leads to disabling PHY link.
>
> Now ixgbe_close() needs to share some of the ixgbe_watchdog_link_is_down
> code so move the common part into the separate function.
>
> Align functionality with the implementation of the ice driver.
>
> Let user to configure link-down-on-close enablement through ethtool.
>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
> ---
> v2: apply Paul's notes
> v3: use e_err
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* [PATCH net v3 0/2] net/stmmac: Secure against failures of DMA memory allocation
From: Jakub Raczynski @ 2026-07-15 12:36 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
linux-kernel, linux-arm-kernel, Jakub Raczynski
In-Reply-To: <CGME20260715123609eucas1p276498c4701060ffbb6789cb096696a31@eucas1p2.samsung.com>
This series fixing two issues related to fails of
__alloc_dma_rx_desc_resources(). Original issue from 1st patch is related to
page_pool that has happened in testing env, while second was requested by
Sashiko to have similar change for DMA allocation.
To have complete fix for all failures of __alloc_dma_rx_desc_resources(),
merge two fixes into series.
---
Changes in v3:
- Added null assignment to page pointers (suggested by sashiko)
- Convert IS_ERR_OR_NULL check to just NULL check
Changes in v2:
- Added reviewed by Maxime to first patch
- Dropped null check as page_pool_destroy() does provide that
- Modified comment to reflect that
Link to v2:
https://lore.kernel.org/all/20260707174115.1264466-1-j.raczynski@samsung.com/
Link to v1:
https://lore.kernel.org/netdev/20260630100953.747868-1-j.raczynski@samsung.com/
Jakub Raczynski (2):
net/stmmac: Set Rx queue page_pool to NULL when freeing DMA resources
net/stmmac: Prevent dma queue NULL free on allocation failure
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 32 ++++++++++++-------
1 file changed, 21 insertions(+), 11 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH net v3 2/2] net/stmmac: Prevent dma queue NULL free on allocation failure
From: Jakub Raczynski @ 2026-07-15 12:36 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
linux-kernel, linux-arm-kernel, Jakub Raczynski
In-Reply-To: <20260715123602.51950-1-j.raczynski@samsung.com>
During allocation of RX/TX descriptor resources and its DMA,
there is verification of failed dma_alloc_coherent() due to lack of memory.
In case of that failure, all allocated resources are freed instantly after,
but there are no checks for dma_free_coherent() whether previous step has
failed.
This will generally result in panic due to freeing NULL address.
Fix it by adding NULL verification of memory that is to be freed.
Also assign NULL to page pointers to avoid double free scenario.
Fixes: e73b19baa3b1c ("net: stmmac: simplify DMA descriptor allocation/init/freeing")
Reported-by: Sashiko AI <sashiko-bot@kernel.org>
Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
---
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 28 +++++++++++++------
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3098971e0b66..77604d6ab466 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2146,7 +2146,6 @@ static void __free_dma_rx_desc_resources(struct stmmac_priv *priv,
u32 queue)
{
struct stmmac_rx_queue *rx_q = &dma_conf->rx_queue[queue];
- size_t size;
void *addr;
/* Release the DMA RX socket buffers */
@@ -2158,15 +2157,21 @@ static void __free_dma_rx_desc_resources(struct stmmac_priv *priv,
rx_q->buf_alloc_num = 0;
rx_q->xsk_pool = NULL;
- /* Free DMA regions of consistent memory previously allocated */
- if (priv->extend_desc)
+ if (priv->extend_desc) {
addr = rx_q->dma_erx;
- else
+ rx_q->dma_erx = NULL;
+ } else {
addr = rx_q->dma_rx;
+ rx_q->dma_rx = NULL;
+ }
- size = stmmac_get_rx_desc_size(priv) * dma_conf->dma_rx_size;
+ /* Free DMA regions of consistent memory if previously allocated */
+ if (addr) {
+ size_t size;
+ size = stmmac_get_rx_desc_size(priv) * dma_conf->dma_rx_size;
- dma_free_coherent(priv->device, size, addr, rx_q->dma_rx_phy);
+ dma_free_coherent(priv->device, size, addr, rx_q->dma_rx_phy);
+ }
if (xdp_rxq_info_is_reg(&rx_q->xdp_rxq))
xdp_rxq_info_unreg(&rx_q->xdp_rxq);
@@ -2198,7 +2203,6 @@ static void __free_dma_tx_desc_resources(struct stmmac_priv *priv,
u32 queue)
{
struct stmmac_tx_queue *tx_q = &dma_conf->tx_queue[queue];
- size_t size;
void *addr;
/* Release the DMA TX socket buffers */
@@ -2206,15 +2210,21 @@ static void __free_dma_tx_desc_resources(struct stmmac_priv *priv,
if (priv->extend_desc) {
addr = tx_q->dma_etx;
+ tx_q->dma_etx = NULL;
} else if (tx_q->tbs & STMMAC_TBS_AVAIL) {
addr = tx_q->dma_entx;
+ tx_q->dma_entx = NULL;
} else {
addr = tx_q->dma_tx;
+ tx_q->dma_tx = NULL;
}
- size = stmmac_get_tx_desc_size(priv, tx_q) * dma_conf->dma_tx_size;
+ if (addr) {
+ size_t size;
+ size = stmmac_get_tx_desc_size(priv, tx_q) * dma_conf->dma_tx_size;
- dma_free_coherent(priv->device, size, addr, tx_q->dma_tx_phy);
+ dma_free_coherent(priv->device, size, addr, tx_q->dma_tx_phy);
+ }
kfree(tx_q->tx_skbuff_dma);
kfree(tx_q->tx_skbuff);
--
2.34.1
^ permalink raw reply related
* [PATCH net v3 1/2] net/stmmac: Set Rx queue page_pool to NULL when freeing DMA resources
From: Jakub Raczynski @ 2026-07-15 12:36 UTC (permalink / raw)
To: netdev
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
linux-kernel, linux-arm-kernel, Jakub Raczynski
In-Reply-To: <20260715123602.51950-1-j.raczynski@samsung.com>
When freeing RX descriptor resources, there is standard clearing of
descriptor page_pool via page_pool_destroy() which does destroy
page but does not set its pointer to NULL, which must be done by driver
calling this function.
It is not done in __free_dma_rx_desc_resources() when stopping interface,
which is generally not an issue, because __alloc_dma_rx_desc_resources() does
setup this regardless of previous state.
But above is true assuming reinitialization is successful.
In case of failure of page_pool_create() in __alloc_dma_rx_desc_resources(),
all non-NULL pages will be freed, including those already cleared.
So there is possible kernel panic due to wrong paging request at address.
Fix this by assigning NULL to page_pool pointer on free.
Also remove NULL check as page_pool_destroy() does check for NULL param.
Fixes: da5ec7f22a0f1 ("net: stmmac: refactor stmmac_init_rx_buffers for stmmac_reinit_rx_buffers")
Signed-off-by: Yashwant Varur <yashwant.v@samsung.com>
Signed-off-by: Jakub Raczynski <j.raczynski@samsung.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 2a0d7eff88d3..3098971e0b66 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -2172,8 +2172,8 @@ static void __free_dma_rx_desc_resources(struct stmmac_priv *priv,
xdp_rxq_info_unreg(&rx_q->xdp_rxq);
kfree(rx_q->buf_pool);
- if (rx_q->page_pool)
- page_pool_destroy(rx_q->page_pool);
+ page_pool_destroy(rx_q->page_pool);
+ rx_q->page_pool = NULL;
}
static void free_dma_rx_desc_resources(struct stmmac_priv *priv,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net 1/2] vxlan: require CAP_NET_ADMIN in the device netns for changelink
From: Fernando Fernandez Mancera @ 2026-07-15 12:36 UTC (permalink / raw)
To: Doruk Tan Ozturk
Cc: davem, edumazet, kuba, pabeni, andrew+netdev, sd, linville,
mschiffer, maoyixie.tju, netdev, linux-kernel, stable
In-Reply-To: <20260715055648.33060-2-doruk@0sec.ai>
On Wed, 15 Jul 2026 07:56:47 +0200, Doruk Tan Ozturk <doruk@0sec.ai> wrote:
> A tunnel changelink() operates on at most two netns, dev_net(dev) and
> the sticky underlay netns vxlan->net. They differ once the device is
> created in or moved to a netns other than the one the request runs in.
> The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev),
> so a caller privileged there but not in vxlan->net can rewrite a vxlan
> device whose underlay lives in vxlan->net.
>
> vxlan_changelink() validates and applies the new configuration against
> vxlan->net (vxlan_config_validate(vxlan->net, ...)) and can reopen the
> underlay socket in that netns, so the same reasoning as the tunnel
> changelink series applies here.
>
> Gate vxlan_changelink() with rtnl_dev_link_net_capable(), at the top of
> the op before any attribute is parsed, matching ipgre_changelink() and
> the rest of the "require CAP_NET_ADMIN in the device netns for
> changelink" series.
>
> Found by 0sec automated security-research tooling (https://0sec.ai).
>
> Fixes: 889ce937c98f ("vxlan: correctly set vxlan->net when creating the device in a netns")
> Cc: stable@vger.kernel.org
> Assisted-by: 0sec:multi-model
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
>
The patch makes sense to me but I believe the right fixes tag would be:
Fixes: 8bcdc4f3a20b ("vxlan: add changelink support")
Thanks,
Fernando.
^ permalink raw reply
* Re: [PATCH net 2/2] geneve: require CAP_NET_ADMIN in the device netns for changelink
From: Fernando Fernandez Mancera @ 2026-07-15 12:36 UTC (permalink / raw)
To: Doruk Tan Ozturk
Cc: davem, edumazet, kuba, pabeni, andrew+netdev, sd, linville,
mschiffer, maoyixie.tju, netdev, linux-kernel, stable
In-Reply-To: <20260715055648.33060-3-doruk@0sec.ai>
On Wed, 15 Jul 2026 07:56:48 +0200, Doruk Tan Ozturk <doruk@0sec.ai> wrote:
> A tunnel changelink() operates on at most two netns, dev_net(dev) and
> the sticky underlay netns geneve->net. They differ once the device is
> created in or moved to a netns other than the one the request runs in.
> The rtnl changelink path checks CAP_NET_ADMIN only against dev_net(dev),
> so a caller privileged there but not in geneve->net can rewrite a geneve
> device whose underlay lives in geneve->net.
>
> geneve_changelink() applies the new configuration against geneve->net:
> geneve_link_config() and the geneve_quiesce()/geneve_unquiesce() pair
> reopen the underlay sockets in that netns (geneve_sock_add() uses
> geneve->net), so the same reasoning as the tunnel changelink series
> applies here.
>
> Gate geneve_changelink() with rtnl_dev_link_net_capable(), at the top of
> the op before any attribute is parsed, matching ipgre_changelink() and
> the rest of the "require CAP_NET_ADMIN in the device netns for
> changelink" series.
>
> Found by 0sec automated security-research tooling (https://0sec.ai).
>
> Fixes: 2d07dc79fe04 ("geneve: add initial netdev driver for GENEVE tunnels")
> Cc: stable@vger.kernel.org
> Assisted-by: 0sec:multi-model
> Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
>
The patch makes sense to me but as with the previous one I believe the
fixes tag is wrong. It should be:
Fixes: 5b861f6baa3a ("geneve: add rtnl changelink support")
Thanks,
Fernando.
^ permalink raw reply
* Re: [PATCH net 1/2] vxlan: require CAP_NET_ADMIN in the device netns for changelink
From: Doruk Tan Ozturk @ 2026-07-15 12:46 UTC (permalink / raw)
To: fmancera
Cc: davem, edumazet, kuba, pabeni, andrew+netdev, sd, linville,
mschiffer, maoyixie.tju, netdev, linux-kernel
> It should be:
> Fixes: 8bcdc4f3a20b ("vxlan: add changelink support")
Thanks, agreed. I'll fix both tags in v2 (geneve too, 5b861f6baa3a).
Doruk
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: ti: icssm-prueth: Support duplicate HW offload feature for HSR and PRP
From: Parvathi Pudi @ 2026-07-15 12:53 UTC (permalink / raw)
To: Paolo Abeni
Cc: parvathi, andrew+netdev, davem, edumazet, kuba, danishanwar,
rogerq, pmohan, afd, basharath, arnd, linux-kernel, netdev,
linux-arm-kernel, pratheesh, j-rameshbabu, Vignesh Raghavendra,
praneeth, srk, rogerq, m-malladi, krishna, mohan
In-Reply-To: <20260706091338.134754-1-pabeni@redhat.com>
Hi,
> From: AI Reviewer <ai@example.com>
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev/
> ---
> net: ti: icssm-prueth: Support duplicate HW offload feature for HSR and PRP
>
> This commit introduces hardware duplicate offload for HSR and PRP modes. It
> implements a common shared queue between the two ports, writing frames once
> to OCMC RAM and relying on the firmware to replicate the transmission.
>
>> diff --git a/drivers/net/ethernet/ti/icssm/icssm_prueth.c
>> b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
>> index 2ab78a98f8568..cbe666a212c3b 100644
>> --- a/drivers/net/ethernet/ti/icssm/icssm_prueth.c
>> +++ b/drivers/net/ethernet/ti/icssm/icssm_prueth.c
>> @@ -97,6 +125,17 @@ static void icssm_prueth_write_reg(struct prueth *prueth,
>> static enum pruss_mem pruss_mem_ids[] = { PRUSS_MEM_DRAM0, PRUSS_MEM_DRAM1,
>> PRUSS_MEM_SHRD_RAM2 };
>>
>> +struct prp_txopt_rct {
>> + __be16 sequence_nr;
>> + __be16 lan_id_and_lsdu_size;
>> + __be16 prp_suffix;
>> +};
>
> [Severity: High]
> Does this structure definition need the __packed attribute?
>
> This struct consists of three 16-bit fields but lacks the __packed attribute,
> so it inherits a 2-byte alignment requirement. Later in
> icssm_prueth_tx_enqueue, a pointer to this structure is derived directly
> from skb_tail_pointer.
>
> If an ethernet frame payload has an odd byte length, wouldn't casting and
> dereferencing this pointer cause an unaligned 16-bit memory access, resulting
> in hardware traps or panics on architectures that do not support it?
The __packed attribute is not needed as this will be handled by C packing rules. See feedback
from an earlier series: https://lore.kernel.org/all/20250708175301.599c82b8@kernel.org/
>
> [ ... ]
>> @@ -549,15 +588,24 @@ static int icssm_prueth_tx_enqueue(struct prueth_emac
>> *emac,
> [ ... ]
>> + other_emac = emac->prueth->emac[(emac->port_id == PRUETH_PORT_MII0) ?
>> + PRUETH_PORT_MII1 - 1 : PRUETH_PORT_MII0 - 1];
>> +
>> + if (prueth_is_lre(prueth) && (emac->link || other_emac->link))
>> + link_up = true;
>
> [Severity: High]
> Could this logical OR cause the shared transmission queue to stall completely
> if only one of the slave links goes down?
>
> If one port loses its link, its emac->link is 0, but the other active port
> will still evaluate link_up as true. The active port would continue sending
> duplicate frames to the shared queue.
No. emac->link only reflects the PHY carrier state and does not indicate whether the
firmware servicing the shared queue is running. When one PHY link goes down, the
corresponding firmware continues to consume descriptors and simply discards the frames.
Therefore, using OR here does not cause the shared transmission queue to stall.
>
> [ ... ]
>> @@ -605,6 +659,29 @@ static int icssm_prueth_tx_enqueue(struct prueth_emac
>> *emac,
> [ ... ]
>> + if (free_blocks_other_port < free_blocks)
>> + free_blocks = free_blocks_other_port;
>> + }
>
> [Severity: High]
> Following up on the link_up logic above, since the available queue space is
> bounded by the slowest reader here, wouldn't the inactive port's read pointer
> remain frozen?
>
> This appears to exhaust the free_blocks pool, causing the active port to
> eventually spin and return -ENOBUFS permanently, defeating the redundancy.
The inactive port's rd_ptr does not remain frozen just because its PHY link is down.
The firmware continues advancing the read pointer while dropping the frames, so free_blocks
is not exhausted in this scenario. We confirmed this behavior by testing.
Unplugging one link does not stall transmission or lead to a permanent -ENOBUFS. A stall
occurs only if the firmware itself stops running, which is a different failure mode.
>
> [ ... ]
>> + } else {
>> + /* Read PRP RCT to extract sequence number and LAN ID */
>> + struct prp_txopt_rct *rct =
>> + (struct prp_txopt_rct *)(skb_tail_pointer(skb) -
>> + ICSSM_LRE_TAG_SIZE);
>> +
>> + if (rct->prp_suffix == htons(ETH_P_PRP)) {
>
> [Severity: High]
> Is it safe to directly dereference rct->prp_suffix here?
>
> As mentioned above regarding the struct definition, this might lead to an
> unaligned memory access on certain architectures. Perhaps using the
> get_unaligned_be16 helper would be safer here, or adding the __packed
> attribute to the structure definition.
The __packed attribute is not needed as this will be handled by C packing rules. See feedback
from an earlier series: https://lore.kernel.org/all/20250708175301.599c82b8@kernel.org/
>
> [ ... ]
>> @@ -1341,18 +1516,30 @@ static enum netdev_tx icssm_emac_ndo_start_xmit(struct
>> sk_buff *skb,
> [ ... ]
>> + raw_spin_lock(lock_queue);
>> + ret = icssm_prueth_tx_enqueue(emac, skb, qid);
>> + raw_spin_unlock(lock_queue);
>
> [Severity: High]
> Does this need to use the irqsave variant to protect against cross-device
> deadlocks with netpoll?
>
> The lre_host_queue_lock is shared between the two ports. If a hardirq
> preempts a CPU while it holds this lock during a transmission, and the
> interrupt handler invokes a printk that triggers netconsole over the second
> interface, netpoll might bypass the netif_tx_lock.
>
> When the second interface calls into ndo_start_xmit, it would attempt to
> acquire the exact same lre_host_queue_lock, causing it to spin forever on
> the same CPU.
> --
We will address this in the next version
Thanks and Regards,
Parvathi.
^ permalink raw reply
* [RFC PATCH net-next 0/6] net: add GeoNetworking protocol
From: Simon Dietz @ 2026-07-15 12:45 UTC (permalink / raw)
To: netdev; +Cc: edumazet, davem, kuniyu, simon.dietz, dietz23838
Implement the GeoNetworking / ETSI ITS-G5 ('net/gn') protocol which
is based on 802.11p wifi and used for vehicle2x applications. It is
standardized by the ETSI and used by some car manufacturers
(especially in europe). It enables ad-hoc, multi-hop geographical
communication and routing among vehicles (and road- or railside
infrastructure).
Most work of this implementation has been done by the bachelor
project 2018/2019 of the operating systems and middleware group of
the Hasso Plattner Institute, University of Potsdam, which the author
was part of.
The project was supervised by:
- Jossekin Beilharz
- Lukas Pirl
- Prof. Andreas Polze
The code is published under the GPL v2 at this location:
https://gitlab.com/hpi-potsdam/osm/g5-on-linux/linux-geonetworking/
The original code base was based on linux version 5.1. The first patch
includes the original codebase rebased to the current net-next code
base so that it compiles under current net-next (as required by
submitting patch guidelines in order not to break git bisect). I've
backed up a not squashed version of this patch series if a more
compartmentalized history would be desired.
The subsequent patches address bounds, null, empty checks, memory
safety, locking, code style and ETSI standard conformity improvements.
This patch series is not merge-ready, yet. E.g. network namespaces are
not supported at all, documentation is missing, ...
Purpose of this RFC is to determine if GeoNetworking support in the
linux kernel is desirable and if so what steps would have to be done
next. There is ongoing research on the topic vehicle2x, which may
benefit from GeoNetworking support in the Linux kernel.
Greetings,
Simon
Simon Dietz (6):
net: add GeoNetworking protocol
net: fix GeoNetworking
net: further fix GeoNetworking
net: even further fix GeoNetworking
net: add ppc64 support for GeoNetworking
net: apply RCS to GeoNetworking
include/linux/gn.h | 349 +++++
include/linux/gn_routing.h | 68 +
include/linux/socket.h | 6 +-
include/uapi/linux/gn.h | 84 ++
include/uapi/linux/if_ether.h | 1 +
net/Kconfig | 2 +
net/Makefile | 1 +
net/gn/Kconfig | 4 +
net/gn/Makefile | 8 +
net/gn/gn_proc.c | 86 ++
net/gn/gn_prot.c | 2012 +++++++++++++++++++++++++++
net/gn/gn_routing.c | 632 +++++++++
net/gn/sysctl_net_gn.c | 33 +
security/selinux/hooks.c | 5 +-
security/selinux/include/classmap.h | 3 +-
15 files changed, 3290 insertions(+), 4 deletions(-)
create mode 100644 include/linux/gn.h
create mode 100644 include/linux/gn_routing.h
create mode 100644 include/uapi/linux/gn.h
create mode 100644 net/gn/Kconfig
create mode 100644 net/gn/Makefile
create mode 100644 net/gn/gn_proc.c
create mode 100644 net/gn/gn_prot.c
create mode 100644 net/gn/gn_routing.c
create mode 100644 net/gn/sysctl_net_gn.c
--
2.55.0
^ permalink raw reply
* Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages
From: Andrew Lunn @ 2026-07-15 13:05 UTC (permalink / raw)
To: Ayoub Kaanich; +Cc: Russell King, netdev@vger.kernel.org
In-Reply-To: <AS4PR08MB8021E0A64800F977B6887141B7F82@AS4PR08MB8021.eurprd08.prod.outlook.com>
On Wed, Jul 15, 2026 at 08:09:56AM +0000, Ayoub Kaanich wrote:
> Hi,
>
> > In general, we are trying to block user space drivers, by only allowing read.
>
> So in principle, a write from a third party driver (not the NIC own driver) is allowed?
We would expect the code to fit in with the current architecture. So
mdio-i2c would provide a Linux MDIO bus. You "third party driver"
would be a PHY driver.
> Our issue is that the NIC drivers (especially the netlink based
> drivers), have no standard way to expose the I2C bus of the SFP
> module to other drivers. phylink based drivers don't have this
> issue.
>
> The current hierarchy is
>
> net_device => sfp_bus (missing in many drivers) => sfp (internal) => i2c_adapter
>
> For example: ice driver does not create an i2c_adapter or sfp_bus, even though many of the NICs using that driver have SFP28 or QSFP28 pluggable cages.
So Linux Ethernet drivers fall into two classes. Those where Linux
driver the hardware, making use of phylink/phylib, and those where
firmware drive the hardware, eg ice, and pretty much all intel
hardware, and most NICs which support > 10G.
For NICs using firmware, you will need to talk to each vendor, and ask
them to extend their firmware to support your SFP.
For NICs where Linux drives the hardware, which is pretty much all
NICs used in embedded systems, with a bandwidth up to 1G, and some
10G, provide an implementation of the protocol in mdio-i2c, and a PHY
driver, and it should all just work.
Looking at the other devices you pointed to, one used a Marvell
88q2xxx, for which a Linux driver already exists. And there was
sufficient hints in the document to make writing the I2C protocol
possible. The other device explicitly described the I2C protocol, but
did not mention what PHY was used, so might need a PHY driver. But
there are not too many T1 PHYs, so it might have a driver already.
Andrew
^ permalink raw reply
* Re: [for-next v4 0/5] ionic: RDMA completion timestamping support
From: Abhijit Gangurde @ 2026-07-15 13:08 UTC (permalink / raw)
To: jgg, kuba
Cc: leon, davem, allen.hubbe, andrew+netdev, brett.creeley, edumazet,
pabeni, nikhil.agarwal, linux-rdma, netdev, linux-kernel, dwmw2
In-Reply-To: <20260610154216.712374-1-abhijit.gangurde@amd.com>
Hi Jason, Jakub,
Gentle ping — if there are no further concerns, could this series be
merged through the rdma tree?
Thanks,
Abhijit
On 6/10/26 21:12, Abhijit Gangurde wrote:
> Hi,
>
> This series adds RDMA completion timestamp support for ionic.
>
> It enables PHC registration for RDMA timestamp capability, exposes a PHC
> state page for safe user-space reads, maps that PHC state through RDMA
> ucontext mmap, and extends the RDMA CQE format to carry completion
> timestamps.
>
> With this, user space can read completion timestamps and convert them to
> wall time with low overhead.
>
> Provider's PR: https://github.com/linux-rdma/rdma-core/pull/1724
>
> v4:
> - Added alias mapping of mlx5_ib_clock_info to ib_uverbs_clock_info
> v3:
> - Renamed ib_uverbs_phc_state to ib_uverbs_clock_info
> - Moved mlx5 to use the common clock info structure
> - Addressed review feedback from Sashiko
> - https://lore.kernel.org/linux-rdma/20260606050003.3648306-1-abhijit.gangurde@amd.com/
> v2:
> - changed ionic_phc_state to ib_uverbs_phc_state and moved it under
> ib_user_verbs.h
> - https://lore.kernel.org/linux-rdma/20260512092623.1157199-1-abhijit.gangurde@amd.com/
> v1:
> - https://lore.kernel.org/all/20260401102501.3395305-1-abhijit.gangurde@amd.com/
>
> Abhijit Gangurde (5):
> net: ionic: register PHC for rdma timestamping
> net: ionic: Add PHC state page for user space access
> RDMA/ionic: map PHC state into user space
> RDMA/ionic: add completion timestamp to CQE format
> RDMA/mlx5: move mlx5 clock info to common struct ib_uverbs_clock_info
>
> .../infiniband/hw/ionic/ionic_controlpath.c | 34 ++++++++++
> drivers/infiniband/hw/ionic/ionic_datapath.c | 43 ++++++-------
> drivers/infiniband/hw/ionic/ionic_fw.h | 12 +++-
> drivers/infiniband/hw/ionic/ionic_ibdev.h | 2 +
> drivers/infiniband/hw/ionic/ionic_lif_cfg.c | 2 +
> drivers/infiniband/hw/ionic/ionic_lif_cfg.h | 1 +
> .../ethernet/pensando/ionic/ionic_ethtool.c | 12 ++--
> .../net/ethernet/pensando/ionic/ionic_if.h | 1 +
> .../net/ethernet/pensando/ionic/ionic_lif.c | 5 +-
> .../net/ethernet/pensando/ionic/ionic_lif.h | 3 +-
> .../net/ethernet/pensando/ionic/ionic_phc.c | 63 ++++++++++++++++---
> include/uapi/rdma/ib_user_verbs.h | 33 ++++++++++
> include/uapi/rdma/ionic-abi.h | 1 +
> include/uapi/rdma/mlx5-abi.h | 15 ++---
> 14 files changed, 179 insertions(+), 48 deletions(-)
>
^ permalink raw reply
* Re: [PATCH] net: phy: Add driver for Motorcomm Quad 2.5GbE phy
From: Andrew Lunn @ 2026-07-15 13:09 UTC (permalink / raw)
To: Kyle Switch
Cc: Frank.Sae, hkallweit1, linux, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, jianmin.wang, ming.xu, xiaolin.xu, jie.han
In-Reply-To: <47b67113-2903-49b5-a25e-84e704ac017d@motor-comm.com>
On Wed, Jul 15, 2026 at 07:59:55PM +0800, Kyle Switch wrote:
>
>
> On 7/15/26 05:46, Andrew Lunn wrote:
> >> +static inline int ytphy_top_write(struct phy_device *phydev, u32 regnum,
> >> + u16 val)
> >> +{
> >> + struct yt8521_priv *priv = phydev->priv;
> >> + struct mii_bus *bus = phydev->mdio.bus;
> >> +
> >> + return bus->write(bus, priv->top_phy_addr, regnum, val);
> >> +}
> >
> > Please could you explain the architecture in detail. It seems like you
> > are accessing registers of some other device on the bus.
> >
> > Maybe you need to use the code in phy_package.c?
>
> Ans: YT8824 contains top extend reg space, and the addr is fixed, for
> internal phy8824 the value is 9, and external phy8824 is (baseaddr + 4).
Does the "top extend reg space" have values in the ID registers, 2 and
3? Is Linux trying to probe this address space?
Anyway, it does sound like you need to use phy_package. That will give
you a better API for accessing the registers in the other address
space.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: mdio: Kconfig: Group mdio multiplexers in a submenu
From: Andrew Lunn @ 2026-07-15 13:11 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Heiner Kallweit, netdev, linux-kernel,
thomas.petazzoni
In-Reply-To: <20260715082226.51481-3-maxime.chevallier@bootlin.com>
On Wed, Jul 15, 2026 at 10:22:25AM +0200, Maxime Chevallier wrote:
> Move all MDIO muxes under the "MDIO controller drivers" submenu.
>
> This doesn't change any dependency for KConfig options and is
> purely cosmetic.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net] net: rnpgbe: Pass an expression directly in rnpgbe_rm_adapter()
From: Uwe Kleine-König @ 2026-07-15 13:12 UTC (permalink / raw)
To: Markus Elfring
Cc: Dan Carpenter, netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, MD Danish Anwar, Michael Grzeschik, Paolo Abeni,
Vadim Fedorenko, Yibo Dong, LKML, kernel-janitors
In-Reply-To: <8110bb3f-70d9-4f0f-82f2-ffe1262b2962@web.de>
[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]
On Mon, Jul 13, 2026 at 10:22:06AM +0200, Markus Elfring wrote:
> >> The address of a data structure member was determined before
> >> a corresponding null pointer check in the implementation of
> >> the function “rnpgbe_rm_adapter”.
> >>
> >> Thus avoid the risk for undefined behaviour by omitting the variable “hw”.
> >> Pass the required address directly to a function call.
> >>
> >> This issue was detected by using the Coccinelle software.
> >>
> >> Fixes: 2ee95ec17e97c58b65e978a08b75fa8cb6424e4e ("net: rnpgbe: Add register_netdev")
> >
> > There is no NULL dereference here. It's just pointer math.
> > No need for a Fixes tag.
>
> How does your view fit to information in an article like “Fun with
> NULL pointers, part 1”(by Jonathan Corbet from 2009-07-20)?
> https://lwn.net/Articles/342330/
It does fit, because the problematic code discussed in Jonathan Corbet's
article is of the type:
int i = ptr->i;
if (!ptr)
do_something();
while here we have:
int *i = &ptr->i;
if (!ptr)
do_something();
which at least in my test[1] is relevantly different. Note, I didn't
study the C standard if the compiler is free to optimize out
do_something() also in the 2nd case, but at least today gcc doesn't.
Best regards
Uwe
[1] Me knowing about ARM assembly, that's what I checked:
$ cat test.c
#include <stdio.h>
#include <stdlib.h>
struct mystruct {
int i;
char c;
};
int funcdirect(struct mystruct *ptr)
{
int i = ptr->i;
if (!ptr)
return -1;
printf("i = %d\n", i);
return 0;
}
int funcindirect(struct mystruct *ptr)
{
int *i = &ptr->i;
if (!ptr)
return -1;
printf("i = %d\n", *i);
return 0;
}
$ arm-linux-gnueabihf-gcc -O3 -c test.c
$ objdump -D test.o
test.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <funcdirect>:
0: b508 push {r3, lr}
2: 4603 mov r3, r0
4: 4803 ldr r0, [pc, #12] @ (14 <funcdirect+0x14>)
6: 6819 ldr r1, [r3, #0]
8: 4478 add r0, pc
a: f7ff fffe bl 0 <printf>
e: 2000 movs r0, #0
10: bd08 pop {r3, pc}
12: bf00 nop
14: 00000008 andeq r0, r0, r8
00000018 <funcindirect>:
18: b138 cbz r0, 2a <funcindirect+0x12>
1a: 6801 ldr r1, [r0, #0]
1c: 4804 ldr r0, [pc, #16] @ (30 <funcindirect+0x18>)
1e: b508 push {r3, lr}
20: 4478 add r0, pc
22: f7ff fffe bl 0 <printf>
26: 2000 movs r0, #0
28: bd08 pop {r3, pc}
2a: f04f 30ff mov.w r0, #4294967295 @ 0xffffffff
2e: 4770 bx lr
30: 0000000c andeq r0, r0, ip
So in funcdirect the check is not present, while it is in funcindirect.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH net-next v2] net: hns: use u32 for register offset in RCB TX coalescing
From: Daniil Iskhakov @ 2026-07-15 12:58 UTC (permalink / raw)
To: Jian Shen
Cc: Daniil Agalakov, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Daniil Iskhakov, netdev,
linux-kernel, rrv, lvc-project
From: Daniil Agalakov <ade@amicon.ru>
In both hns_rcb_get_tx_coalesced_frames() and
hns_rcb_set_tx_coalesced_frames(), the local variable reg holds a
register offset passed to dsaf_read_dev() or dsaf_write_dev().
Register offsets on this hardware are 32-bit values. Use u32 for reg
to match the register access interfaces and avoid implying that
64-bit offsets are supported.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Daniil Agalakov <ade@amicon.ru>
Signed-off-by: Daniil Iskhakov <dish@amicon.ru>
---
This is an unchanged resend of v1, which missed the previous net-next
development cycle.
Changes in v2:
- no code changes
- reword the commit message
- add my Signed-off-by tag
- rebase onto the current net-next tree
v1: https://lore.kernel.org/all/20260420144047.2846673-1-ade@amicon.ru/
drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
index 635b3a95dd82..3c4e4e8ca140 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_rcb.c
@@ -563,7 +563,7 @@ u32 hns_rcb_get_rx_coalesced_frames(
u32 hns_rcb_get_tx_coalesced_frames(
struct rcb_common_cb *rcb_common, u32 port_idx)
{
- u64 reg;
+ u32 reg;
reg = RCB_CFG_PKTLINE_REG + (port_idx + HNS_RCB_TX_PKTLINE_OFFSET) * 4;
return dsaf_read_dev(rcb_common, reg);
@@ -634,7 +634,7 @@ int hns_rcb_set_tx_coalesced_frames(
{
u32 old_waterline =
hns_rcb_get_tx_coalesced_frames(rcb_common, port_idx);
- u64 reg;
+ u32 reg;
if (coalesced_frames == old_waterline)
return 0;
base-commit: f6f3b36c15ed44de1fbb44e645e4fae8c4a4453e
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v2 1/2] net: mdio: Kconfig: Group mdio controller drivers in a submenu
From: Andrew Lunn @ 2026-07-15 13:14 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Heiner Kallweit, netdev, linux-kernel,
thomas.petazzoni
In-Reply-To: <20260715082226.51481-2-maxime.chevallier@bootlin.com>
On Wed, Jul 15, 2026 at 10:22:24AM +0200, Maxime Chevallier wrote:
> Currently, all inidivual drivers for MDIO bus controllers are directly
> listed under Device drivers -> Network device support. Let's group them
> altogether in a submenu, while keeping the dependency on PHYLIB.
>
> No intended functional change besides the menuconfig ordering.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net] pds_core: yield the CPU while waiting for the adminq to drain
From: Pavan Chebbi @ 2026-07-15 13:14 UTC (permalink / raw)
To: Nikhil P. Rao
Cc: netdev, kuba, brett.creeley, eric.joyner, andrew+netdev, davem,
edumazet, pabeni
In-Reply-To: <20260714201456.1776153-1-nikhil.rao@amd.com>
[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]
On Wed, Jul 15, 2026 at 1:46 AM Nikhil P. Rao <nikhil.rao@amd.com> wrote:
>
> pdsc_adminq_wait_and_dec_once_unused() busy-waits for adminq_refcnt to
> drop to one:
>
> while (!refcount_dec_if_one(&pdsc->adminq_refcnt))
> cpu_relax();
>
> The refcount is held by pdsc_adminq_post() for the duration of an
> in-flight command, which can wait up to devcmd_timeout seconds
> (PDS_CORE_DEVCMD_TIMEOUT is 5) for the hardware to complete. cpu_relax()
> is not a reschedule point, so on a non-preemptible kernel this loop can
> spin on the CPU for several seconds, starving other tasks on that core.
>
> Add cond_resched() to the loop so the waiter yields to other runnable
> tasks while it polls, keeping cpu_relax() as the busy-wait hint between
> checks.
>
> Fixes: 7e82a8745b95 ("pds_core: Prevent race issues involving the adminq")
> Reported-by: sashiko-bot <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2
> Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com>
> Reviewed-by: Eric Joyner <eric.joyner@amd.com>
> ---
> drivers/net/ethernet/amd/pds_core/core.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: phy: at803x: Use a helper to check for phy reset existence
From: Andrew Lunn @ 2026-07-15 13:16 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, davem, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Russell King, Heiner Kallweit, netdev, linux-kernel,
thomas.petazzoni, linux-arm-msm
In-Reply-To: <20260715101355.88536-1-maxime.chevallier@bootlin.com>
On Wed, Jul 15, 2026 at 12:13:54PM +0200, Maxime Chevallier wrote:
> The at803x family of devices are subjected to an errata that requires
> hard-reseting the PHY upon link change.
>
> That can only work if there's a physical reset line wired to the PHY,
> which the driver checks by looking if there's a reset GPIO configured
> for the MDIO device.
>
> The reset may however be controlled through a reset controller, which
> isn't accounted for in the errata handling.
>
> Besides that, PHY drivers aren't expected to directly access the
> mdiodev's resources directly, let's therefore wrap this with a phylib
> helper, that uses a similar mdio helper to check for reset existence.
>
> This was found in preparation for bus-level resource management for
> better mdio scan support.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net] pds_core: fix auxiliary device add/del races
From: Pavan Chebbi @ 2026-07-15 13:23 UTC (permalink / raw)
To: Nikhil P. Rao
Cc: netdev, kuba, brett.creeley, eric.joyner, andrew+netdev, davem,
edumazet, pabeni
In-Reply-To: <20260714210745.1785625-1-nikhil.rao@amd.com>
[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]
On Wed, Jul 15, 2026 at 2:38 AM Nikhil P. Rao <nikhil.rao@amd.com> wrote:
>
> Two paths add or delete the same slot (pf->vfs[vf_id].padev): a VF's
> pdsc_reset_done() and the PF's devlink enable_vnet/disable_vnet handler.
> They serialize on config_lock, but neither guards the slot under it
> correctly.
>
> add() registers and stores a new auxiliary device without first checking
> the slot, so a second add of an already-populated slot leaks the first
> device. del() makes that check outside config_lock, so two concurrent
> dels can both pass it; the first clears the slot, and the second
> dereferences a NULL pointer.
>
> Check and update the slot under config_lock in both paths.
>
> Fixes: b699bdc720c0 ("pds_core: specify auxiliary_device to be created")
> Reported-by: sashiko-bot@kernel.org # Running on a local machine
> Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com>
> Reviewed-by: Brett Creeley <brett.creeley@amd.com>
> ---
> drivers/net/ethernet/amd/pds_core/auxbus.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/amd/pds_core/auxbus.c b/drivers/net/ethernet/amd/pds_core/auxbus.c
> index 73b3481220b1..3acafe10a6d5 100644
> --- a/drivers/net/ethernet/amd/pds_core/auxbus.c
> +++ b/drivers/net/ethernet/amd/pds_core/auxbus.c
> @@ -177,17 +177,21 @@ void pdsc_auxbus_dev_del(struct pdsc *cf, struct pdsc *pf,
> {
> struct pds_auxiliary_dev *padev;
>
> - if (!*pd_ptr)
> - return;
> -
> mutex_lock(&pf->config_lock);
>
> + /* A concurrent del may have already torn this device down and
> + * cleared it.
> + */
> padev = *pd_ptr;
> + if (!padev)
> + goto out_unlock;
> +
> pds_client_unregister(pf, padev->client_id);
> auxiliary_device_delete(&padev->aux_dev);
> auxiliary_device_uninit(&padev->aux_dev);
> *pd_ptr = NULL;
>
> +out_unlock:
> mutex_unlock(&pf->config_lock);
> }
>
> @@ -210,6 +214,13 @@ int pdsc_auxbus_dev_add(struct pdsc *cf, struct pdsc *pf,
>
> mutex_lock(&pf->config_lock);
>
> + /* Nothing to do if the aux device is already present. This also
> + * guards against a second add overwriting *pd_ptr and leaking the
> + * first, symmetric with the check in pdsc_auxbus_dev_del().
> + */
Are these AI-generated-appearing comments really necessary?
Anyway, it is your driver.
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
> + if (*pd_ptr)
> + goto out_unlock;
> +
> mask = BIT_ULL(PDSC_S_FW_DEAD) |
> BIT_ULL(PDSC_S_STOPPING_DRIVER);
> if (cf->state & mask) {
> --
> 2.43.0
>
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]
^ permalink raw reply
* Re: [PATCH net] pds_core: check for workqueue allocation failure
From: Pavan Chebbi @ 2026-07-15 13:26 UTC (permalink / raw)
To: Nikhil P. Rao
Cc: netdev, kuba, brett.creeley, eric.joyner, andrew+netdev, davem,
edumazet, pabeni
In-Reply-To: <20260714212713.1788438-1-nikhil.rao@amd.com>
[-- Attachment #1: Type: text/plain, Size: 809 bytes --]
On Wed, Jul 15, 2026 at 2:57 AM Nikhil P. Rao <nikhil.rao@amd.com> wrote:
>
> pdsc_init_pf() does not check whether create_singlethread_workqueue()
> succeeded.
>
> Fail probe on failure. The workqueue is set up before the timer and
> mutexes, so its failure path must unwind only the earlier setup.
>
> Fixes: c2dbb0904310 ("pds_core: health timer and workqueue")
> Reported-by: sashiko-bot <sashiko-bot@kernel.org>
> Closes: https://sashiko.dev/#/patchset/20260629200358.2626129-1-nikhil.rao%40amd.com?part=2
> Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com>
> Reviewed-by: Brett Creeley <brett.creeley@amd.com>
> ---
> drivers/net/ethernet/amd/pds_core/main.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]
^ permalink raw reply
* Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages
From: Ayoub Kaanich @ 2026-07-15 13:41 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Russell King, netdev@vger.kernel.org, Dr. Lars Völker
In-Reply-To: <cd58995a-6bcf-4283-a072-84651a4f0031@lunn.ch>
Hi,
> We would expect the code to fit in with the current architecture. So
> mdio-i2c would provide a Linux MDIO bus. You "third party driver"
> would be a PHY driver.
Sounds fair.
> For NICs using firmware, you will need to talk to each vendor, and ask
> them to extend their firmware to support your SFP.
That does not sound reasonable, given that the only interface needed to the SFP/PHY is the I2C bus which the kernel could access directly (to read EEPROM for example)
The only change needed as far as I see, is to have the driver expose the internal SFP I2C bus (basically only the I2C read/write functions)
for the case of the ice driver, the functions ice_aq_read_i2c and ice_aq_write_i2c already exists, so creating the i2c_adapter from it should be trivial.
If the NIC does not expose the I2C bus at all, then it would be understandable if a NIC firmware is the only viable path, but it's not the case here.
Best Regards.
Ayoub Kaanich
Principal Software Engineer
Engineering Department
________________________________________
From: Andrew Lunn <andrew@lunn.ch>
Sent: Wednesday, July 15, 2026 03:05 PM
To: Ayoub Kaanich <ayoub.kaanich@technica-engineering.de>
Cc: Russell King <linux@armlinux.org.uk>; netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: Re: RFC: symmetric SET_MODULE_EEPROM_BY_PAGE with i2c_address for non-SFF pages
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
On Wed, Jul 15, 2026 at 08:09:56AM +0000, Ayoub Kaanich wrote:
> Hi,
>
> > In general, we are trying to block user space drivers, by only allowing read.
>
> So in principle, a write from a third party driver (not the NIC own driver) is allowed?
We would expect the code to fit in with the current architecture. So
mdio-i2c would provide a Linux MDIO bus. You "third party driver"
would be a PHY driver.
> Our issue is that the NIC drivers (especially the netlink based
> drivers), have no standard way to expose the I2C bus of the SFP
> module to other drivers. phylink based drivers don't have this
> issue.
>
> The current hierarchy is
>
> net_device => sfp_bus (missing in many drivers) => sfp (internal) => i2c_adapter
>
> For example: ice driver does not create an i2c_adapter or sfp_bus, even though many of the NICs using that driver have SFP28 or QSFP28 pluggable cages.
So Linux Ethernet drivers fall into two classes. Those where Linux
driver the hardware, making use of phylink/phylib, and those where
firmware drive the hardware, eg ice, and pretty much all intel
hardware, and most NICs which support > 10G.
For NICs using firmware, you will need to talk to each vendor, and ask
them to extend their firmware to support your SFP.
For NICs where Linux drives the hardware, which is pretty much all
NICs used in embedded systems, with a bandwidth up to 1G, and some
10G, provide an implementation of the protocol in mdio-i2c, and a PHY
driver, and it should all just work.
Looking at the other devices you pointed to, one used a Marvell
88q2xxx, for which a Linux driver already exists. And there was
sufficient hints in the document to make writing the I2C protocol
possible. The other device explicitly described the I2C protocol, but
did not mention what PHY was used, so might need a PHY driver. But
there are not too many T1 PHYs, so it might have a driver already.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v3 06/15] net: macb: allocate tieoff descriptor once across device lifetime
From: Théo Lebrun @ 2026-07-15 13:48 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Richard Cochran, Russell King,
netdev, linux-kernel, Nicolas Ferre, Claudiu Beznea,
Paolo Valerio, Vladimir Kondratiev, Gregory CLEMENT,
Benoît Monin, Tawfik Bayouk, Thomas Petazzoni,
Maxime Chevallier
In-Reply-To: <DJXFDPIB17FW.2BN105BPCBSKB@bootlin.com>
On Mon Jul 13, 2026 at 2:00 PM CEST, Théo Lebrun wrote:
> On Thu Jul 2, 2026 at 12:54 PM CEST, Nicolai Buchwitz wrote:
>> On 1.7.2026 17:59, Théo Lebrun wrote:
>>> The tieoff descriptor is a RX DMA descriptor ring of size one. It gets
>>> configured onto queues for Wake-on-LAN during system-wide suspend when
>>> hardware does not support disabling individual queues
>>> (MACB_CAPS_QUEUE_DISABLE).
>>>
>>> MACB/GEM driver allocates it alongside the main RX ring
>>> inside macb_alloc() at open. Free is done by macb_free() at close.
>>>
>>> Change to allocate once at probe and free on probe failure or device
>>> removal. This makes the tieoff descriptor lifetime much longer,
>>> avoiding repeating coherent buffer allocation on each open/close cycle.
>>>
>>> Main benefit: we dissociate its lifetime from the main ring's lifetime.
>>> That way there is less work to be doing on resources (re)alloc. This
>>> currently happens on close/open, but will soon also happen on context
>>> swap operations (set_ringparam, change_mtu, set_channels, etc).
>>>
>>> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
>>> ---
>>> drivers/net/ethernet/cadence/macb_main.c | 75
>>> +++++++++++++++++---------------
>>> 1 file changed, 41 insertions(+), 34 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/cadence/macb_main.c
>>> b/drivers/net/ethernet/cadence/macb_main.c
>>> index 8b52122bc134..951a7f080225 100644
>>> --- a/drivers/net/ethernet/cadence/macb_main.c
>>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>>
>>> [...]
>>
>>> static void macb_init_rings(struct macb *bp)
>>> @@ -2832,8 +2801,6 @@ static void macb_init_rings(struct macb *bp)
>>> bp->queues[0].tx_head = 0;
>>> bp->queues[0].tx_tail = 0;
>>> desc->ctrl |= MACB_BIT(TX_WRAP);
>>> -
>>> - macb_init_tieoff(bp);
>>> }
>>>
>>> static void macb_reset_hw(struct macb *bp)
>>> @@ -5518,6 +5485,38 @@ static int eyeq5_init(struct platform_device
>>> *pdev)
>>> return ret;
>>> }
>>>
>>> +static int macb_alloc_tieoff(struct macb *bp)
>>> +{
>>> + /* Tieoff is a workaround in case HW cannot disable queues, for PM.
>>> */
>>> + if (bp->caps & MACB_CAPS_QUEUE_DISABLE)
>>> + return 0;
>>
>> Before, the tieoff was allocated in macb_alloc(), which the at91ether
>> path
>> never called. Now it's allocated from macb_probe() for all variants,
>> gated only
>> on MACB_CAPS_QUEUE_DISABLE, so EMAC gets a coherent descriptor it never
>> uses.
>>
>> Add MACB_CAPS_MACB_IS_EMAC to the if statement?
>
> Clearly. That EMAC distinction keeps being annoying.
Well well well. Under AT91 with WOL active there is nothing preventing
the tieoff from being used in macb_suspend(). Meaning the tieoff is
being used zero-initialised. Not advisable.
So I withdraw my previous comment: we won't shield macb_alloc_tieoff()
from IS_EMAC and maybe it will fix a bug.
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] net: core: use WARN_ON_ONCE in datagram iterators
From: Pavan Chebbi @ 2026-07-15 13:54 UTC (permalink / raw)
To: Igor Putko; +Cc: netdev, davem, edumazet, kuba, pabeni, horms, linux-kernel
In-Reply-To: <20260714082511.2817-1-igorpetindev@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]
On Tue, Jul 14, 2026 at 1:55 PM Igor Putko <igorpetindev@gmail.com> wrote:
>
> Datagram fragment iteration helpers check for invalid buffer offsets
> using WARN_ON(). In fast-path packet processing routines, a malformed
> skb or lower-level driver bug triggering this check can result in
> unbounded dmesg logging.
>
IMO the things that you mention as the root cause are the ones need
fixing. I don't see a reason why the log should be changed here..
> Excessive console logging in data-path contexts introduces severe I/O
> latency overhead and risks triggering a DoS or system instability
> via log flooding.
>
> Replace WARN_ON() with WARN_ON_ONCE() in __skb_datagram_iter() and
> skb_copy_datagram_from_iter(). This ensures anomalous conditions remain
> reportable for debugging without spamming the kernel log on repeated
> occurrences.
>
> Signed-off-by: Igor Putko <igorpetindev@gmail.com>
> ---
> net/core/datagram.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index c285c6465..125b52870 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -416,7 +416,7 @@ static int __skb_datagram_iter(const struct sk_buff *skb, int offset,
> int end;
> const skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>
> - WARN_ON(start > offset + len);
> + WARN_ON_ONCE(start > offset + len);
>
> end = start + skb_frag_size(frag);
> if ((copy = end - offset) > 0) {
> @@ -449,7 +449,7 @@ static int __skb_datagram_iter(const struct sk_buff *skb, int offset,
> skb_walk_frags(skb, frag_iter) {
> int end;
>
> - WARN_ON(start > offset + len);
> + WARN_ON_ONCE(start > offset + len);
>
> end = start + frag_iter->len;
> if ((copy = end - offset) > 0) {
> @@ -570,7 +570,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,
> int end;
> const skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>
> - WARN_ON(start > offset + len);
> + WARN_ON_ONCE(start > offset + len);
>
> end = start + skb_frag_size(frag);
> if ((copy = end - offset) > 0) {
> @@ -594,7 +594,7 @@ int skb_copy_datagram_from_iter(struct sk_buff *skb, int offset,
> skb_walk_frags(skb, frag_iter) {
> int end;
>
> - WARN_ON(start > offset + len);
> + WARN_ON_ONCE(start > offset + len);
>
> end = start + frag_iter->len;
> if ((copy = end - offset) > 0) {
> --
> 2.47.3
>
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5469 bytes --]
^ permalink raw reply
* Re: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
From: kernel test robot @ 2026-07-15 14:01 UTC (permalink / raw)
To: Simon Schippers
Cc: oe-lkp, lkp, Brett Sheffield, netdev, linux-kernel, ltp,
Willem de Bruijn, Jason Wang, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Michael S . Tsirkin, Simon Horman,
Jonathan Corbet, Shuah Khan, Andrew Lunn, Tim Gebauer, linux-doc,
Simon Schippers, oliver.sang
In-Reply-To: <20260709095511.168235-1-simon.schippers@tu-dortmund.de>
Hello,
kernel test robot noticed "ltp.ioctl03.fail" on:
commit: 09154ff2072e36b86ba2d92d436b7f27df153ed1 ("[PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE")
url: https://github.com/intel-lab-lkp/linux/commits/Simon-Schippers/tun-tap-vhost-net-make-qdisc-backpressure-opt-in-via-IFF_BACKPRESSURE/20260709-181234
base: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git fabb881df322da25442f98d23f5fa371e3c78ec4
patch link: https://lore.kernel.org/all/20260709095511.168235-1-simon.schippers@tu-dortmund.de/
patch subject: [PATCH net v3] tun/tap & vhost-net: make qdisc backpressure opt-in via IFF_BACKPRESSURE
in testcase: ltp
version:
with following parameters:
disk: 1HDD
fs: ext4
test: syscalls-03
config: x86_64-rhel-9.4-ltp
compiler: gcc-14
test machine: 4 threads 1 sockets Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (Ivy Bridge) with 8G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202607151550.5d829a99-lkp@intel.com
....
^[[1;37mgetuid03: ^[[0m^[[1;32mpass^[[0m (0.028s)
^[[1;37mioctl03: ^[[0m^[[1;31mfail^[[0m (0.047s) <-----
^[[1;37mioctl05: ^[[0m^[[1;32mpass^[[0m (0.471s)
....
Execution time: 3m 35s
Disconnecting from SUT: default
Target information
──────────────────
Kernel: Linux 7.2.0-rc1+ #1 SMP PREEMPT_DYNAMIC Sun Jul 12 07:25:38 CST 2026
Cmdline: ip=::::lkp-ivb-d04::dhcp
root=/dev/ram0
RESULT_ROOT=/result/ltp/1HDD-ext4-syscalls-03/lkp-ivb-d04/debian-13-x86_64-20250902.cgz/x86_64-rhel-9.4-ltp/gcc-14/09154ff2072e36b86ba2d92d436b7f27df153ed1/0
BOOT_IMAGE=/pkg/linux/x86_64-rhel-9.4-ltp/gcc-14/09154ff2072e36b86ba2d92d436b7f27df153ed1/vmlinuz-7.2.0-rc1+
branch=linux-devel/devel-hourly-20260709-190759
job=/lkp/jobs/scheduled/lkp-ivb-d04/ltp-1HDD-ext4-syscalls-03-debian-13-x86_64-20250902.cgz-09154ff2072e-20260712-19649-tc8bu6-0.yaml
user=lkp
ARCH=x86_64
kconfig=x86_64-rhel-9.4-ltp
commit=09154ff2072e36b86ba2d92d436b7f27df153ed1
intremap=posted_msi
max_uptime=7200
LKP_SERVER=internal-lkp-server
nokaslr
selinux=0
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
console=tty0
earlyprintk=ttyS0,115200
console=ttyS0,115200
vga=normal
rw
keep_initrds=/osimage/pkg/debian-13-x86_64-20250902.cgz/ltp-x86_64-ed2758122-1_20260711.cgz
acpi_rsdp=0x000f0490
Machine: unknown
Arch: x86_64
RAM: 6895596 kB
Swap: 0 kB
Distro: debian 13
────────────────────────
TEST SUMMARY
────────────────────────
Suite: syscalls-03
Runtime: 3m 24s
Runs: 183
Results:
Passed: 2144
Failed: 1
Broken: 0
Skipped: 222
Warnings: 0
^[[1;31mFailures:^[[0m
• ioctl03
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260715/202607151550.5d829a99-lkp@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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