* Re: [PATCH net-next v4 1/9] net: dsa: add tag driver for LAN9645X
From: Jakub Kicinski @ 2026-05-06 1:45 UTC (permalink / raw)
To: jensemil.schulzostergaard
Cc: Jakub Kicinski, UNGLinuxDriver, andrew, olteanv, davem, edumazet,
pabeni, horms, robh, krzk+dt, conor+dt, woojung.huh, linux,
Steen.Hegelund, daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260430-dsa_lan9645x_switch_driver_base-v4-1-f1b6005fa8b7@microchip.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.
---
net: dsa: add tag driver for LAN9645X
Adds a DSA tag driver for Microchip LAN9645x switches operating with a
front port configured as an NPI CPU port. RX uses a 16-byte long prefix
plus a 28-byte internal frame header; TX uses only the IFH.
> diff --git a/net/dsa/tag_lan9645x.c b/net/dsa/tag_lan9645x.c
> new file mode 100644
> index 000000000000..81e7a78e0f81
> --- /dev/null
> +++ b/net/dsa/tag_lan9645x.c
[ ... ]
> +static struct sk_buff *lan9645x_rcv(struct sk_buff *skb,
> + struct net_device *ndev)
> +{
> + u32 src_port, qos_class, vlan_tci, tag_type, popcnt, etype_ofs;
> + struct dsa_port *dp;
> + u32 ifh_gap_len = 0;
> + u16 vlan_tpid;
> + u8 *ifh;
> +
> + /* DSA master already consumed DMAC,SMAC,ETYPE from long prefix. Go back
> + * to beginning of frame.
> + */
> + skb_push(skb, ETH_HLEN);
> +
> + if (unlikely(!pskb_may_pull(skb, LAN9645X_TOTAL_TAG_LEN)))
> + return NULL;
> +
> + /* IFH starts after our long prefix */
> + ifh = skb_pull(skb, LAN9645X_LONG_PREFIX_LEN);
[ ... ]
> + skb_pull(skb, LAN9645X_IFH_LEN);
> +
> + if (unlikely(!pskb_may_pull(skb, ifh_gap_len + ETH_HLEN)))
> + return NULL;
> +
> + skb_pull(skb, ifh_gap_len);
> + skb_reset_mac_header(skb);
> + skb_set_network_header(skb, ETH_HLEN);
> + skb_reset_mac_len(skb);
> +
> + /* Remove the long prefix + IFH + ifh_gap contribution from
> + * skb->csum so the stack sees a checksum consistent with the
> + * real Ethernet frame. skb->data currently points at the real
> + * MAC header.
> + */
> + skb_postpull_rcsum(skb,
> + skb->data - LAN9645X_TOTAL_TAG_LEN - ifh_gap_len,
> + LAN9645X_TOTAL_TAG_LEN + ifh_gap_len);
Does this skb_postpull_rcsum() call subtract the wrong region from
skb->csum for CHECKSUM_COMPLETE frames?
By the time lan9645x_rcv() is entered, the conduit's eth_type_trans()
has already pulled the first ETH_HLEN (14) bytes of the long prefix and
adjusted skb->csum accordingly, so skb->csum covers bytes starting at
offset 14 (the remaining 2 bytes of the long prefix plus IFH plus any
gap plus the real frame).
At the point of the skb_postpull_rcsum() call, skb->data points at the
real MAC header, i.e. at offset LAN9645X_TOTAL_TAG_LEN + ifh_gap_len
from the start of the originally-received frame. So
skb->data - LAN9645X_TOTAL_TAG_LEN - ifh_gap_len points at offset 0,
and the subtracted region is [0, LAN9645X_TOTAL_TAG_LEN + ifh_gap_len).
That region includes the first 14 bytes that eth_type_trans() already
removed from skb->csum, and it stops short of the real MAC header which
also needs to be removed. Shouldn't the subtracted region instead start
at what skb->data was on entry to rcv() (i.e. post-eth_type_trans) and
cover LAN9645X_TOTAL_TAG_LEN + ifh_gap_len bytes from there, so that it
matches what skb->csum actually covers?
For reference, tag_ocelot.c (cited in the commit message as the
architectural model) saves start = skb->data at function entry before
any skb_push()/skb_pull() manipulation:
net/dsa/tag_ocelot.c:ocelot_rcv() {
...
u8 *start = skb->data;
...
skb_push(skb, ETH_HLEN);
skb_pull(skb, OCELOT_SHORT_PREFIX_LEN);
...
}
and later passes that saved pointer to skb_postpull_rcsum() with the
total tag length, so the subtracted region exactly matches what the
NIC's csum_complete covers.
Would saving skb->data on entry (before the initial skb_push(ETH_HLEN))
and passing that as the start argument, with length
LAN9645X_TOTAL_TAG_LEN + ifh_gap_len, produce the correct result here
as well?
^ permalink raw reply
* Re: [PATCH v1 net-next 00/15] udp_tunnel: Speed up UDP tunnel device destruction (Part I)
From: Kuniyuki Iwashima @ 2026-05-06 1:43 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David S . Miller, Eric Dumazet, Paolo Abeni, Andrew Lunn,
Simon Horman, Kuniyuki Iwashima, netdev
In-Reply-To: <20260505174904.52b20741@kernel.org>
On Tue, May 5, 2026 at 5:49 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Sat, 2 May 2026 03:12:53 +0000 Kuniyuki Iwashima wrote:
> > Kuniyuki Iwashima (15):
> > udp_tunnel: Pass struct sock to udp_tunnel_sock_release().
> > udp_tunnel: Pass struct sock to setup_udp_tunnel_sock().
> > udp_tunnel: Pass struct sock to udp_tunnel6_dst_lookup().
> > udp_tunnel: Pass struct sock to udp_tunnel_{push,drop}_rx_port().
> > udp_tunnel: Pass struct sock to udp_tunnel_notify_{add,del}_rx_port().
> > vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().
> > vxlan: Store struct sock in struct vxlan_sock.
> > vxlan: Free vxlan_sock with kfree_rcu().
> > geneve: Store struct sock in struct geneve_sock.
> > bareudp: Store struct sock in struct bareudp_dev.
> > fou: Store struct sock in struct fou.
> > amt: Store struct sock in struct amt_dev.
> > pfcp: Store struct sock in struct pfcp_dev.
> > tipc: Store struct sock in struct udp_bearer.
> > udp_tunnel: Remove synchronize_rcu() in udp_tunnel_sock_release().
>
> Excellent job splitting this into patches, pleasure to read!
Happy to hear that, thanks ;)
^ permalink raw reply
* [PATCH net] net/smc: fix missing sk_err when TCP handshake fails
From: D. Wythe @ 2026-05-06 1:41 UTC (permalink / raw)
To: David S. Miller, Dust Li, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Sidraya Jayagond, Wenjia Zhang
Cc: Karsten Graul, Mahanta Jambigi, Simon Horman, Tony Lu,
Ursula Braun, Wen Gu, linux-kernel, linux-rdma, linux-s390,
netdev, oliver.yang, pasic
In smc_connect_work(), when the underlying TCP handshake fails, the error
code (rc) must be propagated to sk_err to ensure userspace can correctly
retrieve the error status via SO_ERROR. Currently, the code only handles
a restricted set of error codes (e.g., EPIPE, ECONNREFUSED). If other
errors occurs, such as EHOSTUNREACH, sk_err remains unset (zero).
This affects applications that rely on SO_ERROR to determine connect
outcome. For example, higher versions of Go's netpoller treats
SO_ERROR == 0 combined with a failed getpeername() as a spurious wakeup
and re-enters epoll_wait(). Under ET mode, no further edge will be
generated since the socket is already in a terminal state, causing the
connect to hang indefinitely or until a user-specified timeout, if one
is set.
Fixes: 50717a37db03 ("net/smc: nonblocking connect rework")
Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
---
net/smc/af_smc.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 1a565095376a..185dbed7de5d 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1628,12 +1628,8 @@ static void smc_connect_work(struct work_struct *work)
lock_sock(&smc->sk);
if (rc != 0 || smc->sk.sk_err) {
smc->sk.sk_state = SMC_CLOSED;
- if (rc == -EPIPE || rc == -EAGAIN)
- smc->sk.sk_err = EPIPE;
- else if (rc == -ECONNREFUSED)
- smc->sk.sk_err = ECONNREFUSED;
- else if (signal_pending(current))
- smc->sk.sk_err = -sock_intr_errno(timeo);
+ if (!smc->sk.sk_err)
+ smc->sk.sk_err = (rc == -EAGAIN) ? EPIPE : -rc;
sock_put(&smc->sk); /* passive closing */
goto out;
}
--
2.45.0
^ permalink raw reply related
* Re: [PATCH net-next v3 1/4] dt-bindings: net: dsa: add MT7628 ESW
From: Rob Herring @ 2026-05-06 1:39 UTC (permalink / raw)
To: Jakub Kicinski
Cc: joey, netdev, horms, pabeni, edumazet, davem, olteanv, andrew,
devicetree, krzk+dt, conor+dt
In-Reply-To: <20260430235621.3080081-1-kuba@kernel.org>
On Thu, Apr 30, 2026 at 04:56:21PM -0700, Jakub Kicinski wrote:
> This is an AI-generated review of your patch. The human sending this
> email says "Since Andrew requested some changes already here is the
> AI review to look thru as well (could be false positives)."
> ---
> Subject: dt-bindings: net: dsa: add MT7628 ESW
>
> This patch adds a new YAML device tree binding for the Embedded Switch
> block found in the MediaTek MT7628 SoC. The binding describes a five
> port switch with integrated 10/100 PHYs plus an internally connected
> 1G CPU port, together with reset lines and an optional MDIO subnode.
>
> > diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
> > new file mode 100644
> > index 000000000000..a9db9057ee54
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
> > @@ -0,0 +1,101 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/dsa/mediatek,mt7628-esw.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Mediatek MT7628 Embedded Ethernet Switch
> > +
> > +maintainers:
> > + - Joris Vaisvila <joey@tinyisr.com>
>
> This isn't a bug, but the maintainers list only contains the submitter
> at an unrelated domain. Existing in-tree MediaTek DSA bindings such as
> Documentation/devicetree/bindings/net/dsa/mediatek,mt7530.yaml list
> multiple MediaTek or long-standing MediaTek-community maintainers.
>
> For an official MediaTek SoC's built-in switch IP, would it make sense
> to CC or co-list a MediaTek networking maintainer (Sean Wang, Landen
> Chao, Daniel Golle, ...) so the hardware description can be
> corroborated and the binding ABI has long-term stewardship?
>
> > +
> > +description:
> > + The MT7628 SoC's built-in Ethernet Switch is a five port switch with
> > + integrated 10/100 PHYs. The switch registers are directly mapped in the SoC's
> > + memory. The switch has an internally connected 1G CPU port and 5 user ports
> > + connected to the built-in Fast Ethernet PHYs.
>
> Is the description internally consistent?
>
> The first sentence says "a five port switch with integrated 10/100
> PHYs", but the following sentences describe "an internally connected
> 1G CPU port and 5 user ports", which is six ports in total. The
> example below also enumerates six ports (reg = 0..4 and 6).
>
> Could this be reworded as e.g. "5 user ports plus 1 internal CPU
> port" to avoid the ambiguity?
>
> Separately, there is no justification in the commit message or
> binding for the absence of a clocks property. MT7628 peripherals are
> typically gated by syscon clock outputs (see
> arch/mips/boot/dts/ralink/mt7628a.dtsi), and
> drivers/net/ethernet/mediatek/mtk_eth_soc.c already treats "esw" as a
> named clock.
>
> The MT7628 ESW driver added alongside this binding deliberately does
> not call any clk_* API, which is a valid design choice if the esw
> gate is always on after reset. Since DT bindings are ABI, though,
> adding a clocks property later would be a backward-incompatible
> change.
>
> Could the commit message explain why no clocks property is needed, or
> alternatively could clocks/clock-names be described in the binding
> now even if the initial driver ignores them?
>
> > +
> > +unevaluatedProperties: false
> > +
> > +allOf:
> > + - $ref: dsa.yaml#/$defs/ethernet-ports
> > +
> > +properties:
> > + compatible:
> > + const: mediatek,mt7628-esw
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + resets:
> > + items:
> > + - description: internal switch block reset
> > + - description: internal phy package reset
> > +
> > + reset-names:
> > + items:
> > + - const: esw
> > + - const: ephy
> > +
> > + mdio:
> > + $ref: /schemas/net/mdio.yaml#
> > + unevaluatedProperties: false
>
> The mdio subnode is referenced here and is actually consumed by the
> driver (drivers/net/dsa/mt7628.c mt7628_setup_internal_mdio() calls
> of_get_available_child_by_name(..., "mdio") and
> devm_of_mdiobus_register()), but the binding provides no description
> of when or why a user would populate it.
>
> Given the top-level description says the PHYs are "integrated" and
> "internally connected", when should an mdio subnode be present? Is an
> external MDIO master ever supported?
>
> A short description attached to the mdio property would make the
> intent clear to DT authors.
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - resets
> > + - reset-names
> > + - ethernet-ports
>
> Should the valid port reg values be constrained here?
>
> The MT7628 ESW has a fixed, well-known set of valid port indices
> (0..4 for user ports and 6 for the CPU, with port 5 not existing).
> See mt7628_phylink_get_caps() in drivers/net/dsa/mt7628.c, which
> explicitly comments that "port 5 does not exist on MT7628".
>
> As written the schema accepts ethernet-port@5 or ethernet-port@7 at
> dt_binding_check time, even though the driver will silently ignore
> them. Would adding a reg enum constraint on the ethernet-port
> children (e.g. via patternProperties, or an override of the
> $defs/ethernet-ports reg) catch these mistakes at schema-validation
> time?
>
> > +
> > +examples:
> > + - |
> > + switch0: switch@10110000 {
This label is unused and should be dropped.
> > + compatible = "mediatek,mt7628-esw";
> > +
> > + reg = <0x10110000 0x8000>;
> > +
> > + resets = <&sysc 23>, <&sysc 24>;
> > + reset-names = "esw", "ephy";
> > +
> > + ethernet-ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> [ ... ]
> > + ethernet-port@6 {
> > + reg = <6>;
> > + phy-mode = "internal";
> > + ethernet = <ðernet>;
>
> The example references an undefined phandle here: ethernet-port@6
> uses ethernet = <ðernet> but no node labelled "ethernet" is defined
> in the example snippet.
>
> Other DSA binding examples in Documentation/devicetree/bindings/net/dsa/
> typically either provide a minimal stub for referenced phandles inside
> the example or use a reg-based reference. Will dt_binding_check emit a
> warning about the unresolved phandle as written?
No, example phandles don't have to resolve to a provider and we
actively don't want providers in the examples.
Rob
^ permalink raw reply
* Re: [PATCH 6/9] dt-bindings: bluetooth: qcom: Add NVMEM BD address cell
From: Rob Herring (Arm) @ 2026-05-06 1:33 UTC (permalink / raw)
To: Loic Poulain
Cc: Bjorn Andersson, devicetree, Krzysztof Kozlowski, linux-arm-msm,
Marcel Holtmann, Konrad Dybcio, David S. Miller, linux-mmc,
Jens Axboe, netdev, Simon Horman, Rocky Liao, daniel,
linux-wireless, Ulf Hansson, Eric Dumazet, Balakrishna Godavarthi,
linux-kernel, Bartosz Golaszewski, Jakub Kicinski, Paolo Abeni,
linux-bluetooth, Conor Dooley, Luiz Augusto von Dentz,
Jeff Johnson, ath10k, linux-block, Johannes Berg
In-Reply-To: <20260428-block-as-nvmem-v1-6-6ad23e75190a@oss.qualcomm.com>
On Tue, 28 Apr 2026 16:23:11 +0200, Loic Poulain wrote:
> Add support for an NVMEM cell provider for "local-bd-address",
> allowing the Bluetooth stack to retrieve controller's BD address
> from non-volatile storage such as an EEPROM or an eMMC partition.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> .../bindings/net/bluetooth/qcom,bluetooth-common.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH net v3] net/mana: Fix auxiliary device double-delete race
From: Jakub Kicinski @ 2026-05-06 1:28 UTC (permalink / raw)
To: kotaranov
Cc: Jakub Kicinski, shirazsaleem, kotaranov, pabeni, haiyangz, kys,
edumazet, davem, decui, wei.liu, longli, jgg, leon, linux-rdma,
linux-kernel, netdev
In-Reply-To: <20260504142704.159035-1-kotaranov@linux.microsoft.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.
---
net/mana: Fix auxiliary device double-delete race
This commit modifies remove_adev() to use xchg() to atomically claim the
auxiliary device pointer. This change is intended to prevent a double-free
race between the PCI eject path and the service reset workqueue.
> diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
> index a654b3699c4c5..dd4f4215ab434 100644
> --- a/drivers/net/ethernet/microsoft/mana/mana_en.c
> +++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
> @@ -3465,14 +3465,19 @@ static void adev_release(struct device *dev)
>
> static void remove_adev(struct gdma_dev *gd)
> {
> - struct auxiliary_device *adev = gd->adev;
> - int id = adev->id;
> + struct auxiliary_device *adev;
> + int id;
> +
> + adev = xchg(&gd->adev, NULL);
> + if (!adev)
> + return;
Does this xchg() operation act as an ad-hoc synchronization gate rather
than properly synchronizing the concurrent teardown paths?
While using xchg() ensures the adev pointer itself is only freed once, the
rest of the teardown sequence appears to remain unprotected. If the PCI
remove path and the service reset workqueue run concurrently, one thread
might successfully claim and process the adev, causing the other thread to
return early from remove_adev().
However, the thread returning early will then continue its execution into
the rest of mana_remove() or mana_rdma_remove(). This could allow the first
thread to proceed and free critical structures:
mana_remove() {
...
remove_adev(gd);
...
free_netdev(ndev);
...
kfree(ac);
}
while the second thread concurrently iterates and accesses those same
structures.
Could this concurrent execution lead to a use-after-free on ndev or ac?
Should the teardown sequence be synchronized using a proper lock, such as
the device lock, or by synchronously canceling the service work in the
remove path, instead of relying on an atomic operation?
[ ... ]
--
pw-bot: cr
^ permalink raw reply
* Re: [net-next PATCH v2 7/8] net: dsa: realtek: rtl8365mb: add FDB support
From: Jakub Kicinski @ 2026-05-06 1:27 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Linus Walleij, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260503-realtek_forward-v2-7-d064e220b391@gmail.com>
On Sun, 03 May 2026 03:18:27 -0300 Luiz Angelo Daros de Luca wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Implement support for FDB and MDB management for the RTL8365MB series
> switches.
>
> The hardware supports IVL by keying the forwarding database with the
> {VID, MAC, EFID} tuple. The Extended Filtering ID (EFID) is 3 bits
> wide, providing 8 unique filtering domains. This driver reserves EFID 0
> for standalone ports, effectively limiting the hardware offload to a
> maximum of 7 bridges.
>
> Introduce a mutex lock (l2_lock) to protect concurrent L2 table updates.
>
> Add support for forwarding database operations, including unicast and
> multicast entry handling as well as fast aging support.
Warning: ../drivers/net/dsa/realtek/rtl8365mb_l2.c:243 function parameter 'entry' not described in 'rtl8365mb_l2_get_next_uc'
Warning: ../drivers/net/dsa/realtek/rtl8365mb_l2.c:243 function parameter 'entry' not described in 'rtl8365mb_l2_get_next_uc'
--
pw-bot: cr
^ permalink raw reply
* Re: [net-next PATCH v2 4/8] net: dsa: realtek: rtl8365mb: add table lookup interface
From: Jakub Kicinski @ 2026-05-06 1:26 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Linus Walleij, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260503-realtek_forward-v2-4-d064e220b391@gmail.com>
On Sun, 03 May 2026 03:18:24 -0300 Luiz Angelo Daros de Luca wrote:
> +int rtl8365mb_table_query(struct realtek_priv *priv,
> + enum rtl8365mb_table table,
> + enum rtl8365mb_table_op op, u16 *addr,
> + enum rtl8365mb_table_l2_method method,
> + u16 port, u16 *data, size_t size)
> +{
> + bool addr_as_input = true;
> + bool write_data = false;
> + int ret = 0;
> + u32 cmd;
> + u32 val;
> + u32 hit;
> +
> + if (!addr) {
> + dev_err(priv->dev, "%s: addr is NULL\n", __func__);
> + return -EINVAL;
> + }
> +
> + if (!data) {
> + dev_err(priv->dev, "%s: data is NULL\n", __func__);
> + return -EINVAL;
> + }
> +
> + if (size > RTL8365MB_TABLE_ENTRY_MAX_SIZE) {
> + dev_err(priv->dev, "%s: size too big: %zu\n", __func__, size);
> + return -E2BIG;
> + }
> +
> + if (size == 0) {
> + dev_err(priv->dev, "%s: size is 0\n", __func__);
> + return -EINVAL;
> + }
Defensive checks are discouraged in the kernel. AI will make short work
of finding such trivial violations.
^ permalink raw reply
* Re: [net-next PATCH v2 4/8] net: dsa: realtek: rtl8365mb: add table lookup interface
From: Jakub Kicinski @ 2026-05-06 1:25 UTC (permalink / raw)
To: Luiz Angelo Daros de Luca
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Linus Walleij, Alvin Šipraga,
Yury Norov, Rasmus Villemoes, Russell King, netdev, linux-kernel
In-Reply-To: <20260503-realtek_forward-v2-4-d064e220b391@gmail.com>
On Sun, 03 May 2026 03:18:24 -0300 Luiz Angelo Daros de Luca wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
>
> Add a generic table lookup interface to centralize access to
> the RTL8365MB internal tables.
>
> This interface abstracts the low-level table access logic and
> will be used by subsequent commits to implement FDB and VLAN
> operations.
kdoc says:
Warning: drivers/net/dsa/realtek/rtl8365mb_table.h:32 enum rtl8365mb_table { RTL8365MB_TABLE_ACL_RULE = 1, RTL8365MB_TABLE_ACL_ACTION = 2, RTL8365MB_TABLE_CVLAN = 3, RTL8365MB_TABLE_L2 = 4, RTL8365MB_TABLE_IGMP_GROUP = 5, }; error: Cannot parse struct or union!
Warning: drivers/net/dsa/realtek/rtl8365mb_table.h:130 No description found for return value of 'rtl8365mb_table_query'
Warning: drivers/net/dsa/realtek/rtl8365mb_table.h:130 No description found for return value of 'rtl8365mb_table_query'
^ permalink raw reply
* Re: [PATCH net] net: wan: fsl_ucc_hdlc: return NETDEV_TX_OK if skb was freed
From: Jakub Kicinski @ 2026-05-06 1:22 UTC (permalink / raw)
To: Holger Brunck
Cc: netdev, linuxppc-dev, andrew+netdev, chleroy, qiang.zhao, horms
In-Reply-To: <20260504174406.2229693-1-holger.brunck@hitachienergy.com>
On Mon, 4 May 2026 19:44:06 +0200 Holger Brunck wrote:
> If the skb was freed in the ucc_hdlc_tx function and the packet marked
> as dropped we need to return NETDEV_TX_OK. Otherwise the above layer
> will try to requeue an already freed skb.
Is this really true? I thought negative returns mean drop.
^ permalink raw reply
* Re: [PATCH net-next v7 0/3] selftests: drv-net: convert so_txtime to drv-net
From: patchwork-bot+netdevbpf @ 2026-05-06 1:20 UTC (permalink / raw)
To: Willem de Bruijn
Cc: netdev, davem, kuba, edumazet, pabeni, horms, linux-kselftest,
shuah, willemb
In-Reply-To: <20260504174056.565319-1-willemdebruijn.kernel@gmail.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 4 May 2026 13:38:31 -0400 you wrote:
> From: Willem de Bruijn <willemb@google.com>
>
> In preparation for extending to pacing hardware offload, convert the
> so_txtime.sh test to a drv-net test that can be run against netdevsim
> and real hardware.
>
> Two preparatory patches
> 1. support negative tests, where tests are expected to fail
> 2. add a tc helper
>
> [...]
Here is the summary with links:
- [net-next,v7,1/3] selftests: net: py: support cmd verifying expected failure
https://git.kernel.org/netdev/net-next/c/d9c1e7dc4ada
- [net-next,v7,2/3] selftests: net: py: add tc utility
https://git.kernel.org/netdev/net-next/c/49bf9e5e7c7c
- [net-next,v7,3/3] selftests: drv-net: convert so_txtime to drv-net
https://git.kernel.org/netdev/net-next/c/5c6baef3885c
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: remove unused .port_max_speed_mode()
From: patchwork-bot+netdevbpf @ 2026-05-06 1:20 UTC (permalink / raw)
To: =?utf-8?q?Marek_Beh=C3=BAn_=3Ckabel=40kernel=2Eorg=3E?=
Cc: andrew, olteanv, rmk+kernel, vivien.didelot, tobias, netdev
In-Reply-To: <20260504152653.1389394-1-kabel@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 4 May 2026 17:26:53 +0200 you wrote:
> The .port_max_speed_mode() method is not used anymore since commit
> 40da0c32c3fc ("net: dsa: mv88e6xxx: remove handling for DSA and CPU ports").
> Drop it.
>
> Signed-off-by: Marek Behún <kabel@kernel.org>
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 9 -------
> drivers/net/dsa/mv88e6xxx/chip.h | 4 ----
> drivers/net/dsa/mv88e6xxx/port.c | 40 --------------------------------
> drivers/net/dsa/mv88e6xxx/port.h | 9 -------
> 4 files changed, 62 deletions(-)
Here is the summary with links:
- net: dsa: mv88e6xxx: remove unused .port_max_speed_mode()
https://git.kernel.org/netdev/net-next/c/9c7d567358cc
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] atm: solos-pci: Simplify initialisation of pci_device_id array
From: patchwork-bot+netdevbpf @ 2026-05-06 1:20 UTC (permalink / raw)
To: =?utf-8?q?Uwe_Kleine-K=C3=B6nig_=28The_Capable_Hub=29_=3Cu=2Ekleine-koenig?=,
=?utf-8?q?=40baylibre=2Ecom=3E?=
Cc: 3chas3, linux-atm-general, netdev, linux-kernel, msp
In-Reply-To: <20260504151202.2139919-2-u.kleine-koenig@baylibre.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 4 May 2026 17:12:01 +0200 you wrote:
> Use the convenience macro PCI_DEVICE to initialize .vendor, .device,
> .subvendor and .subdevice. Drop explicit zeros that the compiler also
> fills in.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
> ---
> Hello,
>
> [...]
Here is the summary with links:
- [net-next] atm: solos-pci: Simplify initialisation of pci_device_id array
https://git.kernel.org/netdev/net-next/c/17099a2f86cb
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 net] net/sched: sch_fq_codel: annotate data-races from fq_codel_dump_class_stats()
From: patchwork-bot+netdevbpf @ 2026-05-06 1:10 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, jhs, jiri, netdev, eric.dumazet
In-Reply-To: <20260504163842.1162001-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 4 May 2026 16:38:42 +0000 you wrote:
> fq_codel_dump_class_stats() acquires qdisc spinlock only when requested
> to follow flow->head chain.
>
> As we did in sch_cake recently, add the missing READ_ONCE()/WRITE_ONCE()
> annotations.
>
> Fixes: edb09eb17ed8 ("net: sched: do not acquire qdisc spinlock in qdisc/class stats dump")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> [...]
Here is the summary with links:
- [v2,net] net/sched: sch_fq_codel: annotate data-races from fq_codel_dump_class_stats()
https://git.kernel.org/netdev/net/c/f83e07b29246
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 1/8] ipvs: fixes for the new ip_vs_status info
From: patchwork-bot+netdevbpf @ 2026-05-06 1:10 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: netfilter-devel, davem, netdev, kuba, pabeni, edumazet, fw, horms,
ja, longman, lvs-devel
In-Reply-To: <20260505001648.360569-2-pablo@netfilter.org>
Hello:
This series was applied to netdev/net.git (main)
by Pablo Neira Ayuso <pablo@netfilter.org>:
On Tue, 5 May 2026 02:16:41 +0200 you wrote:
> From: Julian Anastasov <ja@ssi.bg>
>
> Sashiko reports some problems for the recently added
> /proc/net/ip_vs_status:
>
> * ip_vs_status_show() as a table reader may run long after the
> conn_tab and svc_table table are released. While ip_vs_conn_flush()
> properly changes the conn_tab_changes counter when conn_tab is removed,
> ip_vs_del_service() and ip_vs_flush() were missing such change for
> the svc_table_changes counter. As result, readers like
> ip_vs_dst_event() and ip_vs_status_show() may continue to use
> a freed table after a cond_resched_rcu() call.
>
> [...]
Here is the summary with links:
- [net,1/8] ipvs: fixes for the new ip_vs_status info
https://git.kernel.org/netdev/net/c/afbd961305eb
- [net,2/8] ipvs: fix races around the conn_lfactor and svc_lfactor sysctl vars
https://git.kernel.org/netdev/net/c/f2da9a96abb4
- [net,3/8] ipvs: fix the spin_lock usage for RT build
https://git.kernel.org/netdev/net/c/d493d9de1c21
- [net,4/8] ipvs: do not leak dest after get from dest trash
https://git.kernel.org/netdev/net/c/fbe1e01e818e
- [net,5/8] ipvs: fix races around est_mutex and est_cpulist
https://git.kernel.org/netdev/net/c/2fd109238925
- [net,6/8] ipvs: fix shift-out-of-bounds in ip_vs_rht_desired_size
https://git.kernel.org/netdev/net/c/4ee52b7021a7
- [net,7/8] ipvs: Guard access of HK_TYPE_KTHREAD cpumask with RCU
https://git.kernel.org/netdev/net/c/aa6065206987
- [net,8/8] sched/isolation: Make HK_TYPE_KTHREAD an alias of HK_TYPE_DOMAIN
https://git.kernel.org/netdev/net/c/8f78b749f3da
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH net] net: usb: asix: ax88772: replace usbnet_link_change() with queue_work() and usbnet_unlink_rx_urbs()
From: Markus Baier @ 2026-05-06 1:03 UTC (permalink / raw)
To: Oleksij Rempel
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Russell King, Ethan Nelson-Moore, Miaoqian Lin,
linux-usb, linux-kernel, netdev, Markus Baier
Commit 36bdc0e815b4 ("net: usb: asix: ax88772: re-add usbnet_link_change()
in phylink callbacks") restored the link-change notification that was
lost during the phylink migration, by calling usbnet_link_change() from
the phylink mac_link_up() / mac_link_down() callbacks.
While this fixed the original symptom (RX URB submission not being
initiated after link up), usbnet_link_change() also calls
netif_carrier_off() on link-down, which is redundant in a phylink-based
driver because phylink manages the carrier state itself.
Replace the usbnet_link_change() calls with the minimal operations:
- In ax88772_mac_link_up(), schedule dev->bh_work directly via
queue_work(system_bh_wq, &dev->bh_work). This is the same
mechanism usbnet_open() uses to schedule the bottom-half
that submits RX URBs.
- In ax88772_mac_link_down(), call usbnet_unlink_rx_urbs() to
return any in-flight RX URBs to the host controller.
This releases USB bandwidth and avoids keeping unused buffers
queued while the link is down. This is the symmetric
counterpart to scheduling new RX URBs on link up.
Tested with the Apple A1277 USB Ethernet Adapter (05ac:1402,
AX88772A based) on a Banana Pro (Allwinner A20).
Fixes: 36bdc0e815b4 ("net: usb: asix: ax88772: re-add usbnet_link_change() in phylink callbacks")
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Markus Baier <Markus.Baier@soslab.tu-darmstadt.de>
---
Transparency notice: The English formulation of this commit message
was prepared with AI assistance. The actual system testing and
verification of the issue were performed manually without AI
involvement.
This is a follow-up to commit 36bdc0e815b4 (just applied to net.git).
While that patch correctly restored the missing RX URB submission,
I realized during further analysis that usbnet_link_change() carries
side effects (notably calling netif_carrier_off() on link-down) that
are redundant in a phylink-based driver. After studying how
usbnet_open() handles the same task (direct queue_work() call), this
minimal approach better matches the existing usbnet patterns.
I am sending this now rather than waiting, because the previous patch
just landed and I would like the cleanup to be considered before it
propagates further into stable kernels via the Fixes: tag.
drivers/net/usb/asix_devices.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
index 293ef80c4e30..4230ff611c4b 100644
--- a/drivers/net/usb/asix_devices.c
+++ b/drivers/net/usb/asix_devices.c
@@ -756,7 +756,11 @@ static void ax88772_mac_link_down(struct phylink_config *config,
struct usbnet *dev = netdev_priv(to_net_dev(config->dev));
asix_write_medium_mode(dev, 0, 0);
- usbnet_link_change(dev, false, false);
+
+ /* Phylink will call netif_carrier_off(), but we should explicitly
+ * stop RX URBs to save USB bandwidth.
+ */
+ usbnet_unlink_rx_urbs(dev);
}
static void ax88772_mac_link_up(struct phylink_config *config,
@@ -787,7 +791,11 @@ static void ax88772_mac_link_up(struct phylink_config *config,
m |= AX_MEDIUM_RFC;
asix_write_medium_mode(dev, m, 0);
- usbnet_link_change(dev, true, false);
+
+ /* Phylink will call netif_carrier_on(), but we need to explicitly
+ * kick off RX URB submission in usbnet.
+ */
+ queue_work(system_bh_wq, &dev->bh_work);
}
static const struct phylink_mac_ops ax88772_phylink_mac_ops = {
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v1 net-next 00/15] udp_tunnel: Speed up UDP tunnel device destruction (Part I)
From: patchwork-bot+netdevbpf @ 2026-05-06 1:00 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, edumazet, kuba, pabeni, andrew+netdev, horms, kuni1840,
netdev
In-Reply-To: <20260502031401.3557229-1-kuniyu@google.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 2 May 2026 03:12:53 +0000 you wrote:
> Most of the UDP tunnel devices call synchronize_rcu() twice
> during destruction, for example, vxlan has
>
> 1) synchronize_rcu() in udp_tunnel_sock_release()
>
> 2) synchronize_net() in vxlan_sock_release()
>
> [...]
Here is the summary with links:
- [v1,net-next,01/15] udp_tunnel: Pass struct sock to udp_tunnel_sock_release().
https://git.kernel.org/netdev/net-next/c/944bfc1b1c6f
- [v1,net-next,02/15] udp_tunnel: Pass struct sock to setup_udp_tunnel_sock().
https://git.kernel.org/netdev/net-next/c/2cba193628fe
- [v1,net-next,03/15] udp_tunnel: Pass struct sock to udp_tunnel6_dst_lookup().
https://git.kernel.org/netdev/net-next/c/9333d5ff28bd
- [v1,net-next,04/15] udp_tunnel: Pass struct sock to udp_tunnel_{push,drop}_rx_port().
https://git.kernel.org/netdev/net-next/c/8d0012ce1b41
- [v1,net-next,05/15] udp_tunnel: Pass struct sock to udp_tunnel_notify_{add,del}_rx_port().
https://git.kernel.org/netdev/net-next/c/af3f903fbb70
- [v1,net-next,06/15] vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().
https://git.kernel.org/netdev/net-next/c/30a45c0bffdd
- [v1,net-next,07/15] vxlan: Store struct sock in struct vxlan_sock.
https://git.kernel.org/netdev/net-next/c/027bffa1ad19
- [v1,net-next,08/15] vxlan: Free vxlan_sock with kfree_rcu().
https://git.kernel.org/netdev/net-next/c/4f71dd1b421d
- [v1,net-next,09/15] geneve: Store struct sock in struct geneve_sock.
https://git.kernel.org/netdev/net-next/c/82720c6196dc
- [v1,net-next,10/15] bareudp: Store struct sock in struct bareudp_dev.
https://git.kernel.org/netdev/net-next/c/bc773b15eb19
- [v1,net-next,11/15] fou: Store struct sock in struct fou.
https://git.kernel.org/netdev/net-next/c/173a79f6966a
- [v1,net-next,12/15] amt: Store struct sock in struct amt_dev.
https://git.kernel.org/netdev/net-next/c/65c6e06d5aba
- [v1,net-next,13/15] pfcp: Store struct sock in struct pfcp_dev.
https://git.kernel.org/netdev/net-next/c/fe57adbe0dac
- [v1,net-next,14/15] tipc: Store struct sock in struct udp_bearer.
https://git.kernel.org/netdev/net-next/c/1ae552c7b665
- [v1,net-next,15/15] udp_tunnel: Remove synchronize_rcu() in udp_tunnel_sock_release().
https://git.kernel.org/netdev/net-next/c/72d3b9a4c2b1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 2/3] ovpn: ensure packet delivery happens with BH disabled
From: Jakub Kicinski @ 2026-05-06 1:00 UTC (permalink / raw)
To: antonio
Cc: Jakub Kicinski, netdev, edumazet, sd, davem, pabeni, ralf,
andrew+netdev, horms, shuah, linux-kselftest
In-Reply-To: <20260504230305.2681646-3-antonio@openvpn.net>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
ovpn: ensure packet delivery happens with BH disabled
This commit wraps gro_cells_receive() and dev_dstats_rx_add() with
local_bh_disable() and local_bh_enable() in ovpn_netdev_write(). This
prevents deadlocks and per-cpu state corruption when packet delivery occurs
in process context for TCP connections.
> diff --git a/drivers/net/ovpn/io.c b/drivers/net/ovpn/io.c
> --- a/drivers/net/ovpn/io.c
> +++ b/drivers/net/ovpn/io.c
> @@ -91,12 +91,18 @@ static void ovpn_netdev_write(struct ovpn_peer *peer, struct sk_buff *skb)
>
> /* cause packet to be "received" by the interface */
> pkt_len = skb->len;
> + /* we may get here in process context in case of TCP connections,
> + * therefore we have to disable BHs to ensure gro_cells_receive()
> + * and dev_dstats_rx_add() do not get corrupted or enter deadlock
> + */
> + local_bh_disable();
> ret = gro_cells_receive(&peer->ovpn->gro_cells, skb);
> if (likely(ret == NET_RX_SUCCESS)) {
> /* update RX stats with the size of decrypted packet */
> ovpn_peer_stats_increment_rx(&peer->vpn_stats, pkt_len);
> dev_dstats_rx_add(peer->ovpn->dev, pkt_len);
> }
> + local_bh_enable();
> }
This protects the success path, but do the error and drop paths also need
BH protection?
If ovpn_decrypt_post() is called in process context for TCP connections, an
error condition jumps to the drop label:
ovpn_decrypt_post() {
...
if (unlikely(ret < 0))
goto drop;
...
drop:
if (unlikely(skb))
dev_dstats_rx_dropped(peer->ovpn->dev);
...
}
Since dev_dstats_rx_dropped() updates the same per-CPU dstats structure
without disabling bottom halves, could it still be vulnerable to softirq
preemption and stat corruption?
Additionally, do the TX paths in the TCP implementation have similar issues?
It looks like ovpn_tcp_send_skb() and ovpn_tcp_send_sock_skb() might call
dev_dstats_tx_dropped() without disabling bottom halves.
Similarly, ovpn_tcp_send_sock() uses preempt_disable() around
dev_dstats_tx_add(), which does not prevent softirqs from running upon
return from a hardware interrupt on the same CPU. Does this leave a similar
race window open?
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next 12/15] bnxt_en: Support kTLS TX offload by implementing .tls_dev_add/del()
From: Jakub Kicinski @ 2026-05-06 0:58 UTC (permalink / raw)
To: Michael Chan
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, pavan.chebbi,
andrew.gospodarek
In-Reply-To: <20260504235836.3019499-13-michael.chan@broadcom.com>
On Mon, 4 May 2026 16:58:33 -0700 Michael Chan wrote:
> Add basic infrastructure to allocate and free kTLS context IDs (KIDs)
> to support kTLS TX offload. To offload a connection in .tls_dev_add(),
> the first step is to allocate a KID. After that the kTLS offload
> command is sent to the HW via MPC using the function
> bnxt_xmit_crypto_cmd() introduced in the last patch.
>
> In .tls_dev_del(), we send the delete command to the HW using the
> same bnxt_xmit_crypto_cmd(). After that we free the KID, making it
> available for new offload.
>
> bnxt_ktls_ops will be assigned to the netdev and the TLS features will
> be enabled in the next patch.
drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:269:32: warning: unused variable 'bnxt_ktls_ops' [-Wunused-const-variable]
269 | static const struct tlsdev_ops bnxt_ktls_ops = {
| ^~~~~~~~~~~~~
Warning: drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:24 No description found for return value of 'bnxt_alloc_ktls_info'
Warning: drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.c:24 No description found for return value of 'bnxt_alloc_ktls_info'
^ permalink raw reply
* Re: [PATCH net-next 10/15] bnxt_en: Add MPC transmit and completion functions
From: Jakub Kicinski @ 2026-05-06 0:57 UTC (permalink / raw)
To: Michael Chan
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, pavan.chebbi,
andrew.gospodarek
In-Reply-To: <20260504235836.3019499-11-michael.chan@broadcom.com>
On Mon, 4 May 2026 16:58:31 -0700 Michael Chan wrote:
> Add transmit, ring selection, and completion functions for midpath rings.
> These will be used to send control data to the crypto engines.
drivers/net/ethernet/broadcom/bnxt/bnxt_mpc.c:488:16: warning: variable 'handle' set but not used [-Wunused-but-set-variable]
488 | unsigned long handle = 0;
| ^
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v1 net-next 00/15] udp_tunnel: Speed up UDP tunnel device destruction (Part I)
From: Jakub Kicinski @ 2026-05-06 0:49 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: David S . Miller, Eric Dumazet, Paolo Abeni, Andrew Lunn,
Simon Horman, Kuniyuki Iwashima, netdev
In-Reply-To: <20260502031401.3557229-1-kuniyu@google.com>
On Sat, 2 May 2026 03:12:53 +0000 Kuniyuki Iwashima wrote:
> Kuniyuki Iwashima (15):
> udp_tunnel: Pass struct sock to udp_tunnel_sock_release().
> udp_tunnel: Pass struct sock to setup_udp_tunnel_sock().
> udp_tunnel: Pass struct sock to udp_tunnel6_dst_lookup().
> udp_tunnel: Pass struct sock to udp_tunnel_{push,drop}_rx_port().
> udp_tunnel: Pass struct sock to udp_tunnel_notify_{add,del}_rx_port().
> vxlan: Fix potential null-ptr-deref in vxlan_gro_prepare_receive().
> vxlan: Store struct sock in struct vxlan_sock.
> vxlan: Free vxlan_sock with kfree_rcu().
> geneve: Store struct sock in struct geneve_sock.
> bareudp: Store struct sock in struct bareudp_dev.
> fou: Store struct sock in struct fou.
> amt: Store struct sock in struct amt_dev.
> pfcp: Store struct sock in struct pfcp_dev.
> tipc: Store struct sock in struct udp_bearer.
> udp_tunnel: Remove synchronize_rcu() in udp_tunnel_sock_release().
Excellent job splitting this into patches, pleasure to read!
^ permalink raw reply
* Re: [PATCH v1 net] ipv6: Fix null-ptr-deref in fib6_mtu().
From: patchwork-bot+netdevbpf @ 2026-05-06 0:40 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: dsahern, idosch, davem, edumazet, kuba, pabeni, horms, kuni1840,
netdev, syzbot+01f005f9c6387ca6f6dd
In-Reply-To: <20260504064316.3820775-1-kuniyu@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 4 May 2026 06:43:13 +0000 you wrote:
> syzbot reported null-ptr-deref in fib6_mtu(). [0]
>
> When res->f6i->fib6_pmtu is 0 in fib6_mtu(), it fetches MTU from
> __in6_dev_get(nh->fib_nh_dev)->cnf.mtu6.
>
> However, __in6_dev_get() could return NULL when the device is
> being unregistered.
>
> [...]
Here is the summary with links:
- [v1,net] ipv6: Fix null-ptr-deref in fib6_mtu().
https://git.kernel.org/netdev/net/c/5ad509c1fdad
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net 0/4] bnxt_en: Bug fixes
From: patchwork-bot+netdevbpf @ 2026-05-06 0:40 UTC (permalink / raw)
To: Pavan Chebbi
Cc: davem, kuba, andrew+netdev, andrew.gospodarek, edumazet,
michael.chan, netdev, pabeni
In-Reply-To: <20260504083611.1383776-1-pavan.chebbi@broadcom.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 4 May 2026 14:06:07 +0530 you wrote:
> This patchset adds the following fixes for bnxt:
>
> Patch #1 fixes DPC AER handling to make it more reliable
>
> Patch #2 fixes incorrect capping bp->max_tpa based on what the FW
> supports
>
> [...]
Here is the summary with links:
- [net,1/4] bnxt_en: Delay for 5 seconds after AER DPC for all chips
https://git.kernel.org/netdev/net/c/07f44433355f
- [net,2/4] bnxt_en: Set bp->max_tpa according to what the FW supports
https://git.kernel.org/netdev/net/c/54c28fab2fa5
- [net,3/4] bnxt_en: Check return value of bnxt_hwrm_vnic_cfg
https://git.kernel.org/netdev/net/c/16517bc98a56
- [net,4/4] bnxt_en: Use absolute target ns from ptp_clock_request
https://git.kernel.org/netdev/net/c/bd279e104e5f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] ipv6: default IPV6_SIT to m
From: patchwork-bot+netdevbpf @ 2026-05-06 0:40 UTC (permalink / raw)
To: Alyssa Ross
Cc: davem, dsahern, edumazet, kuba, pabeni, horms, netdev,
linux-kernel, fmancera, rbm, krzk
In-Reply-To: <20260503192515.290900-2-hi@alyssa.is>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 3 May 2026 21:25:16 +0200 you wrote:
> This basically defaulted to m until recently, since IPV6 defaulted to
> m. Since IPV6 was changed to a boolean with a default of y, IPV6_SIT
> started defaulting to built-in as well. This results in a surprise
> sit0 device by default for defconfig (and defconfig-derived config)
> users at boot. For me, this broke an (admittedly non-robust) script.
> Preserve the behaviour of most configs by avoiding building this
> module, that's probably overall seldom used compared to IPv6 as a
> whole, into the kernel.
>
> [...]
Here is the summary with links:
- [v2] ipv6: default IPV6_SIT to m
https://git.kernel.org/netdev/net/c/901a7d9e2f28
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: bcmasp: Keep PHY link during WoL sleep cycle
From: Jakub Kicinski @ 2026-05-06 0:25 UTC (permalink / raw)
To: justin.chen
Cc: Jakub Kicinski, netdev, bcm-kernel-feedback-list, pabeni,
edumazet, davem, andrew+netdev, florian.fainelli
In-Reply-To: <20260501185625.422361-3-justin.chen@broadcom.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.
---
net: bcmasp: Keep PHY link during WoL sleep cycle
This patch splits the suspend/resume paths so that when WoL is enabled
the PHY is left running and the MAC is only partially re-initialized on
resume. phy_stop() is skipped during suspend and phy_start() is replaced
with a forced relink via phy_trigger_machine() when the MAC was reset.
> diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
> index e2b51ec903af..9ffd0dfa5969 100644
> --- a/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
> +++ b/drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c
[ ... ]
> @@ -946,7 +946,8 @@ static void bcmasp_netif_deinit(struct net_device *dev)
>
> umac_enable_set(intf, UMC_CMD_TX_EN, 0);
>
> - phy_stop(dev->phydev);
> + if (stop_phy)
> + phy_stop(dev->phydev);
Skipping phy_stop() in the WoL path means phy_stop_machine() and the
cancel_delayed_work_sync() on phydev->state_queue are no longer executed
before the ASP clock is disabled in bcmasp_interface_suspend().
The PHY state machine runs on system_power_efficient_wq, which is not
WQ_FREEZABLE, so task freeze does not stop it. If a PHY IRQ fires (or
the polling timer expires) between clk_disable_unprepare(intf->parent->clk)
and the matching clk_prepare_enable() on resume, the state machine can
reach bcmasp_adj_link() via phy_check_link_status() ->
phy_link_up()/phy_link_down() -> phydev->adjust_link.
bcmasp_adj_link() reads and writes UMC_CMD, UMC_EEE_LPI_TIMER,
UMC_EEE_CTRL and RGMII_OOB_CNTRL, which sit behind the disabled ASP
clock. Can those accesses hang the bus or return 0xffffffff on these
SoCs?
bcmgenet pins phydev->state = PHY_READY during WoL suspend specifically
to freeze the state machine in a no-op state. Is an equivalent
protection needed here?
> @@ -1385,15 +1386,20 @@ int bcmasp_interface_suspend(struct bcmasp_intf *intf)
> {
> struct device *kdev = &intf->parent->pdev->dev;
> struct net_device *dev = intf->ndev;
> + bool wake;
>
> if (!netif_running(dev))
> return 0;
>
> netif_device_detach(dev);
>
> - bcmasp_netif_deinit(dev);
> + wake = device_may_wakeup(kdev) && intf->wolopts;
>
> - if (!intf->wolopts) {
> + bcmasp_netif_deinit(dev, !wake);
> +
> + if (wake) {
> + bcmasp_suspend_to_wol(intf);
> + } else {
> bcmasp_phy_hw_unprepare(intf);
[ ... ]
> @@ -1438,17 +1444,34 @@ int bcmasp_interface_resume(struct bcmasp_intf *intf)
> if (ret)
> return ret;
>
> - bcmasp_core_clock_set_intf(intf, true);
> -
> - bcmasp_resume_from_wol(intf);
> + wake = device_may_wakeup(kdev) && intf->wolopts;
>
> - bcmasp_phy_hw_prepare(intf);
> + bcmasp_core_clock_set_intf(intf, true);
>
> - umac_reset_and_init(intf, dev->dev_addr);
> + /* The interface might be HW reset in some suspend modes, so we may
> + * need to restore the UNIMAC/PHY if that is the case.
> + */
> + reg = umac_rl(intf, UMC_CMD);
> + if (wake && (reg & UMC_CMD_RX_EN)) {
> + umac_enable_set(intf, UMC_CMD_TX_EN, 1);
> + bcmasp_resume_from_wol(intf);
> + } else {
> + bcmasp_phy_hw_prepare(intf);
> + umac_reset_and_init(intf, dev->dev_addr);
> + }
In the wake && !(reg & UMC_CMD_RX_EN) branch (MAC was HW reset during
suspend), bcmasp_resume_from_wol() is not called.
bcmasp_suspend_to_wol() unconditionally does two things that live in
the shared parent register block, not the per-interface UMC block:
wakeup_intr2_core_wl(intf->parent, 0xffffffff,
ASP_WAKEUP_INTR2_MASK_CLEAR);
if (ndev->phydev && ndev->phydev->eee_cfg.eee_enabled &&
intf->parent->eee_fixup)
intf->parent->eee_fixup(intf, true);
The wakeup interrupt mask and the EEE fixup bits (phy_lpi_overwrite in
ASP_EDPKT_SPARE_REG) are not cleared by a reset that only wipes UMC_CMD.
In this branch the wakeup IRQ remains unmasked (bcmasp_isr_wol would
then fire on subsequent MPD/FILT events during normal traffic) and the
EEE fixup stays asserted. Should this branch also invoke the parts of
bcmasp_resume_from_wol() / eee_fixup(false) that live in the shared
register block?
Separately, bcmasp_suspend_to_wol() explicitly programs
UMC_CMD_PROMISC:
reg |= UMC_CMD_RX_EN | UMC_CMD_PROMISC;
umac_wl(intf, reg, UMC_CMD);
In the wake && (reg & UMC_CMD_RX_EN) fast-resume branch, the only
writes to UMC_CMD are:
umac_enable_set(intf, UMC_CMD_TX_EN, 1);
and whatever bcmasp_resume_from_wol() does, which only touches
UMC_MPD_CTRL and ASP_WAKEUP_INTR2_MASK_SET. bcmasp_netif_init() calls
bcmasp_set_rx_mode() which manages ASP_RX_FILTER_MDA but not
UMC_CMD_PROMISC, and bcmasp_adj_link() only reprograms PROMISC inside
its if (reg & UMC_CMD_SW_RESET) branch (not taken here). Since
old_link/old_duplex/old_pause are preserved across the fast path,
adj_link's changed flag stays zero and it returns without rewriting
UMC_CMD.
Does this leave the MAC stuck in UMC_CMD_PROMISC after every WoL
resume, until the interface is toggled down/up?
>
> bcmasp_netif_init(dev);
>
> - phy_start(dev->phydev);
> + /* If HW was reset, we need to force a relink */
> + if (wake && !(reg & UMC_CMD_RX_EN)) {
> + mutex_lock(&dev->phydev->lock);
> + if (dev->phydev->state == PHY_RUNNING)
> + dev->phydev->state = PHY_UP;
> + mutex_unlock(&dev->phydev->lock);
> + phy_trigger_machine(dev->phydev);
> + } else if (!wake) {
> + phy_start(dev->phydev);
> + }
The forced-relink branch only demotes PHY_RUNNING -> PHY_UP before
phy_trigger_machine(). Since phy_stop() was skipped during suspend,
phydev->state is whatever it was at suspend time, which may instead be
PHY_NOLINK (cable was unplugged), PHY_HALTED or PHY_ERROR.
For PHY_NOLINK, _phy_state_machine() runs phy_check_link_status() +
phy_update_stats() only; it does not trigger _phy_start_aneg() (that is
the PHY_UP case). If the HW reset that cleared UMC_CMD_RX_EN also
touched the PHY chip (shared reset/power domain), autoneg may need to
be restarted.
Does this path handle states other than PHY_RUNNING, and does it
guarantee the PHY is reinitialized and autoneg restarted when the MAC
has been reset?
> +
> netif_device_attach(dev);
>
> return 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