* RE: [PATCH net-next 07/17] net: dsa: mv88e6xxx: Add connect_tag_protocol handler
From: Jagielski, Jedrzej @ 2026-07-03 13:25 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-7-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>From: Andrew Lunn <andrew@lunn.ch>
>
>When the tagging protocol handler is attached to the DSA driver, it
>can validate it is a supported tagging protocol. It can also setup
>data shared between the tagger and the switch driver. Ensure a Mavell
s/Mavell/Marvell ?
>DSA tagger is being connected, and setup the handler from RMU in the
>shared data. At this point, the handler is just an empty stub, but
>later patches will add the needed functionality.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>---
> drivers/net/dsa/mv88e6xxx/chip.c | 18 ++++++++++++++++++
> drivers/net/dsa/mv88e6xxx/rmu.c | 6 ++++++
> drivers/net/dsa/mv88e6xxx/rmu.h | 3 +++
> 3 files changed, 27 insertions(+)
>
>diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
>index 72c93cb84b7e1..fe0d0eb8f0813 100644
>--- a/drivers/net/dsa/mv88e6xxx/chip.c
>+++ b/drivers/net/dsa/mv88e6xxx/chip.c
>@@ -7183,6 +7183,23 @@ static int mv88e6xxx_crosschip_lag_leave(struct dsa_switch *ds, int sw_index,
> return err_sync ? : err_pvt;
> }
>
>+static int mv88e6xxx_connect_tag_protocol(struct dsa_switch *ds,
>+ enum dsa_tag_protocol proto)
>+{
>+ struct dsa_tagger_data *tagger_data = ds->tagger_data;
>+
>+ switch (proto) {
>+ case DSA_TAG_PROTO_DSA:
>+ case DSA_TAG_PROTO_EDSA:
>+ tagger_data->rmu_frame2reg = mv88e6xxx_rmu_frame2reg_handler;
>+ break;
>+ default:
>+ return -EPROTONOSUPPORT;
>+ }
do we really need to use switch for 0/1 cases?
>+
>+ return 0;
>+}
>+
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: dsa: realtek: rtl8366rb: Switch to generic port_bridge* handlers
From: Luiz Angelo Daros de Luca @ 2026-07-03 13:24 UTC (permalink / raw)
To: Linus Walleij
Cc: Alvin Šipraga, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20260630-rtl8366rb-improvements-v2-2-05eb9d6a37f5@kernel.org>
> +static int rtl8366rb_port_set_isolation(struct realtek_priv *priv, int port,
> + u32 mask)
> +{
> + /* Bit 0 enables isolation so set this if we enable isolation
> + * any of the ports an clear it if we disable on all of them.
> + */
> + if (mask)
> + mask = RTL8366RB_PORT_ISO_PORTS(mask) | RTL8366RB_PORT_ISO_EN;
> +
> + return regmap_write(priv->map, RTL8366RB_PORT_ISO(port),
> + mask);
> +}
As sashiko pointed out, set_insolation(...,0) actually disables it
instead of completely isolating it.
I would unconditionally isolate the ports as we will never need to disable it.
Regards,
Luiz
^ permalink raw reply
* RE: [PATCH net-next 05/17] net: dsa: mv88e6xxx: Add conduit state change handler
From: Jagielski, Jedrzej @ 2026-07-03 13:17 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-5-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>From: Andrew Lunn <andrew@lunn.ch>
>
>When the conduit interface comes up, try to enable the RMU. Failing to
>enable the remote management unit is not fatal, not all chips support
>it, and some boards have chips which do support RMU, but with wrong
>port is connected to the CPU.
>
>When the conduit interface goes down, disable the RMU.
>
>Keep track of the conduit interface, so that RMU frames can be sent to
>it.
>
>Co-developed: Mattias Forsblad <mattias.forsblad@gmail.com>
>Signed-off-by: Mattias Forsblad <mattias.forsblad@gmail.com>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
...
>+++ b/drivers/net/dsa/mv88e6xxx/rmu.c
>@@ -0,0 +1,50 @@
>+// SPDX-License-Identifier: GPL-2.0-or-later
>+/*
>+ * Marvell 88E6xxx Switch Remote Management Unit Support
>+ *
>+ * Copyright (c) 2022 Mattias Forsblad <mattias.forsblad@gmail.com>
shouldn't present year be put here?
>+ *
>+ */
>+
>+#include <net/dsa.h>
>+#include "chip.h"
>+#include "global1.h"
>+#include "rmu.h"
>+
>+void mv88e6xxx_rmu_conduit_state_change(struct dsa_switch *ds,
>+ const struct net_device *conduit,
>+ bool operational)
>+{
>+ struct dsa_port *cpu_dp = conduit->dsa_ptr;
>+ struct mv88e6xxx_chip *chip = ds->priv;
>+ int port;
>+ int ret;
could be squashed
>+
>+ port = dsa_towards_port(ds, cpu_dp->ds->index, cpu_dp->index);
>+
>+ mv88e6xxx_reg_lock(chip);
>+
>+ if (operational && chip->info->ops->rmu_enable) {
>+ ret = chip->info->ops->rmu_enable(chip, port);
>+ if (ret == -EOPNOTSUPP) {
>+ dev_info(chip->dev, "RMU: not usable on this board");
do this case really needs to be treated different way if the general
case already prints error code?
>+ goto out;
>+ } else if (ret < 0) {
>+ dev_err(chip->dev, "RMU: unable to enable on port %d %pe",
>+ port, ERR_PTR(ret));
>+ goto out;
>+ }
>+
>+ WRITE_ONCE(chip->rmu_conduit, (struct net_device *)conduit);
>+
>+ dev_dbg(chip->dev, "RMU: Enabled on port %d", port);
>+ } else {
>+ if (chip->info->ops->rmu_disable)
>+ chip->info->ops->rmu_disable(chip);
>+
>+ WRITE_ONCE(chip->rmu_conduit, NULL);
>+ }
>+
>+out:
>+ mv88e6xxx_reg_unlock(chip);
>+}
>diff --git a/drivers/net/dsa/mv88e6xxx/rmu.h b/drivers/net/dsa/mv88e6xxx/rmu.h
>new file mode 100644
>index 0000000000000..71c4fc1d4113f
>--- /dev/null
>+++ b/drivers/net/dsa/mv88e6xxx/rmu.h
>@@ -0,0 +1,15 @@
>+/* SPDX-License-Identifier: GPL-2.0+ */
>+/*
>+ * Marvell 88E6xxx Switch Remote Management Unit Support
>+ *
>+ * Copyright (c) 2022 Mattias Forsblad <mattias.forsblad@gmail.com>
>+ *
>+ */
>+
>+#ifndef _MV88E6XXX_RMU_H_
>+#define _MV88E6XXX_RMU_H_
>+
>+void mv88e6xxx_rmu_conduit_state_change(struct dsa_switch *ds,
>+ const struct net_device *conduit,
>+ bool operational);
>+#endif /* _MV88E6XXX_RMU_H_ */
>
>--
>2.43.0
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] af_unix: Clean up error handling in unix_listen()
From: Christian Brauner @ 2026-07-03 13:17 UTC (permalink / raw)
To: John Ericson
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Kuniyuki Iwashima, John Ericson, Simon Horman, Christian Brauner,
David Rheinsberg, Cong Wang, Sergei Zimmerman, netdev,
linux-kernel
In-Reply-To: <20260703081416.2583118-3-John.Ericson@Obsidian.Systems>
> To avoid the sort of bug that was just fixed going forward, switch to a
> style where `err = -E...;` instead happens right before the `goto`.
> (`err = other_function(...);` is not changed.) Then there is no
> spooky-action-at-a-distance between the `err` initialization and the
> `goto`, something which is easier to slip by code review.
>
> Signed-off-by: John Ericson <mail@johnericson.me>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
--
Christian Brauner <brauner@kernel.org>
^ permalink raw reply
* Re: [PATCH net v2 2/3] selftests/net/af_unix: test listen() rejects wrong socket states
From: Christian Brauner @ 2026-07-03 13:17 UTC (permalink / raw)
To: John Ericson
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Kuniyuki Iwashima, John Ericson, Simon Horman, Christian Brauner,
David Rheinsberg, Cong Wang, Sergei Zimmerman, netdev,
linux-kernel
In-Reply-To: <20260703081416.2583118-2-John.Ericson@Obsidian.Systems>
> Add a regression test for the `unix_listen()` state check. The key case
> is `listen()` on a bound socket that has already been connected: it is
> no longer in `TCP_CLOSE` or `TCP_LISTEN`, so it must fail with `EINVAL`.
> A `prepare_peercred()` call slipped in ahead of that check once left
> `err` at 0 and made `listen()` silently succeed there instead; this
> guards against a repeat.
>
> The neighbouring outcomes are covered too so they cannot regress the
> same way: a bound socket in `TCP_CLOSE` listens fine, re-`listen()`ing a
> socket already in `TCP_LISTEN` is allowed, and an unbound socket fails
> with `EINVAL`.
>
> Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid")
> Signed-off-by: John Ericson <mail@johnericson.me>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
--
Christian Brauner <brauner@kernel.org>
^ permalink raw reply
* Re: [PATCH net v2 1/3] af_unix: fix listen() succeeding on sockets in the wrong state
From: Christian Brauner @ 2026-07-03 13:17 UTC (permalink / raw)
To: John Ericson
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Kuniyuki Iwashima, John Ericson, Simon Horman, Christian Brauner,
David Rheinsberg, Cong Wang, Sergei Zimmerman, netdev,
linux-kernel
In-Reply-To: <20260703081416.2583118-1-John.Ericson@Obsidian.Systems>
> Commit fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for
> reaped sk->sk_peer_pid") inserted a `prepare_peercred()` call between
> `err = -EINVAL` and the socket-state check in `unix_listen()`. Since
> `prepare_peercred()` leaves `err` at 0 on success, `listen()` on an
> AF_UNIX socket that is not in `TCP_CLOSE` or `TCP_LISTEN` state (e.g.
> one that is already connected) now silently returns success without
> doing anything, instead of failing with `EINVAL` as it did before.
>
> Fixes: fd0a109a0f6b ("net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid")
> Signed-off-by: John Ericson <mail@johnericson.me>
Reviewed-by: Christian Brauner (Amutable) <brauner@kernel.org>
--
Christian Brauner <brauner@kernel.org>
^ permalink raw reply
* Re: [PATCH 3/3] net: stmmac: dwmac-socfpga: Add mac-mode DT property support
From: Andrew Lunn @ 2026-07-03 13:15 UTC (permalink / raw)
To: Nazle Asmade, Muhammad Nazim Amirul
Cc: dinguyen@kernel.org, maxime.chevallier@bootlin.com,
rmk+kernel@armlinux.org.uk, krzk+dt@kernel.org,
conor+dt@kernel.org, robh@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
andrew+netdev@lunn.ch, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <f31704f2-cd98-481f-8290-203e3052b738@altera.com>
> > 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
> >
> Hi Maxime, Andrew
>
> Thanks for the reviews!
>
> Hi Andrew,
>
> The challenge with using compatible is that the TSN Config2 board has
> two ports — only gmac1 uses the GMII-to-RGMII converter, while gmac2
> connects directly to its PHY.
The two MACs are not compatible then, and each should have its own
compatible string. This is all in the SoC .dtsi file, so not really a
problem.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 2/5] net: dsa: realtek: rtl8366rb: Switch to generic port_bridge* handlers
From: Luiz Angelo Daros de Luca @ 2026-07-03 13:15 UTC (permalink / raw)
To: Linus Walleij
Cc: Alvin Šipraga, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20260630-rtl8366rb-improvements-v2-2-05eb9d6a37f5@kernel.org>
Em ter., 30 de jun. de 2026 às 08:19, Linus Walleij
<linusw@kernel.org> escreveu:
>
> The RTL8366RB is using its own sub-standard port isolation code.
>
> Implement the required isolation helpers, use these directly in
> the port setup callback, and switch over to the standard port
> isolation code.
>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v2 1/5] net: dsa: realtek: rtl83xx: Make learning optional in join/leave
From: Luiz Angelo Daros de Luca @ 2026-07-03 13:13 UTC (permalink / raw)
To: Linus Walleij
Cc: Alvin Šipraga, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev
In-Reply-To: <20260630-rtl8366rb-improvements-v2-1-05eb9d6a37f5@kernel.org>
> Mostly to make it possible to add rtl83xx support piece by piece,
> make the port learning callback optional in rtl83xx_port_bridge_join()
> and rtl83xx_port_bridge_leave().
>
> Signed-off-by: Linus Walleij <linusw@kernel.org>
I know it was already merged. Anyway
Reviewed-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
From: Andrew Lunn @ 2026-07-03 13:12 UTC (permalink / raw)
To: Nazle Asmade, Muhammad Nazim Amirul
Cc: dinguyen@kernel.org, maxime.chevallier@bootlin.com,
rmk+kernel@armlinux.org.uk, krzk+dt@kernel.org,
conor+dt@kernel.org, robh@kernel.org, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
andrew+netdev@lunn.ch, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <b8ca3bd8-af8f-43e7-904c-1ac45512296b@altera.com>
> >> The delays are provided by the FPGA GMII-to-RGMII converter soft IP,
> >> which is hardcoded in the FPGA bitstream and cannot be disabled or
> >> modified from the driver side.
> >>
> >> Using phy-mode = "rgmii" is intentional here — it prevents the PHY from
> >> adding its own internal delays on top, since the FPGA converter already
> >> provides the full required delay. This is consistent with how all other
> >> Agilex5 SoCDK board variants are described, as seen in commit
> >> c5637e5ceb4b ("arm64: dts: socfpga: agilex5: Fix phy-mode to rgmii as HW
> >> provides clock delay") already in Dinh Nguyen's tree, which applies the
> >> same rationale across all Agilex5 boards.
> >
> > I've become more insistent that designs get this correct. So i don't
> > care too much about past systems. Many vendors are having to fix up
> > their drivers and DT in order to make new boards consistent.
> >
> > You can look at your system as the FPGA being the MAC, and the PHY is
> > the PHY. The PCB is not providing the delay, the MAC is. This exactly
> > fits the description above.
> >
> > Andrew
> Hi Andrew,
>
> Thank you for the clarification. We agree with your framework in
> principle, but would like to explain why phy-mode = "rgmii" is the
> appropriate description for this specific case.
So you want to be different to every other system? Please extend the
text in that document to say that this device is special and has a
different definition of phy-mode to all other systems.
> After getting more information from hw team, for Agilex specific device,
> the RGMII timing delays on this board are provided by an FPGA delay
> chain (Input/Output Delay Chain primitives in the FPGA fabric). The
> reason for using the FPGA rather than the PHY is that the Marvell PHY on
> this board only supports 0ns or 2ns delay steps — too coarse to meet the
> RGMII timing requirements. The FPGA delay chain provides up to 63 steps
> of ~0.1ns precision, which the hardware team has tuned at design time to
> achieve correct signal timing.
As the text says, fine tuning is different. You can have fine tuning,
in both the MAC or PHY, while using either rgmii or rgmii-id.
Also, you cannot fine tune just the MAC, tuning needs to take into
account the PCB design, the length of the clock and data tracks on the
PCB. You can however take into account the difference in timing within
the FPGA.
Or does your FPGA team produce a different bitstream per board design,
after some sort of calibration in order to determine what the PCB
characteristics are?
This however opens up a new possibility. It does sound like you can
produce a new bitstream with the delays set to just the tuning delay,
not the 2ns + tuning? You need to decide if this is simpler than
changing the MAC driver to mask the phy-mode.
> Changing to phy-mode = "rgmii-id" and having
> the driver strip the delay before passing to the PHY would produce the
> same hardware behaviour (PHY adds zero delay), but would add driver
> complexity with no practical benefit, and would misrepresent the FPGA
> delay as a driver-managed MAC delay when it is actually a fixed,
> board-level hardware calibration.
Look at the wording again. It does not say it is driver managed.
# There are a small number of cases where the MAC has hard coded
# delays which cannot be disabled.
This exactly fits your situation.
> Could you advise if you still prefer the rgmii-id approach given this
> constraint?
rgmii-id is the correct value for your PCB design. Please follow what
the text says.
Andrew
^ permalink raw reply
* RE: [PATCH net-next 04/17] net: dsa: mv88e6xxx: Add RMU enable/disable for select switches.
From: Jagielski, Jedrzej @ 2026-07-03 13:07 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-4-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>From: Mattias Forsblad <mattias.forsblad@gmail.com>
>
>Add RMU enable and disable functionality for some Marvell SOHO
>switches.
>
>Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>Signed-off-by: Mattias Forsblad <mattias.forsblad@gmail.com>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>---
you tag should be the last one
>+int mv88e6085_g1_rmu_enable(struct mv88e6xxx_chip *chip, int port)
>+{
>+ int val = MV88E6352_G1_CTL2_RMU_MODE_DISABLED;
unclear for me why to init it if all allowed scenarios put some values into val?
here and for following
>+
>+ switch (port) {
>+ case 9:
>+ val = MV88E6085_G1_CTL2_RM_ENABLE;
>+ break;
>+ case 10:
>+ val = MV88E6085_G1_CTL2_RM_ENABLE | MV88E6085_G1_CTL2_P10RM;
>+ break;
>+ default:
>+ return -EOPNOTSUPP;
>+ }
>+
>+ return mv88e6xxx_g1_ctl2_mask(chip, MV88E6085_G1_CTL2_P10RM |
>+ MV88E6085_G1_CTL2_RM_ENABLE, val);
>+}
^ permalink raw reply
* RE: [PATCH net-next 03/17] net: dsa: tag_dsa: Add helper to add DSA header to RMU frame
From: Jagielski, Jedrzej @ 2026-07-03 13:06 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-3-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>From: Andrew Lunn <andrew@lunn.ch>
>
>A RMU frame sent to the switch needs a DSA header. Add a helper to the
>tag driver to add such a header to an skbuff, and provide access to
>the helper via the tagger data structure. This keeps most of the
>details of the DSA header in the tag driver.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
your tag is missing here; please check tags correctness over the whole series
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Michael Walle @ 2026-07-03 13:05 UTC (permalink / raw)
To: Miquel Raynal, Rob Herring
Cc: Manikandan.M, krzk, pratyush, mwalle, takahiro.kuwano, richard,
vigneshr, krzk+dt, conor+dt, srini, Nicolas.Ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, linux-mtd, devicetree, linux-kernel, linux-arm-kernel,
netdev
In-Reply-To: <8733y0penb.fsf@bootlin.com>
On Fri Jul 3, 2026 at 12:10 PM CEST, Miquel Raynal wrote:
> On 02/07/2026 at 11:37:23 -05, Rob Herring <robh@kernel.org> wrote:
>
>> On Thu, Jul 02, 2026 at 06:55:15AM +0000, Manikandan.M@microchip.com wrote:
>>> Hi Krzysztof,
>>>
>>> On 7/2/26 11:46 AM, Krzysztof Kozlowski wrote:
>>> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>>> >
>>> > On Tue, Jun 30, 2026 at 02:54:00PM +0530, Manikandan Muralidharan wrote:
>>> >> Add an optional "sfdp" child node (compatible "jedec,sfdp") that
>>> >> describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
>>> >
>>> > What is SFDP?
>>> >
>>> SFDP is the Serial Flash Discoverable Parameters -- a JEDEC-standardised
>>> (JESD216) read-only parameter table present in most SPI NOR flashes, the
>>> table contents provide basic information about the flash. There are
>>> standard tables which are specified by the JEDEC standard and there are
>>> vendor tables.
>>
>> Is SFDP present or not discoverable? Or we have a table of discoverable
>> parameters that itself is not discoverable.
>
> SFDP is almost always there. I don't think there are any non SFDP chips
> manufactured today (?).
Oh i bet there are, and IIRC there were some additions lately. Not
sure if the chip was new though.
> The thing is, even if we don't need to define it
> in DT, we might need to point to it in order to extract eg. a unique ID
> or a MAC address through the NVMEM interface.
Exactly. We can detect whether is a SFDP table or not, by trying to
read its signature using the RDSFDP opcode. But as Miquel pointed
out, that's not what this is about. For the nvmem part being useful,
we have to have some node to point to. At the moment, there are
three different kind of NVMEM devices an spi nor flash can create:
- partitions
- factory OTP (i.e. OTP by the flash manufacturer)
- user OTP (i.e. what an OEM could write to)
Now there's a fourth one: SFDP. It can contain vendor specific
tables, which in the mchp case is used to store a mac address,
which is then used for a NIC.
So we somehow has to organize all of them, thus the sfdp node. A
more complete example would be:
flash@0 {
compatible = "jedec,spi-nor";
partitions {
compatible = "fixed-partitions";
partition@0 {
compatible = "nvmem-cells";
};
};
otp-1 {
compatible = "factory-otp";
};
otp-2 {
compatible = "user-otp";
};
sfdp {
compatile = "jedec,sfdp";
};
};
All being NVMEM devices and expose some kind of data used for
drivers.
HTH
-michael
> SFDP is split into several sub-tables, the first one is mandatory, but
> then there are optional tables which can be discovered dynamically.
>
> Thanks,
> Miquèl
^ permalink raw reply
* RE: [PATCH net-next 02/17] net: dsa: mv88e6xxx: Introduce Marvell dsa tagger data operation.
From: Jagielski, Jedrzej @ 2026-07-03 13:04 UTC (permalink / raw)
To: Luke Howard, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Russell King, Richard Cochran, Florian Fainelli
Cc: Cedric Jehasse, Max Holtmann, Max Hunter, Tyrrell, Kieran,
Ryan Wilkins, Mattias Forsblad, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260703-net-next-mv88e6xxx-rmu-v1-2-991a27d78bca@padl.com>
From: Luke Howard <lukeh@padl.com>
Sent: Friday, July 3, 2026 9:47 AM
>From: Mattias Forsblad <mattias.forsblad@gmail.com>
>
>Support connecting Marvell dsa tagger to the switch driver frame2reg
>function to decode received RMU frames.
>
>(Note: during teardown or failed setup, tagger_data may be NULL when
>a late FRAME2REG frame arrives.)
>
>Signed-off-by: Luke Howard <lukeh@padl.com>
>Signed-off-by: Mattias Forsblad <mattias.forsblad@gmail.com>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Hi,
i believe your sob tag should be the last one
^ permalink raw reply
* [PATCH net 9/9] netfilter: xt_connmark: reject invalid shift parameters
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Wyatt Feng <bronzed_45_vested@icloud.com>
Revision 2 of the CONNMARK target accepts user-controlled shift
parameters and applies them to 32-bit mark values in
connmark_tg_shift().
A shift_bits value of 32 or more triggers an undefined-shift bug when
the rule is evaluated. Invalid shift_dir values are also accepted and
silently fall back to the left-shift path.
Reject invalid revision-2 shift parameters in connmark_tg_check() so
malformed rules fail at installation time, before they can reach the
packet path.
Fixes: 472a73e00757 ("netfilter: xt_conntrack: Support bit-shifting for CONNMARK & MARK targets.")
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <dstsmallbird@foxmail.com>
Assisted-by: Codex:GPT-5.4
Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com>
Reviewed-by: Ren Wei <enjou1224z@gmail.com>
Reviewed-by: Phil Sutter <phil@nwl.cc>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/xt_connmark.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_connmark.c b/net/netfilter/xt_connmark.c
index 4277084de2e7..2cf27f7d59b9 100644
--- a/net/netfilter/xt_connmark.c
+++ b/net/netfilter/xt_connmark.c
@@ -112,6 +112,16 @@ static int connmark_tg_check(const struct xt_tgchk_param *par)
return ret;
}
+static int connmark_tg_check_v2(const struct xt_tgchk_param *par)
+{
+ const struct xt_connmark_tginfo2 *info = par->targinfo;
+
+ if (info->shift_dir > D_SHIFT_RIGHT || info->shift_bits >= 32)
+ return -EINVAL;
+
+ return connmark_tg_check(par);
+}
+
static void connmark_tg_destroy(const struct xt_tgdtor_param *par)
{
nf_ct_netns_put(par->net, par->family);
@@ -162,7 +172,7 @@ static struct xt_target connmark_tg_reg[] __read_mostly = {
.name = "CONNMARK",
.revision = 2,
.family = NFPROTO_IPV4,
- .checkentry = connmark_tg_check,
+ .checkentry = connmark_tg_check_v2,
.target = connmark_tg_v2,
.targetsize = sizeof(struct xt_connmark_tginfo2),
.destroy = connmark_tg_destroy,
@@ -183,7 +193,7 @@ static struct xt_target connmark_tg_reg[] __read_mostly = {
.name = "CONNMARK",
.revision = 2,
.family = NFPROTO_IPV6,
- .checkentry = connmark_tg_check,
+ .checkentry = connmark_tg_check_v2,
.target = connmark_tg_v2,
.targetsize = sizeof(struct xt_connmark_tginfo2),
.destroy = connmark_tg_destroy,
--
2.54.0
^ permalink raw reply related
* [PATCH net 8/9] ipvs: reset full ip_vs_seq structs in ip_vs_conn_new
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Commit 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in
ip_vs_conn_new") changed ip_vs_conn_new() to allocate an ip_vs_conn
object with kmem_cache_alloc(). The function then initializes many
fields explicitly, but only resets in_seq.delta and out_seq.delta in the
two struct ip_vs_seq members.
That leaves init_seq and previous_delta uninitialized. This is normally
harmless while the corresponding IP_VS_CONN_F_IN_SEQ or
IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync
message, however, ip_vs_proc_conn() preserves those flags from
IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits
IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with
SEQ flags set but with the rest of in_seq/out_seq still containing stale
slab data.
When a packet for such a connection is later handled by an IPVS
application helper, vs_fix_seq() and vs_fix_ack_seq() use
previous_delta and init_seq to rewrite TCP sequence numbers. A malformed
sync message can therefore make forwarded packets carry stale slab bytes
in their TCP seq/ack numbers, and can also corrupt the forwarded TCP
flow.
Reset both struct ip_vs_seq members completely before publishing the
connection. This matches the existing "reset struct ip_vs_seq" comment
and keeps the sequence-adjustment gates inactive unless valid sequence
data is installed later.
Fixes: 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude-Code:GLM-5.2
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/ipvs/ip_vs_conn.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c
index cb36641f8d1c..6ed2622363f0 100644
--- a/net/netfilter/ipvs/ip_vs_conn.c
+++ b/net/netfilter/ipvs/ip_vs_conn.c
@@ -1420,8 +1420,8 @@ ip_vs_conn_new(const struct ip_vs_conn_param *p, int dest_af,
cp->app = NULL;
cp->app_data = NULL;
/* reset struct ip_vs_seq */
- cp->in_seq.delta = 0;
- cp->out_seq.delta = 0;
+ memset(&cp->in_seq, 0, sizeof(cp->in_seq));
+ memset(&cp->out_seq, 0, sizeof(cp->out_seq));
if (unlikely(flags & IP_VS_CONN_F_NO_CPORT)) {
int af_id = ip_vs_af_index(cp->af);
--
2.54.0
^ permalink raw reply related
* [PATCH net 7/9] ipvs: fix PMTU for GUE/GRE tunnel ICMP errors
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
When an ICMP Fragmentation Needed error is received for a tunneled IPVS
connection, ip_vs_in_icmp() recomputes the MTU that the original packet
can use by subtracting the tunnel overhead from the reported next-hop
MTU.
The current code always subtracts sizeof(struct iphdr), which is only
the IPIP overhead. For GUE and GRE tunnels, ipvs_udp_decap() and
ipvs_gre_decap() already compute the additional tunnel header length,
but that value is scoped to the decapsulation block and is lost before
the ICMP_FRAG_NEEDED handling. As a result, the ICMP error sent back to
the client advertises an MTU that is too large, so PMTUD can fail to
converge for GUE/GRE-tunneled real servers.
With a reported next-hop MTU of 1400, a GUE tunnel currently returns
1380 to the client. The correct value is 1368:
1400 - sizeof(struct iphdr) - sizeof(struct udphdr) -
sizeof(struct guehdr)
Hoist the tunnel header length into the main ip_vs_in_icmp() scope and
subtract sizeof(struct iphdr) + ulen in the Fragmentation Needed path.
The IPIP path keeps ulen as 0, so its existing 1400 - 20 = 1380 result
is unchanged.
Fixes: 508f744c0de3 ("ipvs: strip udp tunnel headers from icmp errors")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude-Code:GLM-5.2
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/ipvs/ip_vs_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index d40b404c1bf6..906f2c361676 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1767,6 +1767,7 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
bool tunnel, new_cp = false;
union nf_inet_addr *raddr;
char *outer_proto = "IPIP";
+ int ulen = 0;
*related = 1;
@@ -1831,7 +1832,6 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
/* Error for our tunnel must arrive at LOCAL_IN */
(skb_rtable(skb)->rt_flags & RTCF_LOCAL)) {
__u8 iproto;
- int ulen;
/* Non-first fragment has no UDP/GRE header */
if (unlikely(cih->frag_off & htons(IP_OFFSET)))
@@ -1936,8 +1936,8 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
if (dest_dst)
mtu = dst_mtu(dest_dst->dst_cache);
}
- if (mtu > 68 + sizeof(struct iphdr))
- mtu -= sizeof(struct iphdr);
+ if (mtu > 68 + sizeof(struct iphdr) + ulen)
+ mtu -= sizeof(struct iphdr) + ulen;
info = htonl(mtu);
}
/* Strip outer IP, ICMP and IPIP/UDP/GRE, go to IP header of
--
2.54.0
^ permalink raw reply related
* [PATCH net 6/9] netfilter: nft_set_rbtree: get command skips end element with open interval
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Pablo Neira Ayuso <pablo@netfilter.org>
The get command on intervals provide partial matches such as subranges
for usability reasons. However, an open interval has no closing end
element. If the closing element matches within the range of the open
internal, ie. its closest match is the start element of the open range,
then, return 0 but offer no matching element to userspace through
netlink as a special case. Userspace provides at least a matching start
element in this case and the closing end element matching the open
interal is ignored.
Another possibility is to report the matching start element of the open
interval for this end interval. However, this results in duplicated
matching being listed in userspace because userspace does not expect a
start element as response to a end element.
Fixes: 2aa34191f06f ("netfilter: nft_set_rbtree: use binary search array in get command")
Reported-by: Melbin K Mathew <mlbnkm1@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/nf_tables_api.c | 3 +++
net/netfilter/nft_set_rbtree.c | 8 ++++++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 4884f7f7aaee..a9eaf9455c77 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -6563,6 +6563,9 @@ static int nft_get_set_elem(struct nft_ctx *ctx, const struct nft_set *set,
if (err < 0)
return err;
+ if (!elem.priv)
+ return 0;
+
err = -ENOMEM;
skb = nlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC);
if (skb == NULL)
diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
index 018bbb6df4ce..6222e9bb57bc 100644
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -184,10 +184,14 @@ nft_rbtree_get(const struct net *net, const struct nft_set *set,
if (!interval || nft_set_elem_expired(interval->from))
return ERR_PTR(-ENOENT);
- if (flags & NFT_SET_ELEM_INTERVAL_END)
+ if (flags & NFT_SET_ELEM_INTERVAL_END) {
+ if (!interval->to)
+ return NULL;
+
rbe = container_of(interval->to, struct nft_rbtree_elem, ext);
- else
+ } else {
rbe = container_of(interval->from, struct nft_rbtree_elem, ext);
+ }
return &rbe->priv;
}
--
2.54.0
^ permalink raw reply related
* [PATCH net 5/9] netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Zhixing Chen <running910@gmail.com>
The ah, hbh and rt matches check that the fixed extension header is
present, then use the header length field to derive the advertised
extension header length for matching.
For the ah match, add the missing advertised-length check. For hbh
and rt, update the existing advertised-length checks. In all three
cases, set hotdrop to true before returning false when the advertised
extension header length exceeds the available skb data.
Returning false treats the packet as a rule mismatch. Set hotdrop to
true and drop malformed packets so they cannot bypass rules intended
to drop packets with these IPv6 extension headers.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Zhixing Chen <running910@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/ipv6/netfilter/ip6t_ah.c | 5 +++++
net/ipv6/netfilter/ip6t_hbh.c | 1 +
net/ipv6/netfilter/ip6t_rt.c | 3 ++-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/netfilter/ip6t_ah.c b/net/ipv6/netfilter/ip6t_ah.c
index 70da2f2ce064..1258783ed876 100644
--- a/net/ipv6/netfilter/ip6t_ah.c
+++ b/net/ipv6/netfilter/ip6t_ah.c
@@ -56,6 +56,11 @@ static bool ah_mt6(const struct sk_buff *skb, struct xt_action_param *par)
}
hdrlen = ipv6_authlen(ah);
+ if (skb->len - ptr < hdrlen) {
+ /* Packet smaller than its length field */
+ par->hotdrop = true;
+ return false;
+ }
pr_debug("IPv6 AH LEN %u %u ", hdrlen, ah->hdrlen);
pr_debug("RES %04X ", ah->reserved);
diff --git a/net/ipv6/netfilter/ip6t_hbh.c b/net/ipv6/netfilter/ip6t_hbh.c
index 450dd53846a2..6d1a5d2026a6 100644
--- a/net/ipv6/netfilter/ip6t_hbh.c
+++ b/net/ipv6/netfilter/ip6t_hbh.c
@@ -75,6 +75,7 @@ hbh_mt6(const struct sk_buff *skb, struct xt_action_param *par)
hdrlen = ipv6_optlen(oh);
if (skb->len - ptr < hdrlen) {
/* Packet smaller than it's length field */
+ par->hotdrop = true;
return false;
}
diff --git a/net/ipv6/netfilter/ip6t_rt.c b/net/ipv6/netfilter/ip6t_rt.c
index 5561bd9cea81..278b52752f36 100644
--- a/net/ipv6/netfilter/ip6t_rt.c
+++ b/net/ipv6/netfilter/ip6t_rt.c
@@ -56,7 +56,8 @@ static bool rt_mt6(const struct sk_buff *skb, struct xt_action_param *par)
hdrlen = ipv6_optlen(rh);
if (skb->len - ptr < hdrlen) {
- /* Pcket smaller than its length field */
+ /* Packet smaller than its length field */
+ par->hotdrop = true;
return false;
}
--
2.54.0
^ permalink raw reply related
* [PATCH net 4/9] netfilter: nfnetlink_cthelper: cap to maximum number of expectation per master on updates
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Really cap it to NF_CT_EXPECT_MAX_CNT (255) on updates.
The commit ("netfilter: nfnetlink_cthelper: cap to maximum number of
expectation per master") only covers creation of helpers, not updates.
Fixes: 397c8300972f ("netfilter: nf_conntrack_helper: cap maximum number of expectation at helper registration")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/nfnetlink_cthelper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/netfilter/nfnetlink_cthelper.c b/net/netfilter/nfnetlink_cthelper.c
index 2cbcca9110db..f062ac210343 100644
--- a/net/netfilter/nfnetlink_cthelper.c
+++ b/net/netfilter/nfnetlink_cthelper.c
@@ -316,6 +316,8 @@ nfnl_cthelper_update_policy_one(const struct nf_conntrack_expect_policy *policy,
new_policy->max_expected =
ntohl(nla_get_be32(tb[NFCTH_POLICY_EXPECT_MAX]));
+ if (!new_policy->max_expected)
+ new_policy->max_expected = NF_CT_EXPECT_MAX_CNT;
if (new_policy->max_expected > NF_CT_EXPECT_MAX_CNT)
return -EINVAL;
--
2.54.0
^ permalink raw reply related
* [PATCH net 3/9] netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Feng Wu <wufengwufengwufeng@gmail.com>
On links faster than ~34 Gbps, where byte rate may exceed 2^32-1
(~ 4.3 GBps), the comparison result becomes incorrect because the
truncated value no longer reflects the actual estimator rate.
Fix by changing the local variables to u64.
Fixes: 1c0d32fde5bd ("net_sched: gen_estimator: complete rewrite of rate estimators")
Signed-off-by: Feng Wu <wufengwufengwufeng@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/xt_rateest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netfilter/xt_rateest.c b/net/netfilter/xt_rateest.c
index b1d736c15fcb..7c05b6342578 100644
--- a/net/netfilter/xt_rateest.c
+++ b/net/netfilter/xt_rateest.c
@@ -16,7 +16,7 @@ xt_rateest_mt(const struct sk_buff *skb, struct xt_action_param *par)
{
const struct xt_rateest_match_info *info = par->matchinfo;
struct gnet_stats_rate_est64 sample = {0};
- u_int32_t bps1, bps2, pps1, pps2;
+ u64 bps1, bps2, pps1, pps2;
bool ret = true;
gen_estimator_read(&info->est1->rate_est, &sample);
--
2.54.0
^ permalink raw reply related
* [PATCH net 2/9] netfilter: xt_u32: reject invalid shift counts
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
From: Wyatt Feng <bronzed_45_vested@icloud.com>
u32_match_it() executes rule-supplied shift operands on a 32-bit
value. A malformed u32 rule can provide a shift count of 32 or more,
triggering an undefined shift out-of-bounds during packet evaluation.
Validate XT_U32_LEFTSH and XT_U32_RIGHTSH operands in
u32_mt_checkentry() and reject malformed rules before they reach the
packet path.
Fixes: 1b50b8a371e9 ("[NETFILTER]: Add u32 match")
Reported-by: Yuan Tan <yuantan098@gmail.com>
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Reported-by: Zhengchuan Liang <zcliangcn@gmail.com>
Reported-by: Xin Liu <bird@lzu.edu.cn>
Assisted-by: Codex:GPT-5.4
Signed-off-by: Wyatt Feng <bronzed_45_vested@icloud.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/xt_u32.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/netfilter/xt_u32.c b/net/netfilter/xt_u32.c
index 117d4615d668..ec1a21e3b6e2 100644
--- a/net/netfilter/xt_u32.c
+++ b/net/netfilter/xt_u32.c
@@ -100,7 +100,7 @@ static int u32_mt_checkentry(const struct xt_mtchk_param *par)
{
const struct xt_u32 *data = par->matchinfo;
const struct xt_u32_test *ct;
- unsigned int i;
+ unsigned int i, j;
if (data->ntests > ARRAY_SIZE(data->tests))
return -EINVAL;
@@ -111,6 +111,16 @@ static int u32_mt_checkentry(const struct xt_mtchk_param *par)
if (ct->nnums > ARRAY_SIZE(ct->location) ||
ct->nvalues > ARRAY_SIZE(ct->value))
return -EINVAL;
+
+ for (j = 1; j < ct->nnums; ++j) {
+ switch (ct->location[j].nextop) {
+ case XT_U32_LEFTSH:
+ case XT_U32_RIGHTSH:
+ if (ct->location[j].number >= 32)
+ return -EINVAL;
+ break;
+ }
+ }
}
return 0;
--
2.54.0
^ permalink raw reply related
* [PATCH net 1/9] netfilter: nf_nat_sip: reload possible stale data pointer
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
In-Reply-To: <20260703125709.16493-1-fw@strlen.de>
quoting sashiko:
------------------------------------------------------------------------
[..] noticed a potential memory bug and header corruption involving the
SIP NAT helper.
In net/netfilter/nf_nat_sip.c:nf_nat_sip():
if (skb_ensure_writable(skb, skb->len)) {
nf_ct_helper_log(skb, ct, "cannot mangle packet");
return NF_DROP;
}
uh = (void *)skb->data + protoff;
uh->dest = ct_sip_info->forced_dport;
if (!nf_nat_mangle_udp_packet(skb, ct, ctinfo, protoff,
0, 0, NULL, 0)) {
If a cloned or fragmented SKB is reallocated by skb_ensure_writable(), the
old data buffer is freed. However, nf_nat_sip() fails to update *dptr to
point to the new buffer.
It also appears to use nf_nat_mangle_udp_packet() on what could be a TCP
packet, which would overwrite the sequence number with a checksum update.
------------------------------------------------------------------------
nf_conntrack_sip linerizes skbs, hence no fragmented skb can be seen.
But clones are possible, so rebuild dptr.
Disable nf_nat_mangle_udp_packet() branch for TCP streams.
It doesn't look like this can ever happen, else we should have received
bug reports about this, so just check the conntrack is UDP and drop
otherwise.
The calling conntrack_sip set ->forced_dport for SIP_HDR_VIA_UDP messages,
so I don't think this is ever expected to be true for a TCP stream.
Fixes: 7266507d8999 ("netfilter: nf_ct_sip: support Cisco 7941/7945 IP phones")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Florian Westphal <fw@strlen.de>
---
net/netfilter/nf_nat_sip.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/net/netfilter/nf_nat_sip.c b/net/netfilter/nf_nat_sip.c
index 67c04d8143ab..aea02f6aff09 100644
--- a/net/netfilter/nf_nat_sip.c
+++ b/net/netfilter/nf_nat_sip.c
@@ -289,13 +289,24 @@ static unsigned int nf_nat_sip(struct sk_buff *skb, unsigned int protoff,
/* Mangle destination port for Cisco phones, then fix up checksums */
if (dir == IP_CT_DIR_REPLY && ct_sip_info->forced_dport) {
+ int doff = *dptr - (const char *)skb->data;
struct udphdr *uh;
+ if (doff <= 0) {
+ DEBUG_NET_WARN_ON_ONCE(1);
+ return NF_DROP;
+ }
+
+ /* ct_sip_info->forced_dport only expected with UDP */
+ if (nf_ct_protonum(ct) != IPPROTO_UDP)
+ return NF_DROP;
+
if (skb_ensure_writable(skb, skb->len)) {
nf_ct_helper_log(skb, ct, "cannot mangle packet");
return NF_DROP;
}
+ *dptr = skb->data + doff;
uh = (void *)skb->data + protoff;
uh->dest = ct_sip_info->forced_dport;
--
2.54.0
^ permalink raw reply related
* [PATCH net 0/9] netfilter: updates for net
From: Florian Westphal @ 2026-07-03 12:57 UTC (permalink / raw)
To: netdev
Cc: Paolo Abeni, David S. Miller, Eric Dumazet, Jakub Kicinski,
netfilter-devel, pablo
Hi,
The following patchset contains Netfilter fixes for *net*, all
for ancient problems. Patch 7 raised drive-by sashiko findings,
but those are not related to the change itself.
1) Rebuild the nf_nat_sip data pointer to prevent stale access after SKB
reallocation. Restrict UDP mangling to UDP streams to avoid TCP packet
corruption.
2) Prevent undefined behavior in xt_u32 caused by invalid shift counts.
From Wyatt Feng.
3) Use u64 variables to prevent incorrect comparisons on links exceeding
34 Gbps in xt_rateest. From Feng Wu.
4) Cap the number of expectations per master during nfnetlink_cthelper
updates. From Pablo Neira Ayuso.
5) Mark malformed IPv6 extension headers for hotdrop in ip6tables.
From Zhixing Chen.
6) Skip the end element of an open interval during the get command when its
closest match is the interval's start element. Also from Pablo Neira Ayuso.
7) Fix PMTU calculation for GUE/GRE tunnels in IPVS during ICMP fragmentation
error handling. Include additional tunnel header length when computing the
new MTU. From Yizhou Zhao.
8) Reset full ip_vs_seq structures in ip_vs_conn_new. Also from Yizhou Zhao.
9) Reject invalid shift parameters in xt_connmark. Also from Wyatt Feng.
Please, pull these changes from:
The following changes since commit d335dcc6f521571d57117b8deeebc940836e5450:
gue: validate REMCSUM private option length (2026-07-03 09:34:53 +0100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf.git tags/nf-26-07-03
for you to fetch changes up to 1b47026fb4b35bac850ad6e8a4ad7fc018e09ebc:
netfilter: xt_connmark: reject invalid shift parameters (2026-07-03 14:45:21 +0200)
----------------------------------------------------------------
netfilter pull request nf-26-07-03
----------------------------------------------------------------
Feng Wu (1):
netfilter: xt_rateest: fix u64 truncation in xt_rateest_mt()
Florian Westphal (1):
netfilter: nf_nat_sip: reload possible stale data pointer
Pablo Neira Ayuso (2):
netfilter: nfnetlink_cthelper: cap to maximum number of expectation
per master on updates
netfilter: nft_set_rbtree: get command skips end element with open
interval
Wyatt Feng (2):
netfilter: xt_u32: reject invalid shift counts
netfilter: xt_connmark: reject invalid shift parameters
Yizhou Zhao (2):
ipvs: fix PMTU for GUE/GRE tunnel ICMP errors
ipvs: reset full ip_vs_seq structs in ip_vs_conn_new
Zhixing Chen (1):
netfilter: ip6tables: mark malformed IPv6 extension headers for hotdrop
net/ipv6/netfilter/ip6t_ah.c | 5 +++++
net/ipv6/netfilter/ip6t_hbh.c | 1 +
net/ipv6/netfilter/ip6t_rt.c | 3 ++-
net/netfilter/ipvs/ip_vs_conn.c | 4 ++--
net/netfilter/ipvs/ip_vs_core.c | 6 +++---
net/netfilter/nf_nat_sip.c | 11 +++++++++++
net/netfilter/nf_tables_api.c | 3 +++
net/netfilter/nfnetlink_cthelper.c | 2 ++
net/netfilter/nft_set_rbtree.c | 8 ++++++--
net/netfilter/xt_connmark.c | 14 ++++++++++++--
net/netfilter/xt_rateest.c | 2 +-
net/netfilter/xt_u32.c | 12 +++++++++++-
12 files changed, 59 insertions(+), 12 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH] net : bonding : Remove TODO comment about retrying setting the MAC
From: Paritosh Potukuchi @ 2026-07-03 12:55 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, jv, paritosh.potukuchi, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
As correctly pointed out by Jay Vosburgh,
"This comment dates to sometime before git, when it was common for
network device drivers to lack the ability to change the MAC while the
interface is up. To the best of my knowledge, that isn't a issue
today."
Based on the discussion in the RFC linked below, I am removing the
TODO.
Link to the RFC:
https://lore.kernel.org/netdev/2001256.1782860341@famine/T/#t
Signed-off-by: Paritosh Potukuchi <paritosh.potukuchi@amd.com>
---
drivers/net/bonding/bond_main.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index d2e4dae4e97c..d5c19dc4bc07 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4865,12 +4865,6 @@ static int bond_set_mac_address(struct net_device *bond_dev, void *addr)
__func__, slave);
res = dev_set_mac_address(slave->dev, addr, NULL);
if (res) {
- /* TODO: consider downing the slave
- * and retry ?
- * User should expect communications
- * breakage anyway until ARP finish
- * updating, so...
- */
slave_dbg(bond_dev, slave->dev, "%s: err %d\n",
__func__, res);
goto unwind;
--
2.43.0
^ permalink raw reply related
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