* Re: [PATCH iproute2-next v2 2/2] devlink: support u64-array values in devlink param show/set
From: David Ahern @ 2026-07-01 14:34 UTC (permalink / raw)
To: Ratheesh Kannoth
Cc: stephen, kuba, linux-kernel, netdev, andrew+netdev, edumazet,
pabeni, jiri
In-Reply-To: <akR7g8aWfws3h2jx@rkannoth-OptiPlex-7090>
On 6/30/26 8:29 PM, Ratheesh Kannoth wrote:
> On 2026-06-30 at 20:06:17, David Ahern (dsahern@kernel.org) wrote:
>> On 6/29/26 7:50 PM, Ratheesh Kannoth wrote:
>>> diff --git a/devlink/devlink.c b/devlink/devlink.c
>>> index 9372e92f..3c29601d 100644
>>> --- a/devlink/devlink.c
>>> +++ b/devlink/devlink.c
>>> @@ -3496,13 +3496,115 @@ static const struct param_val_conv param_val_conv[] = {
>>> };
>>>
>>> #define PARAM_VAL_CONV_LEN ARRAY_SIZE(param_val_conv)
>>> +#define DEVLINK_PARAM_MAX_ARRAY_SIZE 32
>>
>> Why 32? Is that based on current code?
> Yes, this aligns with the current kernel-side limits. See:
> https://lore.kernel.org/all/20260609040453.711932-5-rkannoth@marvell.com/
>
>> How does the kernel side handle
>> the number of parameters? What happens if the kernel sends more than 32
>> parameters - from a user's perspective, not this code and processing the
>> output?
> The kernel strictly validates and restricts the number of parameters. To be safe, this patch
> adds an explicit bounds check to prevent userspace issues if that threshold is ever crossed.
>
> Ideally, since "union devlink_param_value" is omitted from the UAPI, we have to define
> DEVLINK_PARAM_MAX_ARRAY_SIZE here. Moving the underlying structures to the UAPI in the
> future would allow us to share a single definition and avoid this hardcoded value in userspace.
iproute2 needs to be backward and forward compatible. As it stands, a
new kernel can allow more than 32 entries and an older iproute2 will not
display all of them. That is wrong.
Let's make the limit part of the uapi. If you do not want to do that
now, then iproute2 code needs to handle a larger size.
^ permalink raw reply
* Re: [PATCH net-next v2] ice: use dev_err_probe() in ice_probe()
From: Maciej Fijalkowski @ 2026-07-01 14:37 UTC (permalink / raw)
To: Rongguang Wei
Cc: netdev, intel-wired-lan, aleksandr.loktionov, przemyslaw.kitszel,
anthony.l.nguyen, andrew+netdev, Rongguang Wei
In-Reply-To: <20260701013618.29934-1-clementwei90@163.com>
On Wed, Jul 01, 2026 at 09:36:18AM +0800, Rongguang Wei wrote:
> From: Rongguang Wei <weirongguang@kylinos.cn>
>
> dev_err_probe() logs the error and returns the supplied error code, which
> allows probe error paths to be written more compactly.
>
> Use dev_err_probe() in ice_probe() for error paths that currently print an
> error message and immediately return the same error code. This keeps the
> existing error handling semantics while reducing open-coded logging and
> return sequences.
>
> Signed-off-by: Rongguang Wei <weirongguang@kylinos.cn>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> v2:
> - Fix commit message per Aleksandr Loktionov's recommendation.
> v1: https://lore.kernel.org/netdev/20260630032537.42605-1-clementwei90@163.com/T/#t
> ---
> drivers/net/ethernet/intel/ice/ice_main.c | 24 ++++++++---------------
> 1 file changed, 8 insertions(+), 16 deletions(-)
Could we also address rest of sites within driver at this very same
commit?
drivers/net/ethernet/intel/ice/ice_dcb_lib.c-873- dev_err(dev, "DCB init failed\n");
drivers/net/ethernet/intel/ice/ice_dcb_lib.c:874: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-4482- dev_warn(dev, "Failed to initialize hardware after applying Tx scheduling configuration.\n");
drivers/net/ethernet/intel/ice/ice_main.c:4483: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-4543- dev_err(dev, "Fail during requesting FW: %d\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:4544: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-4961- dev_err(dev, "ice_init_pf failed: %d\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:4962: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-5192- dev_err(dev, "BAR0 I/O map error %d\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:5193: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-5206- dev_err(dev, "DMA configuration failed: 0x%x\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:5207: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-5244- dev_err(dev, "ice_init_hw failed: %d\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:5245: return err;
--
drivers/net/ethernet/intel/ice/ice_main.c-9627- netdev_err(netdev, "Failed to get link info, error %d\n", err);
drivers/net/ethernet/intel/ice/ice_main.c:9628: return err;
--
drivers/net/ethernet/intel/ice/devlink/devlink.c-1244- dev_err(dev, "ice_init_hw failed: %d\n", err);
drivers/net/ethernet/intel/ice/devlink/devlink.c:1245: return err;
--
drivers/net/ethernet/intel/ice/ice_ptp.c-1935- dev_err(ice_pf_to_dev(pf), "PTP failed to set time %d\n", err);
drivers/net/ethernet/intel/ice/ice_ptp.c:1936: return err;
--
drivers/net/ethernet/intel/ice/ice_ptp.c-2000- dev_err(dev, "PTP failed to adjust time, err %d\n", err);
drivers/net/ethernet/intel/ice/ice_ptp.c:2001: return err;
--
drivers/net/ethernet/intel/ice/ice_sriov.c-829- dev_err(dev, "Failed to enable SR-IOV: %d\n", err);
drivers/net/ethernet/intel/ice/ice_sriov.c:830: return err;
--
drivers/net/ethernet/intel/ice/ice_eswitch_br.c-314- dev_info(dev, "Bridge port lookup failed (vsi=%u)\n", vsi_idx);
drivers/net/ethernet/intel/ice/ice_eswitch_br.c:315: return ERR_PTR(-EINVAL);
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index e2fd2dab03e3..31aa42f8e6d3 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -5161,10 +5161,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
> struct ice_hw *hw;
> int err;
>
> - if (pdev->is_virtfn) {
> - dev_err(dev, "can't probe a virtual function\n");
> - return -EINVAL;
> - }
> + if (pdev->is_virtfn)
> + return dev_err_probe(dev, -EINVAL, "can't probe a virtual function\n");
>
> /* when under a kdump kernel initiate a reset before enabling the
> * device in order to clear out any pending DMA transactions. These
> @@ -5188,10 +5186,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
> return err;
>
> err = pcim_iomap_regions(pdev, BIT(ICE_BAR0), dev_driver_string(dev));
> - if (err) {
> - dev_err(dev, "BAR0 I/O map error %d\n", err);
> - return err;
> - }
> + if (err)
> + return dev_err_probe(dev, err, "BAR0 I/O map error %d\n", err);
>
> pf = ice_allocate_pf(dev);
> if (!pf)
> @@ -5202,10 +5198,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
>
> /* set up for high or low DMA */
> err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
> - if (err) {
> - dev_err(dev, "DMA configuration failed: 0x%x\n", err);
> - return err;
> - }
> + if (err)
> + return dev_err_probe(dev, err, "DMA configuration failed: 0x%x\n", err);
>
> pci_set_master(pdev);
> pf->pdev = pdev;
> @@ -5240,10 +5234,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
> return ice_probe_recovery_mode(pf);
>
> err = ice_init_hw(hw);
> - if (err) {
> - dev_err(dev, "ice_init_hw failed: %d\n", err);
> - return err;
> - }
> + if (err)
> + return dev_err_probe(dev, err, "ice_init_hw failed: %d\n", err);
>
> ice_init_dev_hw(pf);
>
> --
> 2.25.1
>
>
^ permalink raw reply
* Re: [PATCH net] net/mlx5: HWS, fix matcher leak on resize target setup failure
From: Paolo Abeni @ 2026-07-01 14:38 UTC (permalink / raw)
To: saeedm, tariqt, mbloch, leon
Cc: andrew+netdev, davem, edumazet, kuba, kliteyn, vdogaru, horms,
kees, stable, netdev, linux-rdma, linux-kernel, jianhao.xu, zilin,
Dawei Feng
In-Reply-To: <20260629064049.3852759-1-dawei.feng@seu.edu.cn>
On 6/29/26 8:40 AM, Dawei Feng wrote:
> hws_bwc_matcher_move() allocates a replacement matcher before setting it
> as the resize target. If mlx5hws_matcher_resize_set_target() fails, the
> replacement matcher is not attached anywhere and is leaked.
>
> Fix the leak by destroying the replacement matcher before returning from
> the resize-target failure path.
>
> The bug was first flagged by an experimental analysis tool we are
> developing for kernel memory-management bugs while analyzing
> v6.13-rc1. The tool is still under development and is not yet publicly
> available. Manual inspection confirms that the bug is still
> present in v7.1.1.
>
> An x86_64 allyesconfig build showed no new warnings. As we do not have a
> mlx5 HWS-capable device to test with, no runtime testing was able to be
> performed.
>
> Fixes: 2111bb970c78 ("net/mlx5: HWS, added backward-compatible API handling")
> Cc: stable@vger.kernel.org
> Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
@nvidia team, double checking I did not miss any relevant communication.
The last process update I recall is that one of the people listed in
maintainer file will ack patches for us to merge directly into the
net/net-next trees.
Should we consider any ack from @nvidia sufficient to take over?
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Andrew Lunn @ 2026-07-01 14:43 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: dinguyen, maxime.chevallier, rmk+kernel, krzk+dt, conor+dt, robh,
davem, edumazet, kuba, pabeni, andrew+netdev, devicetree,
linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20260630133108.27244-4-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Tue, Jun 30, 2026 at 06:31:08AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Russell King's commit de696c63c1dc ("net: stmmac: socfpga: convert to
> use phy_interface") replaced mac_interface with phy_interface in
> socfpga_get_plat_phymode(), noting that no upstream DTS files set the
> "mac-mode" property, making the two values identical.
>
> The Agilex5 SoCDK TSN Config2 board is an exception: its gmac1 TSN
> port uses GMII internally in the MAC while the PHY-side interface is
> RGMII, so mac-mode and phy-mode differ. Without restoring mac_interface
> support, the MAC is configured with RGMII instead of GMII, causing
> connectivity failures on this board.
>
> Add socfpga_of_get_mac_mode() to read the optional "mac-mode" DT
> property and store it in a new mac_interface field. When the property
> is absent, mac_interface falls back to phy_interface, preserving
> the existing behaviour for all other boards.
I don't actually see a need for mac-mode. From what you are saying,
there is no choice. The MAC is hard wired to the converter block. So
you can just look at the compatible. You are going to need to use the
compatible anyway, to mask the phy-mode to handle the "MAC" doing the
RGMII delays.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v11 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: Maciej Fijalkowski @ 2026-07-01 14:45 UTC (permalink / raw)
To: Dipayaan Roy
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
kuba, pabeni, leon, longli, kotaranov, horms, shradhagupta,
ssengar, ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, dipayanroy, leitao, kees,
john.fastabend, hawk, bpf, daniel, ast, sdf, yury.norov,
pavan.chebbi
In-Reply-To: <20260701141808.461554-1-dipayanroy@linux.microsoft.com>
On Wed, Jul 01, 2026 at 07:15:44AM -0700, Dipayaan Roy wrote:
> On some ARM64 platforms with 4K PAGE_SIZE, utilizing page_pool
> fragments for allocation in the RX refill path (~2kB buffer per fragment)
> causes 15-20% throughput regression under high connection counts
> (>16 TCP streams at 180+ Gbps). Using full-page buffers on these
> platforms shows no regression and restores line-rate performance.
>
> This behavior is observed on a single platform; other platforms
> perform better with page_pool fragments, indicating this is not a
> page_pool issue but platform-specific.
>
> This series adds an ethtool private flag "full-page-rx" to let the
> user opt in to one RX buffer per page:
>
> ethtool --set-priv-flags eth0 full-page-rx on
>
> There is no behavioral change by default. The flag can be persisted
> via udev rule for affected platforms.
Were you able to track down what is the actual bottleneck on the 'broken'
platform? What is the performance of full-page approach on healthy
platforms? On changelog below you mention the frag approach 'outperforms'
the full-page one.
>
> This series depends on the following fixes now merged in net-next:
> commit 17bfe0a8c014 ("net: mana: Add NULL guards in teardown path to prevent panic on attach failure")
> commit 5b05aa36ee24 ("net: mana: Skip redundant detach on already-detached port")
>
> Changes in v11:
> - Rebased on net-next
> Changes in v10:
> - Rebased on net-next which now includes the prerequisite fixes.
> - Recovery logic in mana_set_priv_flags() leverages the idempotent
> mana_detach() from the merged fixes.
> Changes in v9:
> - Added correct tree.
> Changes in v8:
> - Fixed queue_reset_work recovery by restoring port_is_up before
> scheduling reset so the handler can properly re-attach.
> - Simplified "err && schedule_port_reset" to "schedule_port_reset".
> Changes in v7:
> - Rebased onto net-next.
> - Retained private flag approach after David Wei's testing on
> Grace (ARM64) confirmed that fragment mode outperforms
> full-page mode on other platforms, validating this is a
> single-platform workaround rather than a generic issue.
> Changes in v6:
> - Added missed maintainers.
> Changes in v5:
> - Split prep refactor into separate patch (patch 1/2)
> Changes in v4:
> - Dropping the smbios string parsing and add ethtool priv flag
> to reconfigure the queues with full page rx buffers.
> Changes in v3:
> - changed u8* to char*
> Changes in v2:
> - separate reading string index and the string, remove inline.
>
> Dipayaan Roy (2):
> net: mana: refactor mana_get_strings() and mana_get_sset_count() to
> use switch
> net: mana: force full-page RX buffers via ethtool private flag
>
> drivers/net/ethernet/microsoft/mana/mana_en.c | 22 ++-
> .../ethernet/microsoft/mana/mana_ethtool.c | 178 +++++++++++++++---
> include/net/mana/mana.h | 8 +
> 3 files changed, 177 insertions(+), 31 deletions(-)
>
> --
> 2.43.0
>
>
^ permalink raw reply
* [PATCH net v3] net: usb: lan78xx: disable VLAN filter in promiscuous mode
From: Enrico Pozzobon via B4 Relay @ 2026-07-01 14:47 UTC (permalink / raw)
To: Thangaraj Samynathan, Rengarajan Sundararajan, UNGLinuxDriver,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Woojung.Huh
Cc: netdev, linux-usb, linux-kernel, Enrico Pozzobon
From: Enrico Pozzobon <enrico.pozzobon@dissecto.com>
The hardware VLAN filter (RFE_CTL_VLAN_FILTER_) drops VLAN-tagged frames
whose VID has not been registered via lan78xx_vlan_rx_add_vid(). It is
left enabled in promiscuous mode, so packet capture (e.g. tcpdump or
Wireshark) does not see tagged frames for unregistered VIDs.
Clear the filter while the interface is promiscuous and restore it from
NETIF_F_HW_VLAN_CTAG_FILTER otherwise. Enforce the same condition in
lan78xx_set_features() so netdev_update_features() cannot re-enable the
filter while promiscuous.
Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
Signed-off-by: Enrico Pozzobon <enrico.pozzobon@dissecto.com>
---
Currently, on microchip lan7801, enabling promiscuous mode does not
result in VLAN tagged packets being captured. This patch fixes this,
forcing the RFE_CTL_VLAN_FILTER_ flag to be off when promiscuous mode is
enabled.
---
Changes in v3:
- EDITME: describe what is new in this series revision.
- EDITME: use bulletpoints and terse descriptions.
- Link to v2: https://patch.msgid.link/20260701-lan78xx-vlan-promisc-v2-1-fe3b18066728@dissecto.com
Changes in v2:
- moved VLAN filter logic into lan78xx_update_vlan_filter()
- Link to v1: https://patch.msgid.link/20260630-lan78xx-vlan-promisc-v1-1-fbf0f903bd8f@dissecto.com
To: Thangaraj Samynathan <Thangaraj.S@microchip.com>
To: Rengarajan Sundararajan <Rengarajan.S@microchip.com>
To: UNGLinuxDriver@microchip.com
To: Andrew Lunn <andrew+netdev@lunn.ch>
To: "David S. Miller" <davem@davemloft.net>
To: Eric Dumazet <edumazet@google.com>
To: Jakub Kicinski <kuba@kernel.org>
To: Paolo Abeni <pabeni@redhat.com>
To: Woojung.Huh@microchip.com
Cc: netdev@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/usb/lan78xx.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index c4cebacabcb5..cb782d81d84f 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -1499,6 +1499,17 @@ static void lan78xx_deferred_multicast_write(struct work_struct *param)
return;
}
+static void lan78xx_update_vlan_filter(struct lan78xx_priv *pdata,
+ struct net_device *netdev,
+ netdev_features_t features)
+{
+ if ((features & NETIF_F_HW_VLAN_CTAG_FILTER) &&
+ !(netdev->flags & IFF_PROMISC))
+ pdata->rfe_ctl |= RFE_CTL_VLAN_FILTER_;
+ else
+ pdata->rfe_ctl &= ~RFE_CTL_VLAN_FILTER_;
+}
+
static void lan78xx_set_multicast(struct net_device *netdev)
{
struct lan78xx_net *dev = netdev_priv(netdev);
@@ -1533,6 +1544,8 @@ static void lan78xx_set_multicast(struct net_device *netdev)
}
}
+ lan78xx_update_vlan_filter(pdata, dev->net, dev->net->features);
+
if (netdev_mc_count(dev->net)) {
struct netdev_hw_addr *ha;
int i;
@@ -3074,10 +3087,7 @@ static int lan78xx_set_features(struct net_device *netdev,
else
pdata->rfe_ctl &= ~RFE_CTL_VLAN_STRIP_;
- if (features & NETIF_F_HW_VLAN_CTAG_FILTER)
- pdata->rfe_ctl |= RFE_CTL_VLAN_FILTER_;
- else
- pdata->rfe_ctl &= ~RFE_CTL_VLAN_FILTER_;
+ lan78xx_update_vlan_filter(pdata, netdev, features);
spin_unlock_irqrestore(&pdata->rfe_ctl_lock, flags);
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260623-lan78xx-vlan-promisc-83af8a48a7ec
Best regards,
--
Enrico Pozzobon <enrico.pozzobon@dissecto.com>
^ permalink raw reply related
* Re: [PATCH net-next v2 1/1] net: rnpgbe: fix mailbox endianness and remove pointer casts
From: Andrew Lunn @ 2026-07-01 14:47 UTC (permalink / raw)
To: Dong Yibo
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, vadim.fedorenko,
netdev, linux-kernel, yaojun
In-Reply-To: <20260701032208.1843156-2-dong100@mucse.com>
On Wed, Jul 01, 2026 at 11:22:08AM +0800, Dong Yibo wrote:
> The rnpgbe mailbox exchanges data through 32-bit MMIO registers in
> little-endian wire format. The original code had two problems:
>
> 1. FW structs (with __le16/__le32 fields) were cast to (u32 *)
> before reaching the mailbox transport, hiding the endian
> annotations from sparse.
>
> 2. No cpu_to_le32()/le32_to_cpu() conversion was done between
> CPU-endian MMIO values and the little-endian payload, causing
> data corruption on big-endian systems.
>
> Fix by adding the missing byte-order conversions in the transport
> layer and introducing union wrappers (mbx_fw_cmd_req_u,
> mbx_fw_cmd_reply_u) that overlay each FW struct with a __le32
> dwords[] array. Callers fill named fields using cpu_to_le16/32(),
> then pass dwords[] to the transport, which now takes explicit
> __le32 * instead of u32 *. This eliminates all pointer casts on
> the mailbox data path and lets sparse verify the conversions.
>
> Fixes: 4543534c3ef5 ("net: rnpgbe: Add basic mbx ops support")
> Signed-off-by: Dong Yibo <dong100@mucse.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] qede: Prevent possible snprintf() truncation by bounding %s string format
From: Baran Tuna @ 2026-07-01 14:47 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Baran Tuna, Breno Leitao,
open list:QLOGIC QL4xxx ETHERNET DRIVER, open list
GCC warning shows that formatted strings may
exceed the fixed-size destination buffers.
Bounding the %s string format
so the maximum formatted output always fits.
This eliminates the -Wformat-truncation warning.
Signed-off-by: Baran Tuna <barant@fastmail.com>
---
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index 647f30a16a94..5428f53150a0 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -618,10 +618,10 @@ static void qede_get_drvinfo(struct net_device *ndev,
if ((strlen(storm) + strlen("[storm]")) <
sizeof(info->version))
snprintf(info->version, sizeof(info->version),
- "[storm %s]", storm);
+ "[storm %.16s]", storm);
else
snprintf(info->version, sizeof(info->version),
- "%s", storm);
+ "%.16s", storm);
if (edev->dev_info.common.mbi_version) {
snprintf(mbi, ETHTOOL_FWVERS_LEN, "%d.%d.%d",
@@ -632,10 +632,10 @@ static void qede_get_drvinfo(struct net_device *ndev,
(edev->dev_info.common.mbi_version &
QED_MBI_VERSION_0_MASK) >> QED_MBI_VERSION_0_OFFSET);
snprintf(info->fw_version, sizeof(info->fw_version),
- "mbi %s [mfw %s]", mbi, mfw);
+ "mbi %.10s [mfw %.10s]", mbi, mfw);
} else {
snprintf(info->fw_version, sizeof(info->fw_version),
- "mfw %s", mfw);
+ "mfw %.16s", mfw);
}
strscpy(info->bus_info, pci_name(edev->pdev), sizeof(info->bus_info));
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3] xsk: fix memory corruptions in net/core/xdp.c
From: Paolo Abeni @ 2026-07-01 14:52 UTC (permalink / raw)
To: Clement Lecigne, Fijalkowski, Maciej
Cc: Lobakin, Aleksander, edumazet@google.com, netdev@vger.kernel.org,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
kuba@kernel.org, sdf@fomichev.me, horms@kernel.org,
john.fastabend@gmail.com, ast@kernel.org, daniel@iogearbox.net
In-Reply-To: <CAHuCGd=KJqrem_WTdZ6LSeTpdaSauw1JXe9EB3x6QRtVvFbTLg@mail.gmail.com>
On 6/29/26 1:15 PM, Clement Lecigne wrote:
> On Mon, Jun 29, 2026 at 12:34 PM Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com> wrote:
>>
>>>
>>> From: Clément Lecigne <clecigne@google.com>
>>>
>>> Commit 560d958c6c68 ("xsk: add generic XSk &xdp_buff -> skb conversion")
>>> introduced a vulnerability in the handling of XDP_PASS for AF_XDP zero-copy
>>> frames.
>>>
>>> Note: Currently, this specific AF_XDP zero-copy conversion path is only
>>> reachable from the drivers/net/ethernet/intel/ice and
>>> drivers/net/ethernet/intel/idpf drivers.
>>>
>>> When building an skb, xdp_build_skb_from_zc() uses the chunk size
>>> (xdp->frame_sz) for the allocation. However, napi_build_skb() automatically
>>> reserves space at the end of the allocation for the skb_shared_info
>>> structure.
>>>
>>> Most high performance UMEM applications use 4K chunks, where the
>>> corruption cannot happen. However, if the UMEM is configured with 2KB
>>> chunks (a very common configuration to maximize packet density in memory),
>>> a standard 1500 MTU packet will trigger the corruption because the required
>>> space exceeds the 2048 byte chunk size:
>>>
>>> Headroom (256) + Packet (1514) + skb_shared_info (320) = 2090 bytes
>>>
>>> Because 2090 bytes > 2048 bytes and __skb_put() does not perform bounds
>>> checking, the memcpy() writes past the available linear data area and
>>> corrupts the skb_shared_info structure. This can lead to arbitrary code
>>> execution if pointers like destructor_arg are overwritten.
>>>
>>> Additionally, in xdp_copy_frags_from_zc(), the allocation size is set
>>> strictly to the fragment size (len), but the subsequent memcpy() uses
>>> LARGEST_ALIGN(len). This mismatch results in an out-of-bounds write of
>>> up to 7 bytes, which triggers KASAN warnings and is unsafe despite typical
>>> page pool allocator padding.
>>>
>>> Fix the skb allocation in xdp_build_skb_from_zc() by dynamically
>>> calculating the exact truesize required using SKB_HEAD_ALIGN() to
>>> properly account for the headroom, the LARGEST_ALIGN(len), and the
>>> skb_shared_info overhead.
>>>
>>> Fix the out-of-bounds write in xdp_copy_frags_from_zc() by rounding up
>>> the allocation request using LARGEST_ALIGN(len) to match the copy
>>> operation.
>>>
>>> Fixes: 560d958c6c68 ("xsk: add generic XSk &xdp_buff -> skb conversion")
>>> CC: Alexander Lobakin <aleksander.lobakin@intel.com>
>>> CC: Eric Dumazet <edumazet@google.com>
>>> Signed-off-by: Clément Lecigne <clecigne@google.com>
>>
>> Hi Clement,
>>
>> Do you have a reproducer for mentioned issue or is it only a fix from
>> theoretical POV?
>>
>> To be clear, we were addressing headroom issues in this series:
>> https://lore.kernel.org/bpf/20260402154958.562179-1-maciej.fijalkowski@intel.com/
>>
>> so I wanted to ask if you are able to have this malformed setup for
>> 2k chunk size. That series should not allow for that.
>
> I didn't manage to build a malformed setup and only used a LKM to reproduce
> the issue artificially.
Note that we don't accept patches addressing issue for OoT modules. I
read you reply as the critical setup can't be obtained with the vanilla
tree.
Please clarify otherwise.
/P
^ permalink raw reply
* Re: [PATCH] net: stmmac: recalibrate CBS idle slope when EST is enabled
From: Andrew Lunn @ 2026-07-01 14:54 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: netdev, kuba, davem, edumazet, pabeni, rmk+kernel,
maxime.chevallier
In-Reply-To: <20260701053244.17172-1-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Tue, Jun 30, 2026 at 10:32:44PM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
Hi Nazim
Please take a read of
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
It would be good to get the Subject line correct, and there are maybe
a few other things in there you currently don't know.
> + /* If EST is not enabled, no need to recalibrate idle slope */
> + if (!priv->est)
> + goto config_cbs;
> + if (!priv->est->enable)
> + goto config_cbs;
> +
> + cycle_time_ns = (priv->est->ctr[1] * NSEC_PER_SEC) +
> + priv->est->ctr[0];
> + if (!cycle_time_ns)
> + goto config_cbs;
The use of goto like this suggests it is time to refactor this code
into some helpers, so making the structure clearer. Otherwise this is
going to turning into spaghetti.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH 1/9] ax88179_178a: Fix endianness of pause watermark register
From: Andrew Lunn @ 2026-07-01 14:57 UTC (permalink / raw)
To: Birger Koblitz
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <20260701-ax88179a-v1-1-13685df67515@birger-koblitz.de>
On Wed, Jul 01, 2026 at 07:42:47AM +0200, Birger Koblitz wrote:
> The 16-bit pause watermark register is little endian as
> described in the ASIX 4.1.0 out-of-tree driver. Correct the
> register byte sequence but also swap the configuration values
> used in the code in order to keep the current behaviour.
>
> The endianness is relevant for 16-bit writes to the register.
Is this a Fix which should be back ported in stable?
Andrew
^ permalink raw reply
* Re: [PATCH 2/9] ax88179_178a: Add HW support for AX179A-based chips
From: Andrew Lunn @ 2026-07-01 15:05 UTC (permalink / raw)
To: Birger Koblitz
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <20260701-ax88179a-v1-2-13685df67515@birger-koblitz.de>
> #include <linux/usb/usbnet.h>
> #include <uapi/linux/mdio.h>
> #include <linux/mdio.h>
> +#include <linux/if_vlan.h>
Does this patch require this header?
> @@ -414,7 +570,6 @@ static int ax88179_suspend(struct usb_interface *intf, pm_message_t message)
>
> usbnet_suspend(intf, message);
>
> - /* Enable WoL */
> if (priv->wolopts) {
Please try to avoid changes like this.
> /* Force bulk-in zero length */
> ax88179_read_cmd(dev, AX_ACCESS_MAC, AX_PHYPWR_RSTCTL,
> - 2, 2, &tmp16);
> + 2, 2, &tmp16);
>
> tmp16 |= AX_PHYPWR_RSTCTL_BZ | AX_PHYPWR_RSTCTL_IPRL;
> ax88179_write_cmd(dev, AX_ACCESS_MAC, AX_PHYPWR_RSTCTL,
> - 2, 2, &tmp16);
> + 2, 2, &tmp16);
Please put white space changes in another patch.
> + /* Initialize MII structure */
> + dev->mii.dev = dev->net;
> + dev->mii.mdio_read = ax88179_mdio_read;
> + dev->mii.mdio_write = ax88179_mdio_write;
> + dev->mii.phy_id_mask = 0xff;
> + dev->mii.reg_num_mask = 0xff;
> + dev->mii.phy_id = 0x03;
If this device is going to have a long term future, it really should
move to phylink.
Andrew
^ permalink raw reply
* Re: [PATCH v2 02/19] driver core: platform: provide platform_device_set_of_node()
From: Manuel Ebner @ 2026-07-01 15:05 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-kernel, netdev, linux-arm-msm, linux-sound, driver-core,
devicetree, linuxppc-dev, linux-i2c, iommu, linux-pm, imx,
linux-arm-kernel, intel-xe, dri-devel, linux-usb, linux-mips,
platform-driver-x86, Bartosz Golaszewski, Lee Jones,
Thierry Reding, Sebastian Hesselbarth, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Srinivas Kandagatla, Greg Kroah-Hartman, Vinod Koul,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring, Saravana Kannan,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Andy Shevchenko,
Joerg Roedel, Will Deacon, Robin Murphy, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Ulf Hansson, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Matthew Brost, Thomas Hellström, Rodrigo Vivi,
David Airlie, Simona Vetter, Peter Chen, Paul Cercueil, Bin Liu,
Philipp Zabel, Maximilian Luz, Hans de Goede, Ilpo Järvinen,
Krzysztof Kozlowski, Benjamin Herrenschmidt
In-Reply-To: <CAMRc=MdQURjypSn+QjSDJfEiOMC8bbEZmZLgjpt=EquAM1Q1pw@mail.gmail.com>
On Tue, 2026-06-30 at 09:22 -0400, Bartosz Golaszewski wrote:
> On Tue, 30 Jun 2026 13:37:54 +0200, Manuel Ebner <manuelebner@mailbox.org> said:
> > On Mon, 2026-06-29 at 11:12 +0200, Bartosz Golaszewski wrote:
> > > [...]
> > >
> > > +/**
> > > + * platform_device_set_of_node - assign an OF node to device
> > > + * @pdev: platform device to add the node for
> > > + * @np: new device node
> > > + *
> > > + * Assign an OF node to this platform device. Internally keep track of the
> > > + * reference count. Devices created with platform_device_alloc() must use this
> > > + * function instead of assigning the node manually.
> >
> > Doesn't it make sense to add a remark to the kernel doc of platform_device_alloc()?
> >
> > Thanks
> > Manuel
> >
> > > [...]
> >
>
> Sure, will do in the next iteration.
then you can add
Reviewed-by: Manuel Ebner <manuelebner@mailbox.org>
Manuel
>
> Bart
^ permalink raw reply
* Re: [PATCH] net: fman: guard IRQ handlers against pre-init interrupt
From: Paolo Abeni @ 2026-07-01 15:06 UTC (permalink / raw)
To: ZhaoJinming, horms, andrew, madalin.bucur
Cc: andrew+netdev, davem, edumazet, kuba, linux-kernel, netdev,
sean.anderson
In-Reply-To: <20260629084529.3709393-1-zhaojinming@uniontech.com>
On 6/29/26 10:45 AM, ZhaoJinming wrote:
> read_dts_node() registers shared interrupt handlers via
> devm_request_irq() with fman as the dev_id, passing it to fman_irq()
> and fman_err_irq(). At registration time, fman is only partially
> initialized -- kzalloc_obj() zero-initializes all fields, so
> fman->cfg and fman->fpm_regs are NULL.
>
> The handlers guard against incomplete initialization via:
>
> if (!is_init_done(fman->cfg))
> return IRQ_NONE;
>
> However, is_init_done(NULL) returns true (intended to indicate that
> fman_init() has completed and cfg has been freed). This means when
> cfg is NULL before fman_config() allocates it, the guard does not
> take effect:
>
> is_init_done(NULL) -> returns true
> !true -> false
> guard skipped -> proceeds to dereference NULL fpm_regs
>
> If another device on the same shared IRQ line fires during the window
> between devm_request_irq() and fman_init(), the handler accesses
> NULL fman->fpm_regs via ioread32be(), causing a crash. The window
> includes of_platform_populate() which can be slow.
>
> Add an irq_ready flag to struct fman that is set to true only after
> fman_init() completes in fman_probe(). Check this flag at the start
> of fman_irq() and fman_err_irq() before any register access.
>
> Use READ_ONCE()/WRITE_ONCE() for the flag accesses since it is a
> cross-context shared variable written in process context and read
> in interrupt context.
>
> This issue was identified in code review during the discussion of a
> separate IRQF_SHARED UAF fix patch:
> https://lore.kernel.org/netdev/20260626162323.GE1310988@horms.kernel.org/
>
> Signed-off-by: ZhaoJinming <zhaojinming@uniontech.com>
> ---
> drivers/net/ethernet/freescale/fman/fman.c | 5 +++++
> drivers/net/ethernet/freescale/fman/fman.h | 1 +
> 2 files changed, 6 insertions(+)
>
> diff --git a/drivers/net/ethernet/freescale/fman/fman.c b/drivers/net/ethernet/freescale/fman/fman.c
> index 013273a2de32..f14cb02d85a4 100644
> --- a/drivers/net/ethernet/freescale/fman/fman.c
> +++ b/drivers/net/ethernet/freescale/fman/fman.c
> @@ -2510,6 +2510,8 @@ static irqreturn_t fman_err_irq(int irq, void *handle)
> struct fman_fpm_regs __iomem *fpm_rg;
> irqreturn_t single_ret, ret = IRQ_NONE;
>
> + if (!READ_ONCE(fman->irq_ready))
> + return IRQ_NONE;
Sashiko noted that on weakly ordered arch this could not be enough:
https://sashiko.dev/#/patchset/20260629084529.3709393-1-zhaojinming%40uniontech.com
Also I have the feeling this is papering over the real issue. Why
initializing the irq when the driver is not yet ready? Why don't move
IRQ initialization later?
/P
^ permalink raw reply
* Re: [PATCH bpf-next v5 1/3] bpf: Add BPF_FIB_LOOKUP_VLAN flag to bpf_fib_lookup() helper
From: David Ahern @ 2026-07-01 15:08 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, Avinash Duduskar, ast, daniel,
andrii
Cc: eddyz87, memxor, martin.lau, song, yonghong.song, jolsa, emil,
john.fastabend, sdf, davem, edumazet, kuba, pabeni, horms, shuah,
hawk, yatsenko, leon.hwang, kpsingh, a.s.protopopov, ameryhung,
rongtao, eyal.birger, bpf, netdev, linux-kernel, linux-kselftest
In-Reply-To: <87y0fv0y79.fsf@toke.dk>
On 7/1/26 5:02 AM, Toke Høiland-Jørgensen wrote:
> David Ahern <dsahern@kernel.org> writes:
>> Seems to me the fib_lookup for xdp needs to return the bottom device,
>> not the vlan device, for forwarding to work. That's why I added the
>> fields to the struct. That allows the program to push the vlan header if
>> required. My preference (dream?) was that Tx path had support to tell
>> the redirect the vlan and h/w added it on send.
>
> Sure, returning the bottom device index with the VLAN tag makes sense,
> and that's basically what this series does (but bails out on stacked
> VLANs). However, that's not what the helper does today, which is why the
> flag is there, to opt-in to the new behaviour. I don't think we can just
> change the ifindex without breaking existing applications (as noted
> up-thread).
I do not see it as breaking existing programs which is why I chimed in
on the thread.
>
>> But really, once stacked devices come into play, I just wanted to make
>> sure thought is given to different use cases. As you know the lookup
>> struct if hard bound to 64B and it is trying to cover a lot of use cases.
>
> Agreed, I don't think we can handle stacked devices in this helper. But
> we could split it out into a new one. Something like:
>
> struct lower_device_info {
> enum device_type type;
> struct {
> __be16 h_vlan_proto;
> __be16 h_vlan_TCI;
> } vlan;
> /* add other types here */
> };
>
> int xdp_get_lower_device(int ifindex, struct lower_device_info *info);
>
> called like:
>
> int xdp_program(struct xdp_md *ctx)
> {
> struct lower_device_info dev_info = {};
> int ifindex, ret;
>
> ifindex = find_destination(ctx); /* does fib lookup, or something else */
>
> while ((ret = xdp_get_lower_device_info(ifindex, &dev_info)) > 0) {
> if (dev_info.type == VLAN) {
> push_vlan_tag(ctx, &dev_info.vlan);
> ifindex = ret;
> } else {
> return XDP_PASS; /* we only handle VLAN devices */
> }
> }
>
> return bpf_redirect(ifindex, 0);
> }
>
>
> With a helper like this, we obviously don't strictly speaking need to
> change the fib lookup helper at all. However, for the single-tagged VLAN
> case, I think supporting it directly in the fib lookup could still have
> value, as an optimisation: it saves an extra call for resolving the
> ifindex, and the fields are already there. So I think my preference
> would be to merge this series as-is, and then follow up with a new kfunc
> to handle the stacked case. But we could also just drop this series and
> go straight to the new kfunc.
>
> WDYT?
no preference. I only chimed in because of the added flag to the uapi
which I do not see as needed. If the consensus is that it is in fact
needed, all good then.
^ permalink raw reply
* Re: [PATCH 5/9] ax88179_178a: Add support for ethtool pause parameter configuration
From: Andrew Lunn @ 2026-07-01 15:08 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Birger Koblitz, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-usb, netdev, linux-kernel
In-Reply-To: <587499ee-d87e-4056-8d2a-8fda2ef3f0f1@bootlin.com>
> > +static void ax88179a_get_pauseparam(struct net_device *net, struct ethtool_pauseparam *pause)
> > +{
> > + struct usbnet *dev = netdev_priv(net);
> > + struct ax88179_data *data;
> > + u16 bmcr, lcladv, rmtadv;
> > + u8 cap;
> > +
> > + data = dev->driver_priv;
> > +
> > + if (data->chip_version < AX_VERSION_AX88179A)
> > + return;
> > +
> > + bmcr = ax88179_mdio_read(net, dev->mii.phy_id, MII_BMCR);
> > + lcladv = ax88179_mdio_read(net, dev->mii.phy_id, MII_ADVERTISE);
> > + rmtadv = ax88179_mdio_read(net, dev->mii.phy_id, MII_LPA);
> > +
> > + if (!(bmcr & BMCR_ANENABLE)) {
> > + pause->autoneg = 0;
> > + pause->rx_pause = 0;
> > + pause->tx_pause = 0;
> The best way to have this correct is to use phylink, but for that you'd need to
> have a proper PHY driver instead of using the mii_ API here.
I said the some to one of the other patches.
Do we know what PHYs are being used? Can register 2 and 3 be read to
get the PHY IDs?
Andrew
^ permalink raw reply
* Re: [PATCH net v3] net/smc: fix out-of-bounds read when sk_user_data holds a sk_psock
From: Paolo Abeni @ 2026-07-01 15:27 UTC (permalink / raw)
To: Sechang Lim, D . Wythe, Dust Li, Sidraya Jayagond, Wenjia Zhang,
David S . Miller, Eric Dumazet, Jakub Kicinski
Cc: Jiayuan Chen, Mahanta Jambigi, Tony Lu, Wen Gu, Simon Horman,
Karsten Graul, Guvenc Gulce, Ursula Braun, linux-rdma, linux-s390,
netdev, linux-kernel, bpf
In-Reply-To: <20260629095140.679754-1-rhkrqnwk98@gmail.com>
On 6/29/26 11:51 AM, Sechang Lim wrote:
> A passive-open child inherits the listener's smc_clcsock_data_ready().
> sk_clone_lock() clears its sk_user_data to NULL because the listener tagged
> it SK_USER_DATA_NOCOPY. Until accept restores the callback, a BPF sock_ops
> program can add the established child to a sockmap, and sk_psock_init()
> installs a sk_psock into the NULL sk_user_data. The inherited callback then
> reads it back through smc_clcsock_user_data(), which strips only NOCOPY,
> takes the sk_psock for an smc_sock, and dereferences a clcsk_* field past
> its end:
>
> BUG: KASAN: slab-out-of-bounds in smc_clcsock_data_ready+0x84/0x200 net/smc/af_smc.c:2637
> Read of size 8 at addr ffff8880013b8674 by task syz.6.12484/67930
> <IRQ>
> smc_clcsock_data_ready+0x84/0x200 net/smc/af_smc.c:2637
> tcp_urg+0x24d/0x360 net/ipv4/tcp_input.c:6264
> tcp_rcv_state_process+0x280d/0x4940 net/ipv4/tcp_input.c:7336
> tcp_child_process+0x371/0xa50 net/ipv4/tcp_minisocks.c:1002
> tcp_v4_rcv+0x1eaa/0x2a00 net/ipv4/tcp_ipv4.c:2186
> [...]
> </IRQ>
>
> Allocated by task 67930:
> sk_psock_init+0x142/0x740 net/core/skmsg.c:766
> sock_hash_update_common+0xd3/0x990 net/core/sock_map.c:1010
> bpf_sock_hash_update+0x114/0x170 net/core/sock_map.c:1229
> __cgroup_bpf_run_filter_sock_ops+0x74/0xa0 kernel/bpf/cgroup.c:1727
> tcp_init_transfer+0x1085/0x1100 net/ipv4/tcp_input.c:6693
> [...]
>
> Resolve the conflict on the write path. Reserve the child's sk_user_data
> with a NULL pointer tagged SK_USER_DATA_NOCOPY so sk_psock_init() returns
> -EBUSY, and release it at accept. smc_clcsock_user_data() still strips the
> tag to NULL, so the inherited callback stays a no-op.
>
> Fixes: a60a2b1e0af1 ("net/smc: reduce active tcp_listen workers")
> Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
> ---
> v3:
> - reserve sk_user_data on the write path instead of the read-side check (D. Wythe)
>
> v2:
> - https://lore.kernel.org/netdev/20260619150342.3626224-1-rhkrqnwk98@gmail.com/
>
> v1:
> - https://lore.kernel.org/netdev/20260614120931.4041687-1-rhkrqnwk98@gmail.com/
>
> net/smc/af_smc.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index b5db69073e20..78f162344fe3 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -154,7 +154,11 @@ static struct sock *smc_tcp_syn_recv_sock(const struct sock *sk,
> own_req, opt_child_init);
> /* child must not inherit smc or its ops */
> if (child) {
> - rcu_assign_sk_user_data(child, NULL);
> + /* reserve sk_user_data so sockmap cannot claim the slot */
> + write_lock_bh(&child->sk_callback_lock);
> + __rcu_assign_sk_user_data_with_flags(child, NULL,
> + SK_USER_DATA_NOCOPY);
> + write_unlock_bh(&child->sk_callback_lock);
>
> /* v4-mapped sockets don't inherit parent ops. Don't restore. */
> if (inet_csk(child)->icsk_af_ops == inet_csk(sk)->icsk_af_ops)
> @@ -1773,6 +1777,7 @@ static int smc_clcsock_accept(struct smc_sock *lsmc, struct smc_sock **new_smc)
> /* new clcsock has inherited the smc listen-specific sk_data_ready
> * function; switch it back to the original sk_data_ready function
> */
> + write_lock_bh(&new_clcsock->sk->sk_callback_lock);
> new_clcsock->sk->sk_data_ready = lsmc->clcsk_data_ready;
>
> /* if new clcsock has also inherited the fallback-specific callback
> @@ -1786,6 +1791,9 @@ static int smc_clcsock_accept(struct smc_sock *lsmc, struct smc_sock **new_smc)
> if (lsmc->clcsk_error_report)
> new_clcsock->sk->sk_error_report = lsmc->clcsk_error_report;
> }
> + /* release the slot reserved in smc_tcp_syn_recv_sock() */
> + rcu_assign_sk_user_data(new_clcsock->sk, NULL);
> + write_unlock_bh(&new_clcsock->sk->sk_callback_lock);
Sashiko reports that this still cause problem on fallback.
@Wythe, I understand from previous discussion that you would prefer to
address such issues separately (and thus you are fine with the patch in
the current form). Could you please confirm?
/P
>
> (*new_smc)->clcsock = new_clcsock;
> out:
^ permalink raw reply
* Re: [PATCH] qede: Prevent possible snprintf() truncation by bounding %s string format
From: Breno Leitao @ 2026-07-01 15:27 UTC (permalink / raw)
To: Baran Tuna
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, open list:QLOGIC QL4xxx ETHERNET DRIVER, open list
In-Reply-To: <20260701144713.197557-1-barant@fastmail.com>
On Wed, Jul 01, 2026 at 05:47:11PM +0300, Baran Tuna wrote:
> GCC warning shows that formatted strings may
> exceed the fixed-size destination buffers.
>
> Bounding the %s string format
> so the maximum formatted output always fits.
>
> This eliminates the -Wformat-truncation warning.
>
> Signed-off-by: Baran Tuna <barant@fastmail.com>
> ---
> drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
> index 647f30a16a94..5428f53150a0 100644
> --- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
> +++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
> @@ -618,10 +618,10 @@ static void qede_get_drvinfo(struct net_device *ndev,
> if ((strlen(storm) + strlen("[storm]")) <
> sizeof(info->version))
> snprintf(info->version, sizeof(info->version),
> - "[storm %s]", storm);
> + "[storm %.16s]", storm);
Where is this 16 coming from?
Also, isn't the if above checking for no overflow? I.e,
we got here only if strlen(storm) + strlen("[storm]") < sizeof(info->version))
For whoever else is reviwewing this, this the buffers:
#define ETHTOOL_FWVERS_LEN 32
char version[32];
char storm[ETHTOOL_FWVERS_LEN];
^ permalink raw reply
* [PATCH net v2] nfc: st-nci: align frame buffers for typed length load
From: Runyu Xiao @ 2026-07-01 15:22 UTC (permalink / raw)
To: David Heidelberg
Cc: Krzysztof Kozlowski, Christophe Ricard, Samuel Ortiz, netdev,
linux-kernel, stable, Runyu Xiao, Jianhao Xu
The ST NCI I2C and SPI transports parse a frame length from bytes
received from the controller. Both paths read the frame header into a
local u8 buffer and then cast buf + 2 to __be16 * before converting it
from big endian.
Align the local frame buffers to 2 bytes so that buf + 2 is also
2-byte aligned before the __be16 load. This keeps the existing parser
logic while making the alignment requirement explicit for the typed
length access.
This issue was detected by our static analysis tool and confirmed by
manual audit. UBSAN alignment validation of the same access shape,
be16_to_cpu(*(__be16 *)(buf + 2)), reports a misaligned-access load of
type '__be16' when the byte buffer does not provide that alignment.
Fixes: 35630df68d60 ("NFC: st21nfcb: Add driver for STMicroelectronics ST21NFCB NFC chip")
Fixes: 2bc4d4f8c8f3 ("nfc: st-nci: Add spi phy support for st21nfcb")
Cc: stable@vger.kernel.org
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
Changes in v2:
- Follow David's feedback and align the local I2C/SPI frame buffers
instead of switching the length load to get_unaligned_be16().
- Use the original st21nfcb I2C driver commit in the I2C Fixes tag.
drivers/nfc/st-nci/i2c.c | 2 +-
drivers/nfc/st-nci/spi.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/nfc/st-nci/i2c.c b/drivers/nfc/st-nci/i2c.c
index 9ae839a6f5cc..b7e208dd5a18 100644
--- a/drivers/nfc/st-nci/i2c.c
+++ b/drivers/nfc/st-nci/i2c.c
@@ -108,7 +108,7 @@ static int st_nci_i2c_read(struct st_nci_i2c_phy *phy,
{
int r;
u8 len;
- u8 buf[ST_NCI_I2C_MAX_SIZE];
+ u8 buf[ST_NCI_I2C_MAX_SIZE] __aligned(2);
struct i2c_client *client = phy->i2c_dev;
r = i2c_master_recv(client, buf, ST_NCI_I2C_MIN_SIZE);
diff --git a/drivers/nfc/st-nci/spi.c b/drivers/nfc/st-nci/spi.c
index 169eacc0a32a..74b4ac39f65b 100644
--- a/drivers/nfc/st-nci/spi.c
+++ b/drivers/nfc/st-nci/spi.c
@@ -119,7 +119,7 @@ static int st_nci_spi_read(struct st_nci_spi_phy *phy,
{
int r;
u8 len;
- u8 buf[ST_NCI_SPI_MAX_SIZE];
+ u8 buf[ST_NCI_SPI_MAX_SIZE] __aligned(2);
struct spi_device *dev = phy->spi_dev;
struct spi_transfer spi_xfer = {
.rx_buf = buf,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 0/2] sched: Introduce and use deferred WARNs in sched
From: Sebastian Andrzej Siewior @ 2026-07-01 15:31 UTC (permalink / raw)
To: Peter Zijlstra, Vlad Poenaru
Cc: linux-arch, linux-kernel, sched-ext, netdev, David S . Miller,
Andrea Righi, Andrew Morton, Arnd Bergmann, Ben Segall,
Breno Leitao, Changwoo Min, David Vernet, Dietmar Eggemann,
Eric Dumazet, Ingo Molnar, Jakub Kicinski, John Ogness,
Juri Lelli, K Prateek Nayak, Paolo Abeni, Petr Mladek,
Sergey Senozhatsky, Simon Horman, Steven Rostedt, Tejun Heo,
Vincent Guittot
In-Reply-To: <20260624093329.GZ48970@noisy.programming.kicks-ass.net>
On 2026-06-24 11:33:29 [+0200], Peter Zijlstra wrote:
> So I really don't see why we should do this. This has been a 'problem'
> forever, and printk() is actually being fixed.
I just prepared v2 and apparently missed this. So let me postpone it…
A user triggered a warning under the rq lock so it is not a theoretical
problem which happens during development. printk is fixed it is just the
console driver that are lagging behind. The 8250 is probably the role
model that everyone is waiting for and once it becomes a NBCON it is no
longer affected by the "deferred" requirement here.
The problem was reproduced on netconsole which is a NBCON, too.
So we just ignore the problem because it is well known? I was hoping for
some duct tape until we have NBCON and threaded-legacy consoles.
Vlad: Were you doing something special to trigger the warning in
question or did it randomly trigger?
Sebastian
^ permalink raw reply
* Re: [PATCH net 2/3] net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains
From: Jamal Hadi Salim @ 2026-07-01 15:35 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Jakub Kicinski, Paolo Abeni, Sebastian Andrzej Siewior,
Andrii Nakryiko, Kumar Kartikeya Dwivedi, bpf,
Linux Kernel Network Developers, Victor Nogueira
In-Reply-To: <d9fce17f-851e-4cb0-9d78-2ac2cadfda81@iogearbox.net>
On Tue, Jun 30, 2026 at 11:23 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 6/30/26 5:16 PM, Jamal Hadi Salim wrote:
> > On Tue, Jun 30, 2026 at 8:33 AM Daniel Borkmann <daniel@iogearbox.net> wrote:
> >> From: Jamal Hadi Salim <jhs@mojatatu.com>
> >>
> >> When a TC filter attached to a qdisc filter chain returns
> >> TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an
> >> act_bpf action), the redirect was silently lost i.e no qdisc classify
> >> function handled TC_ACT_REDIRECT, so the packet fell through the
> >> switch and was enqueued normally instead of being redirected.
> >>
> >> This has been broken since bpf_redirect() was introduced for TC in
> >> commit 27b29f63058d ("bpf: add bpf_redirect() helper"). We got lucky
> >> for a long time because bpf_net_context was a per-CPU variable that
> >> was always available.
> >>
> >> commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct
> >> on PREEMPT_RT.") turned bpf_net_context into a task_struct member that
> >> is only set up by explicit callers. Without a caller setting it up,
> >> bpf_redirect() itself crashes with a NULL pointer dereference in
> >> bpf_net_ctx_get_ri(). However, even with bpf_net_context available,
> >> TC_ACT_REDIRECT from qdisc filter chains cannot be honored without
> >> adding skb_do_redirect() calls to every qdisc classify function, which
> >> would require changes across net/sched/. Isolate it to ebpf core where
> >> it belongs.
> >>
> >> Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a
> >> wrapper around tcf_classify() for use by qdisc classify functions and
> >> tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT,
> >> the wrapper converts it to TC_ACT_SHOT, dropping the packet rather
> >> than letting it continue silently. Dropping is preferred over
> >> letting the packet through because the user immediately sees packet
> >> loss. Silently passing the packet through would hide the problem and
> >> leave the user wondering why their redirect is not working.
> >>
> >> The clsact fast path, tc_run() continues to call tcf_classify() directly
> >> and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by
> >> sch_handle_egress/ingress() calling skb_do_redirect() as before.
> >>
> >> Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper")
> >> Fixes: 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.")
> >> Tested-by: Victor Nogueira <victor@mojatatu.com>
> >> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> >> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> >> ---
> >> include/net/pkt_cls.h | 14 +++++++++++++-
> >> net/sched/cls_api.c | 4 +---
> >> net/sched/sch_cake.c | 2 +-
> >> net/sched/sch_drr.c | 2 +-
> >> net/sched/sch_dualpi2.c | 2 +-
> >> net/sched/sch_ets.c | 2 +-
> >> net/sched/sch_fq_codel.c | 2 +-
> >> net/sched/sch_fq_pie.c | 2 +-
> >> net/sched/sch_hfsc.c | 2 +-
> >> net/sched/sch_htb.c | 2 +-
> >> net/sched/sch_multiq.c | 2 +-
> >> net/sched/sch_prio.c | 2 +-
> >> net/sched/sch_qfq.c | 2 +-
> >> net/sched/sch_sfb.c | 2 +-
> >> net/sched/sch_sfq.c | 2 +-
> >> 15 files changed, 27 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
> >> index 3bd08d7f39c1..5f5cb36439fe 100644
> >> --- a/include/net/pkt_cls.h
> >> +++ b/include/net/pkt_cls.h
> >> @@ -156,8 +156,20 @@ static inline int tcf_classify(struct sk_buff *skb,
> >> {
> >> return TC_ACT_UNSPEC;
> >> }
> >> -
> >> #endif
> >> +static inline int tcf_classify_qdisc(struct sk_buff *skb,
> >> + const struct tcf_proto *tp,
> >> + struct tcf_result *res, bool compat_mode)
> >> +{
> >> + int ret = tcf_classify(skb, NULL, tp, res, compat_mode);
> >> +
> >> + /* TC_ACT_REDIRECT from qdisc filter chains is not supported.
> >> + * Use BPF via tcx or mirred redirect instead.
> >> + */
> >> + if (unlikely(ret == TC_ACT_REDIRECT))
> >> + ret = TC_ACT_SHOT;
> >> + return ret;
> >> +}
> >
> > Why did you remove the warning?
> > A lesser issue is that you introduced a space above #endif
>
> I don't think we need to put out an extra warn to spam the log, this
> can be easily traced either via bpftrace or qdisc stats etc; plus the
> guidance to eBPF with clsact is also obsolete. Given noone has run
> into this the last 10y, I don't think it really matters tbh.
It's a bit entitled for you to change someone else's patch to fit your
philosophy without a mention.
It's only one message per qdisc. But fine, let's keep it that way.
Sashiko is hallucinating on TC_ACT_CONSUMED for patch 1. Let's ignore it.
cheers,
jamal
> Thanks,
> Daniel
^ permalink raw reply
* [PATCH net-next 0/2] sit: prepare for RTNL-less link dumping
From: Eric Dumazet @ 2026-07-01 15:51 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Kuniyuki Iwashima, Ido Schimmel, David Ahern,
netdev, eric.dumazet, Eric Dumazet
This series prepares the SIT tunnel driver for RTNL-less link info dumping.
To do so, we need to ensure that configuration reads in ipip6_fill_info()
can run safely concurrently with configuration updates
(via netlink changelink or ioctls).
First patch fixes a long-standing bug in the shared
ip_tunnel_encap_setup() helper (used by SIT and other IPv4 tunnels),
which cleared the encapsulation configuration even if the setup failed,
and adds WRITE_ONCE() annotations to protect concurrent readers.
Second patch updates SIT's fill_info() to use READ_ONCE()
for lockless reads, and updates the write paths to use WRITE_ONCE().
Eric Dumazet (2):
ip_tunnel: use WRITE_ONCE in ip_tunnel_encap_setup
sit: no longer rely on RTNL in ipip6_fill_info()
net/ipv4/ip_tunnel.c | 14 ++++-----
net/ipv6/sit.c | 70 +++++++++++++++++++++++++-------------------
2 files changed, 46 insertions(+), 38 deletions(-)
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply
* [PATCH net-next 1/2] ip_tunnel: use WRITE_ONCE in ip_tunnel_encap_setup
From: Eric Dumazet @ 2026-07-01 15:51 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Kuniyuki Iwashima, Ido Schimmel, David Ahern,
netdev, eric.dumazet, Eric Dumazet
In-Reply-To: <20260701155135.3962058-1-edumazet@google.com>
Update ip_tunnel_encap_setup() to use WRITE_ONCE() when writing
to encap fields (type, sport, dport, flags) and hlen fields.
This ensures that concurrent lockless readers (like fill_info)
do not see torn writes.
Also remove the unsafe memset() on t->encap which could cause
concurrent readers to transiently see zeroed fields.
Removing it also fixes a bug where t->encap was left cleared
even if ip_encap_hlen() failed, resulting in partial configuration.
Fixes: 56328486539d ("net: Changes to ip_tunnel to support foo-over-udp encapsulation")
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/ip_tunnel.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 9d114bd575f928b0ab46ef3007e456692d82b497..f7bbdd1bd323b1973ec1ea1d93f0ed6ab703bcd3 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -491,19 +491,17 @@ int ip_tunnel_encap_setup(struct ip_tunnel *t,
{
int hlen;
- memset(&t->encap, 0, sizeof(t->encap));
-
hlen = ip_encap_hlen(ipencap);
if (hlen < 0)
return hlen;
- t->encap.type = ipencap->type;
- t->encap.sport = ipencap->sport;
- t->encap.dport = ipencap->dport;
- t->encap.flags = ipencap->flags;
+ WRITE_ONCE(t->encap.type, ipencap->type);
+ WRITE_ONCE(t->encap.sport, ipencap->sport);
+ WRITE_ONCE(t->encap.dport, ipencap->dport);
+ WRITE_ONCE(t->encap.flags, ipencap->flags);
- t->encap_hlen = hlen;
- t->hlen = t->encap_hlen + t->tun_hlen;
+ WRITE_ONCE(t->encap_hlen, hlen);
+ WRITE_ONCE(t->hlen, hlen + t->tun_hlen);
return 0;
}
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH net-next 2/2] sit: no longer rely on RTNL in ipip6_fill_info()
From: Eric Dumazet @ 2026-07-01 15:51 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Kuniyuki Iwashima, Ido Schimmel, David Ahern,
netdev, eric.dumazet, Eric Dumazet
In-Reply-To: <20260701155135.3962058-1-edumazet@google.com>
Update ipip6_fill_info() to read configuration fields (link, ttl, tos,
proto, i_flags, fwmark, 6rd prefix, encap type/sport/dport/flags)
locklessly using READ_ONCE().
Annotate the bitmap reads for i_flags by copying the first element
atomically using READ_ONCE() into a local variable, as the whole
bitmap fits in one unsigned long.
This allows ipip6_fill_info() to run safely without RTNL.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv6/sit.c | 70 ++++++++++++++++++++++++++++----------------------
1 file changed, 40 insertions(+), 30 deletions(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index a38b24fb838424b6d3cb063d77aa85cf719ce6c5..c7abbb09bfd3dfada6fc1e1682ac42acb7248ad9 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1143,17 +1143,17 @@ static void ipip6_tunnel_update(struct ip_tunnel *t,
ipip6_tunnel_unlink(sitn, t);
synchronize_net();
- t->parms.iph.saddr = p->iph.saddr;
- t->parms.iph.daddr = p->iph.daddr;
+ WRITE_ONCE(t->parms.iph.saddr, p->iph.saddr);
+ WRITE_ONCE(t->parms.iph.daddr, p->iph.daddr);
__dev_addr_set(t->dev, &p->iph.saddr, 4);
memcpy(t->dev->broadcast, &p->iph.daddr, 4);
ipip6_tunnel_link(sitn, t);
- t->parms.iph.ttl = p->iph.ttl;
- t->parms.iph.tos = p->iph.tos;
- t->parms.iph.frag_off = p->iph.frag_off;
- if (t->parms.link != p->link || t->fwmark != fwmark) {
- t->parms.link = p->link;
- t->fwmark = fwmark;
+ WRITE_ONCE(t->parms.iph.ttl, p->iph.ttl);
+ WRITE_ONCE(t->parms.iph.tos, p->iph.tos);
+ WRITE_ONCE(t->parms.iph.frag_off, p->iph.frag_off);
+ if (READ_ONCE(t->parms.link) != p->link || READ_ONCE(t->fwmark) != fwmark) {
+ WRITE_ONCE(t->parms.link, p->link);
+ WRITE_ONCE(t->fwmark, fwmark);
ipip6_tunnel_bind_dev(t->dev);
}
dst_cache_reset(&t->dst_cache);
@@ -1184,9 +1184,9 @@ static int ipip6_tunnel_update_6rd(struct ip_tunnel *t,
return -EINVAL;
t->ip6rd.prefix = prefix;
- t->ip6rd.relay_prefix = relay_prefix;
- t->ip6rd.prefixlen = ip6rd->prefixlen;
- t->ip6rd.relay_prefixlen = ip6rd->relay_prefixlen;
+ WRITE_ONCE(t->ip6rd.relay_prefix, relay_prefix);
+ WRITE_ONCE(t->ip6rd.prefixlen, ip6rd->prefixlen);
+ WRITE_ONCE(t->ip6rd.relay_prefixlen, ip6rd->relay_prefixlen);
dst_cache_reset(&t->dst_cache);
netdev_state_change(t->dev);
return 0;
@@ -1693,42 +1693,52 @@ static size_t ipip6_get_size(const struct net_device *dev)
static int ipip6_fill_info(struct sk_buff *skb, const struct net_device *dev)
{
- struct ip_tunnel *tunnel = netdev_priv(dev);
- struct ip_tunnel_parm_kern *parm = &tunnel->parms;
-
- if (nla_put_u32(skb, IFLA_IPTUN_LINK, parm->link) ||
- nla_put_in_addr(skb, IFLA_IPTUN_LOCAL, parm->iph.saddr) ||
- nla_put_in_addr(skb, IFLA_IPTUN_REMOTE, parm->iph.daddr) ||
- nla_put_u8(skb, IFLA_IPTUN_TTL, parm->iph.ttl) ||
- nla_put_u8(skb, IFLA_IPTUN_TOS, parm->iph.tos) ||
+ const struct ip_tunnel *tunnel = netdev_priv(dev);
+ const struct ip_tunnel_parm_kern *parm;
+ IP_TUNNEL_DECLARE_FLAGS(i_flags);
+ __be16 frag_off;
+ __be32 daddr;
+ __be32 saddr;
+
+ parm = &tunnel->parms;
+ i_flags[0] = READ_ONCE(parm->i_flags[0]);
+ frag_off = READ_ONCE(parm->iph.frag_off);
+ saddr = READ_ONCE(parm->iph.saddr);
+ daddr = READ_ONCE(parm->iph.daddr);
+
+ if (nla_put_u32(skb, IFLA_IPTUN_LINK, READ_ONCE(parm->link)) ||
+ nla_put_in_addr(skb, IFLA_IPTUN_LOCAL, saddr) ||
+ nla_put_in_addr(skb, IFLA_IPTUN_REMOTE, daddr) ||
+ nla_put_u8(skb, IFLA_IPTUN_TTL, READ_ONCE(parm->iph.ttl)) ||
+ nla_put_u8(skb, IFLA_IPTUN_TOS, READ_ONCE(parm->iph.tos)) ||
nla_put_u8(skb, IFLA_IPTUN_PMTUDISC,
- !!(parm->iph.frag_off & htons(IP_DF))) ||
- nla_put_u8(skb, IFLA_IPTUN_PROTO, parm->iph.protocol) ||
+ !!(frag_off & htons(IP_DF))) ||
+ nla_put_u8(skb, IFLA_IPTUN_PROTO, READ_ONCE(parm->iph.protocol)) ||
nla_put_be16(skb, IFLA_IPTUN_FLAGS,
- ip_tunnel_flags_to_be16(parm->i_flags)) ||
- nla_put_u32(skb, IFLA_IPTUN_FWMARK, tunnel->fwmark))
+ ip_tunnel_flags_to_be16(i_flags)) ||
+ nla_put_u32(skb, IFLA_IPTUN_FWMARK, READ_ONCE(tunnel->fwmark)))
goto nla_put_failure;
#ifdef CONFIG_IPV6_SIT_6RD
if (nla_put_in6_addr(skb, IFLA_IPTUN_6RD_PREFIX,
&tunnel->ip6rd.prefix) ||
nla_put_in_addr(skb, IFLA_IPTUN_6RD_RELAY_PREFIX,
- tunnel->ip6rd.relay_prefix) ||
+ READ_ONCE(tunnel->ip6rd.relay_prefix)) ||
nla_put_u16(skb, IFLA_IPTUN_6RD_PREFIXLEN,
- tunnel->ip6rd.prefixlen) ||
+ READ_ONCE(tunnel->ip6rd.prefixlen)) ||
nla_put_u16(skb, IFLA_IPTUN_6RD_RELAY_PREFIXLEN,
- tunnel->ip6rd.relay_prefixlen))
+ READ_ONCE(tunnel->ip6rd.relay_prefixlen)))
goto nla_put_failure;
#endif
if (nla_put_u16(skb, IFLA_IPTUN_ENCAP_TYPE,
- tunnel->encap.type) ||
+ READ_ONCE(tunnel->encap.type)) ||
nla_put_be16(skb, IFLA_IPTUN_ENCAP_SPORT,
- tunnel->encap.sport) ||
+ READ_ONCE(tunnel->encap.sport)) ||
nla_put_be16(skb, IFLA_IPTUN_ENCAP_DPORT,
- tunnel->encap.dport) ||
+ READ_ONCE(tunnel->encap.dport)) ||
nla_put_u16(skb, IFLA_IPTUN_ENCAP_FLAGS,
- tunnel->encap.flags))
+ READ_ONCE(tunnel->encap.flags)))
goto nla_put_failure;
return 0;
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH net-next v3 0/3] net: dsa: motorcomm: Add LED support
From: David Yang @ 2026-07-01 15:54 UTC (permalink / raw)
To: netdev
Cc: David Yang, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-kernel
v2: https://lore.kernel.org/r/20260629183137.541341-1-mmyangfl@gmail.com
- allocate LED structures only
- eliminate double locking
v1: https://lore.kernel.org/r/20260618202716.2166450-1-mmyangfl@gmail.com
- set up polarity correctly
- do not set up .brightness_get() to prevent dead lock
David Yang (3):
net: dsa: motorcomm: Move to subdirectory
net: dsa: motorcomm: Split SMI module
net: dsa: motorcomm: Add LED support
MAINTAINERS | 2 +-
drivers/net/dsa/Kconfig | 10 +-
drivers/net/dsa/Makefile | 2 +-
drivers/net/dsa/motorcomm/Kconfig | 17 +
drivers/net/dsa/motorcomm/Makefile | 5 +
.../net/dsa/{yt921x.c => motorcomm/chip.c} | 218 +------
.../net/dsa/{yt921x.h => motorcomm/chip.h} | 14 +-
drivers/net/dsa/motorcomm/leds.c | 586 ++++++++++++++++++
drivers/net/dsa/motorcomm/leds.h | 118 ++++
drivers/net/dsa/motorcomm/smi.c | 157 +++++
drivers/net/dsa/motorcomm/smi.h | 88 +++
11 files changed, 997 insertions(+), 220 deletions(-)
create mode 100644 drivers/net/dsa/motorcomm/Kconfig
create mode 100644 drivers/net/dsa/motorcomm/Makefile
rename drivers/net/dsa/{yt921x.c => motorcomm/chip.c} (96%)
rename drivers/net/dsa/{yt921x.h => motorcomm/chip.h} (99%)
create mode 100644 drivers/net/dsa/motorcomm/leds.c
create mode 100644 drivers/net/dsa/motorcomm/leds.h
create mode 100644 drivers/net/dsa/motorcomm/smi.c
create mode 100644 drivers/net/dsa/motorcomm/smi.h
--
2.53.0
^ 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