* [PATCH net-next v2 2/5] dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
From: Ivan Vecera @ 2026-03-28 8:06 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Prathosh Satish, Arkadiusz Kubalewski, Jiri Pirko,
Michal Schmidt, Simon Horman, Vadim Fedorenko, linux-kernel,
Conor Dooley, Krzysztof Kozlowski, Rob Herring, devicetree,
Pasi Vaananen
In-Reply-To: <20260328080624.593916-1-ivecera@redhat.com>
Replace open-coded clear-and-set bitfield operations with
FIELD_MODIFY().
Reviewed-by: Petr Oros <poros@redhat.com>
Reviewed-by: Prathosh Satish <Prathosh.Satish@microchip.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/chan.h | 17 ++++++-----------
drivers/dpll/zl3073x/core.c | 3 +--
drivers/dpll/zl3073x/flash.c | 3 +--
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/dpll/zl3073x/chan.h b/drivers/dpll/zl3073x/chan.h
index e0f02d3432086..481da2133202b 100644
--- a/drivers/dpll/zl3073x/chan.h
+++ b/drivers/dpll/zl3073x/chan.h
@@ -66,8 +66,7 @@ static inline u8 zl3073x_chan_ref_get(const struct zl3073x_chan *chan)
*/
static inline void zl3073x_chan_mode_set(struct zl3073x_chan *chan, u8 mode)
{
- chan->mode_refsel &= ~ZL_DPLL_MODE_REFSEL_MODE;
- chan->mode_refsel |= FIELD_PREP(ZL_DPLL_MODE_REFSEL_MODE, mode);
+ FIELD_MODIFY(ZL_DPLL_MODE_REFSEL_MODE, &chan->mode_refsel, mode);
}
/**
@@ -77,8 +76,7 @@ static inline void zl3073x_chan_mode_set(struct zl3073x_chan *chan, u8 mode)
*/
static inline void zl3073x_chan_ref_set(struct zl3073x_chan *chan, u8 ref)
{
- chan->mode_refsel &= ~ZL_DPLL_MODE_REFSEL_REF;
- chan->mode_refsel |= FIELD_PREP(ZL_DPLL_MODE_REFSEL_REF, ref);
+ FIELD_MODIFY(ZL_DPLL_MODE_REFSEL_REF, &chan->mode_refsel, ref);
}
/**
@@ -110,13 +108,10 @@ zl3073x_chan_ref_prio_set(struct zl3073x_chan *chan, u8 ref, u8 prio)
{
u8 *val = &chan->ref_prio[ref / 2];
- if (!(ref & 1)) {
- *val &= ~ZL_DPLL_REF_PRIO_REF_P;
- *val |= FIELD_PREP(ZL_DPLL_REF_PRIO_REF_P, prio);
- } else {
- *val &= ~ZL_DPLL_REF_PRIO_REF_N;
- *val |= FIELD_PREP(ZL_DPLL_REF_PRIO_REF_N, prio);
- }
+ if (!(ref & 1))
+ FIELD_MODIFY(ZL_DPLL_REF_PRIO_REF_P, val, prio);
+ else
+ FIELD_MODIFY(ZL_DPLL_REF_PRIO_REF_N, val, prio);
}
/**
diff --git a/drivers/dpll/zl3073x/core.c b/drivers/dpll/zl3073x/core.c
index 6363002d48d46..7eebfc1ad1019 100644
--- a/drivers/dpll/zl3073x/core.c
+++ b/drivers/dpll/zl3073x/core.c
@@ -743,8 +743,7 @@ int zl3073x_dev_phase_avg_factor_set(struct zl3073x_dev *zldev, u8 factor)
value = (factor + 1) & 0x0f;
/* Update phase measurement control register */
- dpll_meas_ctrl &= ~ZL_DPLL_MEAS_CTRL_AVG_FACTOR;
- dpll_meas_ctrl |= FIELD_PREP(ZL_DPLL_MEAS_CTRL_AVG_FACTOR, value);
+ FIELD_MODIFY(ZL_DPLL_MEAS_CTRL_AVG_FACTOR, &dpll_meas_ctrl, value);
rc = zl3073x_write_u8(zldev, ZL_REG_DPLL_MEAS_CTRL, dpll_meas_ctrl);
if (rc)
return rc;
diff --git a/drivers/dpll/zl3073x/flash.c b/drivers/dpll/zl3073x/flash.c
index 83452a77e3e98..f85535c8ad246 100644
--- a/drivers/dpll/zl3073x/flash.c
+++ b/drivers/dpll/zl3073x/flash.c
@@ -194,8 +194,7 @@ zl3073x_flash_cmd_wait(struct zl3073x_dev *zldev, u32 operation,
if (rc)
return rc;
- value &= ~ZL_WRITE_FLASH_OP;
- value |= FIELD_PREP(ZL_WRITE_FLASH_OP, operation);
+ FIELD_MODIFY(ZL_WRITE_FLASH_OP, &value, operation);
rc = zl3073x_write_u8(zldev, ZL_REG_WRITE_FLASH, value);
if (rc)
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v2 1/5] dpll: zl3073x: clean up esync get/set and use zl3073x_out_is_ndiv()
From: Ivan Vecera @ 2026-03-28 8:06 UTC (permalink / raw)
To: netdev
Cc: Petr Oros, Prathosh Satish, Arkadiusz Kubalewski, Jiri Pirko,
Michal Schmidt, Simon Horman, Vadim Fedorenko, linux-kernel,
Conor Dooley, Krzysztof Kozlowski, Rob Herring, devicetree,
Pasi Vaananen
In-Reply-To: <20260328080624.593916-1-ivecera@redhat.com>
Return -EOPNOTSUPP early in esync_get callbacks when esync is not
supported instead of conditionally populating the range at the end.
This simplifies the control flow by removing the finish label/goto
in the output variant and the conditional range assignment in both
input and output variants.
Replace open-coded N-div signal format switch statements with
zl3073x_out_is_ndiv() helper in esync_get, esync_set and
frequency_set callbacks.
Reviewed-by: Petr Oros <poros@redhat.com>
Reviewed-by: Prathosh Satish <Prathosh.Satish@microchip.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/dpll/zl3073x/dpll.c | 64 ++++++++++++-------------------------
1 file changed, 20 insertions(+), 44 deletions(-)
diff --git a/drivers/dpll/zl3073x/dpll.c b/drivers/dpll/zl3073x/dpll.c
index a29f606318f6d..2476c14028210 100644
--- a/drivers/dpll/zl3073x/dpll.c
+++ b/drivers/dpll/zl3073x/dpll.c
@@ -131,6 +131,12 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
ref_id = zl3073x_input_pin_ref_get(pin->id);
ref = zl3073x_ref_state_get(zldev, ref_id);
+ if (!pin->esync_control || zl3073x_ref_freq_get(ref) <= 1)
+ return -EOPNOTSUPP;
+
+ esync->range = esync_freq_ranges;
+ esync->range_num = ARRAY_SIZE(esync_freq_ranges);
+
switch (FIELD_GET(ZL_REF_SYNC_CTRL_MODE, ref->sync_ctrl)) {
case ZL_REF_SYNC_CTRL_MODE_50_50_ESYNC_25_75:
esync->freq = ref->esync_n_div == ZL_REF_ESYNC_DIV_1HZ ? 1 : 0;
@@ -142,17 +148,6 @@ zl3073x_dpll_input_pin_esync_get(const struct dpll_pin *dpll_pin,
break;
}
- /* If the pin supports esync control expose its range but only
- * if the current reference frequency is > 1 Hz.
- */
- if (pin->esync_control && zl3073x_ref_freq_get(ref) > 1) {
- esync->range = esync_freq_ranges;
- esync->range_num = ARRAY_SIZE(esync_freq_ranges);
- } else {
- esync->range = NULL;
- esync->range_num = 0;
- }
-
return 0;
}
@@ -582,8 +577,8 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
struct zl3073x_dpll_pin *pin = pin_priv;
const struct zl3073x_synth *synth;
const struct zl3073x_out *out;
+ u32 synth_freq, out_freq;
u8 clock_type, out_id;
- u32 synth_freq;
out_id = zl3073x_output_pin_out_get(pin->id);
out = zl3073x_out_state_get(zldev, out_id);
@@ -592,17 +587,19 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
* for N-division is also used for the esync divider so both cannot
* be used.
*/
- switch (zl3073x_out_signal_format_get(out)) {
- case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV:
- case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV_INV:
+ if (zl3073x_out_is_ndiv(out))
return -EOPNOTSUPP;
- default:
- break;
- }
/* Get attached synth frequency */
synth = zl3073x_synth_state_get(zldev, zl3073x_out_synth_get(out));
synth_freq = zl3073x_synth_freq_get(synth);
+ out_freq = synth_freq / out->div;
+
+ if (!pin->esync_control || out_freq <= 1)
+ return -EOPNOTSUPP;
+
+ esync->range = esync_freq_ranges;
+ esync->range_num = ARRAY_SIZE(esync_freq_ranges);
clock_type = FIELD_GET(ZL_OUTPUT_MODE_CLOCK_TYPE, out->mode);
if (clock_type != ZL_OUTPUT_MODE_CLOCK_TYPE_ESYNC) {
@@ -610,11 +607,11 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
esync->freq = 0;
esync->pulse = 0;
- goto finish;
+ return 0;
}
/* Compute esync frequency */
- esync->freq = synth_freq / out->div / out->esync_n_period;
+ esync->freq = out_freq / out->esync_n_period;
/* By comparing the esync_pulse_width to the half of the pulse width
* the esync pulse percentage can be determined.
@@ -623,18 +620,6 @@ zl3073x_dpll_output_pin_esync_get(const struct dpll_pin *dpll_pin,
*/
esync->pulse = (50 * out->esync_n_width) / out->div;
-finish:
- /* Set supported esync ranges if the pin supports esync control and
- * if the output frequency is > 1 Hz.
- */
- if (pin->esync_control && (synth_freq / out->div) > 1) {
- esync->range = esync_freq_ranges;
- esync->range_num = ARRAY_SIZE(esync_freq_ranges);
- } else {
- esync->range = NULL;
- esync->range_num = 0;
- }
-
return 0;
}
@@ -660,13 +645,8 @@ zl3073x_dpll_output_pin_esync_set(const struct dpll_pin *dpll_pin,
* for N-division is also used for the esync divider so both cannot
* be used.
*/
- switch (zl3073x_out_signal_format_get(&out)) {
- case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV:
- case ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV_INV:
+ if (zl3073x_out_is_ndiv(&out))
return -EOPNOTSUPP;
- default:
- break;
- }
/* Select clock type */
if (freq)
@@ -728,9 +708,9 @@ zl3073x_dpll_output_pin_frequency_set(const struct dpll_pin *dpll_pin,
struct zl3073x_dev *zldev = zldpll->dev;
struct zl3073x_dpll_pin *pin = pin_priv;
const struct zl3073x_synth *synth;
- u8 out_id, signal_format;
u32 new_div, synth_freq;
struct zl3073x_out out;
+ u8 out_id;
out_id = zl3073x_output_pin_out_get(pin->id);
out = *zl3073x_out_state_get(zldev, out_id);
@@ -740,12 +720,8 @@ zl3073x_dpll_output_pin_frequency_set(const struct dpll_pin *dpll_pin,
synth_freq = zl3073x_synth_freq_get(synth);
new_div = synth_freq / (u32)frequency;
- /* Get used signal format for the given output */
- signal_format = zl3073x_out_signal_format_get(&out);
-
/* Check signal format */
- if (signal_format != ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV &&
- signal_format != ZL_OUTPUT_MODE_SIGNAL_FORMAT_2_NDIV_INV) {
+ if (!zl3073x_out_is_ndiv(&out)) {
/* For non N-divided signal formats the frequency is computed
* as division of synth frequency and output divisor.
*/
--
2.52.0
^ permalink raw reply related
* [PATCH net-next v2 0/5] dpll: zl3073x: add ref-sync pair support
From: Ivan Vecera @ 2026-03-28 8:06 UTC (permalink / raw)
To: netdev
Cc: Arkadiusz Kubalewski, Jiri Pirko, Michal Schmidt, Petr Oros,
Prathosh Satish, Simon Horman, Vadim Fedorenko, linux-kernel,
Conor Dooley, Krzysztof Kozlowski, Rob Herring, devicetree,
Pasi Vaananen
This series adds Reference-Sync pair support to the ZL3073x DPLL driver.
A Ref-Sync pair consists of a clock reference and a low-frequency sync
signal (e.g. 1 PPS) where the DPLL locks to the clock reference but
phase-aligns to the sync reference.
Patches 1-3 are preparatory cleanups and helper additions:
- Clean up esync get/set callbacks with early returns and use the
zl3073x_out_is_ndiv() helper
- Convert open-coded clear-and-set bitfield patterns to FIELD_MODIFY()
- Add ref sync control and output clock type accessor helpers
Patch 4 adds the 'ref-sync-sources' phandle-array property to the
dpll-pin device tree binding schema and updates the ZL3073x binding
examples.
Patch 5 implements the driver support:
- ref_sync_get/set callbacks with frequency validation
- Automatic sync source exclusion from reference selection
- Device tree based ref-sync pair registration
Tested and verified on Microchip EDS2 (pcb8385) development board.
Changes:
v2 - added proper reviewed-by tags (requested by Kuba)
Ivan Vecera (5):
dpll: zl3073x: clean up esync get/set and use zl3073x_out_is_ndiv()
dpll: zl3073x: use FIELD_MODIFY() for clear-and-set patterns
dpll: zl3073x: add ref sync and output clock type helpers
dt-bindings: dpll: add ref-sync-sources property
dpll: zl3073x: add ref-sync pair support
.../devicetree/bindings/dpll/dpll-pin.yaml | 11 +
.../bindings/dpll/microchip,zl30731.yaml | 30 +-
drivers/dpll/zl3073x/chan.h | 17 +-
drivers/dpll/zl3073x/core.c | 3 +-
drivers/dpll/zl3073x/dpll.c | 295 ++++++++++++++----
drivers/dpll/zl3073x/flash.c | 3 +-
drivers/dpll/zl3073x/out.h | 22 ++
drivers/dpll/zl3073x/ref.h | 46 +++
drivers/dpll/zl3073x/regs.h | 2 +
9 files changed, 348 insertions(+), 81 deletions(-)
--
2.52.0
^ permalink raw reply
* Re: [PATCH net-next 3/5] dpll: zl3073x: add ref sync and output clock type helpers
From: Ivan Vecera @ 2026-03-28 8:02 UTC (permalink / raw)
To: Jakub Kicinski, Prathosh.Satish
Cc: netdev, arkadiusz.kubalewski, jiri, mschmidt, poros, horms,
vadim.fedorenko, linux-kernel, conor+dt, krzk+dt, robh,
devicetree, pvaanane
In-Reply-To: <20260327165913.37642642@kernel.org>
On 3/28/26 12:59 AM, Jakub Kicinski wrote:
> On Fri, 27 Mar 2026 15:35:13 +0000 Prathosh.Satish@microchip.com wrote:
>> Reviewed-by: prathosh.satish@microchip.com
>
> That's not a correct format for a review tag, and you need to
> make sure that the quoted lines are prefixed with >
> Outlook style quoting does not work, it makes patchwork think
> that you added all the tags that were in the quoted text again.
>
> Ivan, could you sort this out and repost (add corrected tags from
> Prathosh)? Last time I tried to fix such mess while applying it ended
> poorly :(
>
Hi Kuba,
sure, I'm going to repost it as v2.
Thanks,
Ivan
^ permalink raw reply
* Re: [PATCH net-next v2 03/15] net: stmmac: qcom-ethqos: eliminate configure_func
From: Russell King (Oracle) @ 2026-03-28 7:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alexandre Torgue, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, linux-arm-kernel, linux-arm-msm, linux-stm32,
Mohd Ayaan Anwar, netdev, Paolo Abeni
In-Reply-To: <E1w62n4-0000000E3C3-251S@rmk-PC.armlinux.org.uk>
On Fri, Mar 27, 2026 at 08:43:38AM +0000, Russell King (Oracle) wrote:
> @@ -687,7 +683,7 @@ static int ethqos_clks_config(void *priv, bool enabled)
> /* Enable functional clock to prevent DMA reset to timeout due
> * to lacking PHY clock after the hardware block has been power
> * cycled. The actual configuration will be adjusted once
> - * ethqos_fix_mac_speed() is invoked.
> + * ethqos' fix_mac_speed() method is invoked.
...
> - ethqos->configure_func = ethqos_configure_rgmii;
> + plat_dat->fix_mac_speed = ethqos_fix_mac_speed_rgmii;
...
> - ethqos->configure_func = ethqos_configure_sgmii;
> + plat_dat->fix_mac_speed = ethqos_fix_mac_speed_sgmii;
AI review of this patch is still complaining about the comment above:
The comment still references 'fix_mac_speed() method' but the function
ethqos_fix_mac_speed() was removed in this patch. Should this comment be
updated to reference either ethqos_fix_mac_speed_rgmii() or
ethqos_fix_mac_speed_sgmii(), or perhaps just 'the fix_mac_speed callback'
to remain implementation-agnostic?
Artifical Stupidity at its best! :/
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v3] net: stmmac: skip VLAN restore when VLAN hash ops are missing
From: Russell King (Oracle) @ 2026-03-28 7:51 UTC (permalink / raw)
To: Michal Piekos
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Ovidiu Panait,
netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260328-vlan-restore-error-v3-1-df47a039c6f6@mmpsystems.pl>
On Sat, Mar 28, 2026 at 07:51:53AM +0100, Michal Piekos wrote:
> stmmac_vlan_restore() unconditionally calls stmmac_vlan_update() when
> NETIF_F_VLAN_FEATURES is set. On platforms where priv->hw->vlan (or
> ->update_vlan_hash) is not provided, stmmac_update_vlan_hash() returns
> -EINVAL via stmmac_do_void_callback(), resulting in a spurious
> "Failed to restore VLANs" error even when no VLAN filtering is in use.
>
> Remove the unneeded comment.
>
> Tested on Orange Pi Zero 3.
>
> Fixes: bd7ad51253a7 ("net: stmmac: Fix VLAN HW state restore")
> Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
> ---
> This patch fixes a noisy "Failed to restore VLANs" message on platforms
> where stmmac VLAN hash ops are not implemented.
> stmmac_vlan_restore() calls stmmac_vlan_update() without checking for
> VLAN hash ops presence which results in -EINVAL.
> ---
> Changes in v3:
> - Remove the offending comment
> - Restore the original check for NETIF_F_VLAN_FEATURES
> - Link to v2: https://lore.kernel.org/r/20260321-vlan-restore-error-v2-1-45cf56a5223d@mmpsystems.pl
>
> Changes in v2:
> - Replace check for hash ops with check for HW FILTER flags
> - Link to v1: https://lore.kernel.org/r/20260314-vlan-restore-error-v1-1-4fc6c3e2115f@mmpsystems.pl
> ---
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 +-------
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 6827c99bde8c..0f3e5ac05faa 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -6861,19 +6861,13 @@ static int stmmac_vlan_rx_kill_vid(struct net_device *ndev, __be16 proto, u16 vi
>
> static int stmmac_vlan_restore(struct stmmac_priv *priv)
> {
> - int ret;
> -
> if (!(priv->dev->features & NETIF_F_VLAN_FEATURES))
> return 0;
>
> if (priv->hw->num_vlan)
> stmmac_restore_hw_vlan_rx_fltr(priv, priv->dev, priv->hw);
>
> - ret = stmmac_vlan_update(priv, priv->num_double_vlans);
> - if (ret)
> - netdev_err(priv->dev, "Failed to restore VLANs\n");
> -
> - return ret;
> + return stmmac_vlan_update(priv, priv->num_double_vlans);
> }
Yes, but as both Andrew and myself have pointed out, no one checks
the return value of stmmac_vlan_restore(), so why does it return
int?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH v3] net: stmmac: skip VLAN restore when VLAN hash ops are missing
From: Michal Piekos @ 2026-03-28 6:51 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue, Ovidiu Panait
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel,
Michal Piekos
stmmac_vlan_restore() unconditionally calls stmmac_vlan_update() when
NETIF_F_VLAN_FEATURES is set. On platforms where priv->hw->vlan (or
->update_vlan_hash) is not provided, stmmac_update_vlan_hash() returns
-EINVAL via stmmac_do_void_callback(), resulting in a spurious
"Failed to restore VLANs" error even when no VLAN filtering is in use.
Remove the unneeded comment.
Tested on Orange Pi Zero 3.
Fixes: bd7ad51253a7 ("net: stmmac: Fix VLAN HW state restore")
Signed-off-by: Michal Piekos <michal.piekos@mmpsystems.pl>
---
This patch fixes a noisy "Failed to restore VLANs" message on platforms
where stmmac VLAN hash ops are not implemented.
stmmac_vlan_restore() calls stmmac_vlan_update() without checking for
VLAN hash ops presence which results in -EINVAL.
---
Changes in v3:
- Remove the offending comment
- Restore the original check for NETIF_F_VLAN_FEATURES
- Link to v2: https://lore.kernel.org/r/20260321-vlan-restore-error-v2-1-45cf56a5223d@mmpsystems.pl
Changes in v2:
- Replace check for hash ops with check for HW FILTER flags
- Link to v1: https://lore.kernel.org/r/20260314-vlan-restore-error-v1-1-4fc6c3e2115f@mmpsystems.pl
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 6827c99bde8c..0f3e5ac05faa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -6861,19 +6861,13 @@ static int stmmac_vlan_rx_kill_vid(struct net_device *ndev, __be16 proto, u16 vi
static int stmmac_vlan_restore(struct stmmac_priv *priv)
{
- int ret;
-
if (!(priv->dev->features & NETIF_F_VLAN_FEATURES))
return 0;
if (priv->hw->num_vlan)
stmmac_restore_hw_vlan_rx_fltr(priv, priv->dev, priv->hw);
- ret = stmmac_vlan_update(priv, priv->num_double_vlans);
- if (ret)
- netdev_err(priv->dev, "Failed to restore VLANs\n");
-
- return ret;
+ return stmmac_vlan_update(priv, priv->num_double_vlans);
}
static int stmmac_bpf(struct net_device *dev, struct netdev_bpf *bpf)
---
base-commit: be762d8b6dd7efacb61937d20f8475db8f207655
change-id: 20260314-vlan-restore-error-f8b3a1c7f50a
Best regards,
--
Michal Piekos <michal.piekos@mmpsystems.pl>
^ permalink raw reply related
* Re: [PATCH net-next v10 07/14] net: Proxy netdev_queue_get_dma_dev for leased queues
From: Nikolay Aleksandrov @ 2026-03-28 6:51 UTC (permalink / raw)
To: Daniel Borkmann, netdev
Cc: bpf, kuba, davem, pabeni, willemb, sdf, john.fastabend,
martin.lau, jordan, maciej.fijalkowski, magnus.karlsson, dw, toke,
yangzhenze, wangdongdong.6
In-Reply-To: <20260327121049.334562-8-daniel@iogearbox.net>
On 27/03/2026 14:10, Daniel Borkmann wrote:
> From: David Wei <dw@davidwei.uk>
>
> Extend netdev_queue_get_dma_dev to return the physical device of the
> real rxq for DMA in case the queue was leased. This allows memory
> providers like io_uring zero-copy or devmem to bind to the physically
> leased rxq via virtual devices such as netkit.
>
> Signed-off-by: David Wei <dw@davidwei.uk>
> Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> include/net/netdev_queues.h | 3 ++-
> net/core/netdev_queues.c | 36 ++++++++++++++++++++++++++++--------
> 2 files changed, 30 insertions(+), 9 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net-next v10 06/14] net: Proxy netif_mp_{open,close}_rxq for leased queues
From: Nikolay Aleksandrov @ 2026-03-28 6:50 UTC (permalink / raw)
To: Daniel Borkmann, netdev
Cc: bpf, kuba, davem, pabeni, willemb, sdf, john.fastabend,
martin.lau, jordan, maciej.fijalkowski, magnus.karlsson, dw, toke,
yangzhenze, wangdongdong.6
In-Reply-To: <20260327121049.334562-7-daniel@iogearbox.net>
On 27/03/2026 14:10, Daniel Borkmann wrote:
> From: David Wei <dw@davidwei.uk>
>
> When a process in a container wants to setup a memory provider, it will
> use the virtual netdev and a leased rxq, and call netif_mp_{open,close}_rxq
> to try and restart the queue. At this point, proxy the queue restart on
> the real rxq in the physical netdev.
>
> For memory providers (io_uring zero-copy rx and devmem), it causes the
> real rxq in the physical netdev to be filled from a memory provider that
> has DMA mapped memory from a process within a container.
>
> Signed-off-by: David Wei <dw@davidwei.uk>
> Co-developed-by: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> ---
> net/core/dev.h | 2 +
> net/core/netdev_rx_queue.c | 93 +++++++++++++++++++++++++++++++-------
> 2 files changed, 78 insertions(+), 17 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net-next v10 05/14] net: Slightly simplify net_mp_{open,close}_rxq
From: Nikolay Aleksandrov @ 2026-03-28 6:47 UTC (permalink / raw)
To: Daniel Borkmann, netdev
Cc: bpf, kuba, davem, pabeni, willemb, sdf, john.fastabend,
martin.lau, jordan, maciej.fijalkowski, magnus.karlsson, dw, toke,
yangzhenze, wangdongdong.6
In-Reply-To: <20260327121049.334562-6-daniel@iogearbox.net>
On 27/03/2026 14:10, Daniel Borkmann wrote:
> net_mp_open_rxq is currently not used in the tree as all callers are
> using __net_mp_open_rxq directly, and net_mp_close_rxq is only used
> once while all other locations use __net_mp_close_rxq.
>
> Consolidate into a single API, netif_mp_{open,close}_rxq, using the
> netif_ prefix to indicate that the caller is responsible for locking.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Co-developed-by: David Wei <dw@davidwei.uk>
> Signed-off-by: David Wei <dw@davidwei.uk>
> ---
> include/net/page_pool/memory_provider.h | 8 ++------
> io_uring/zcrx.c | 9 ++++++---
> net/core/devmem.c | 6 +++---
> net/core/netdev_rx_queue.c | 23 ++---------------------
> 4 files changed, 13 insertions(+), 33 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net-next v10 04/14] net, ethtool: Disallow leased real rxqs to be resized
From: Nikolay Aleksandrov @ 2026-03-28 6:47 UTC (permalink / raw)
To: Daniel Borkmann, netdev
Cc: bpf, kuba, davem, pabeni, willemb, sdf, john.fastabend,
martin.lau, jordan, maciej.fijalkowski, magnus.karlsson, dw, toke,
yangzhenze, wangdongdong.6
In-Reply-To: <20260327121049.334562-5-daniel@iogearbox.net>
On 27/03/2026 14:10, Daniel Borkmann wrote:
> Similar to AF_XDP, do not allow queues in a physical netdev to be
> resized by ethtool -L when they are leased. Cover channel resize
> paths (both netlink and ioctl) to reject resizing when the queues
> would be affected.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Co-developed-by: David Wei <dw@davidwei.uk>
> Signed-off-by: David Wei <dw@davidwei.uk>
> ---
> net/ethtool/channels.c | 17 ++++++++++++-----
> net/ethtool/ioctl.c | 16 +++++++++++-----
> 2 files changed, 23 insertions(+), 10 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net v2] bridge: mrp: reject zero test interval to avoid OOM panic
From: Xiang Mei @ 2026-03-28 6:47 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: netdev, bridge, horms, kuba, idosch, davem, edumazet, pabeni,
bestswngs
In-Reply-To: <edad225a-79cc-42de-a771-b1ea6d430ef7@blackwall.org>
Thanks for the quick review.
On Fri, Mar 27, 2026 at 11:44 PM Nikolay Aleksandrov
<razor@blackwall.org> wrote:
>
> On 28/03/2026 08:30, Xiang Mei wrote:
> > br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
> > interval value from netlink without validation. When interval is 0,
> > usecs_to_jiffies(0) yields 0, causing the delayed work
> > (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
> > itself with zero delay. This creates a tight loop on system_percpu_wq
> > that allocates and transmits MRP test frames at maximum rate, exhausting
> > all system memory and causing a kernel panic via OOM deadlock.
> >
> > The same zero-interval issue applies to br_mrp_start_in_test_parse()
> > for interconnect test frames.
> >
> > Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
> > IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
> > IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
> > netlink attribute parsing layer before the value ever reaches the
> > workqueue scheduling code. This is consistent with how other bridge
> > subsystems (br_fdb, br_mst) enforce range constraints on netlink
> > attributes.
> >
> > Fixes: 20f6a05ef635 ("bridge: mrp: Rework the MRP netlink interface")
> > Fixes: 7ab1748e4ce6 ("bridge: mrp: Extend MRP netlink interface for configuring MRP interconnect")
> > Reported-by: Weiming Shi <bestswngs@gmail.com>
> > Signed-off-by: Xiang Mei <xmei5@asu.edu>
> > ---
> > net/bridge/br_mrp_netlink.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/bridge/br_mrp_netlink.c b/net/bridge/br_mrp_netlink.c
> > index ce6f63c77cc0..86f0e75d6e34 100644
> > --- a/net/bridge/br_mrp_netlink.c
> > +++ b/net/bridge/br_mrp_netlink.c
> > @@ -196,7 +196,7 @@ static const struct nla_policy
> > br_mrp_start_test_policy[IFLA_BRIDGE_MRP_START_TEST_MAX + 1] = {
> > [IFLA_BRIDGE_MRP_START_TEST_UNSPEC] = { .type = NLA_REJECT },
> > [IFLA_BRIDGE_MRP_START_TEST_RING_ID] = { .type = NLA_U32 },
> > - [IFLA_BRIDGE_MRP_START_TEST_INTERVAL] = { .type = NLA_U32 },
> > + [IFLA_BRIDGE_MRP_START_TEST_INTERVAL] = NLA_POLICY_MIN(NLA_U32, 1),
> > [IFLA_BRIDGE_MRP_START_TEST_MAX_MISS] = { .type = NLA_U32 },
> > [IFLA_BRIDGE_MRP_START_TEST_PERIOD] = { .type = NLA_U32 },
> > [IFLA_BRIDGE_MRP_START_TEST_MONITOR] = { .type = NLA_U32 },
> > @@ -316,7 +316,7 @@ static const struct nla_policy
> > br_mrp_start_in_test_policy[IFLA_BRIDGE_MRP_START_IN_TEST_MAX + 1] = {
> > [IFLA_BRIDGE_MRP_START_IN_TEST_UNSPEC] = { .type = NLA_REJECT },
> > [IFLA_BRIDGE_MRP_START_IN_TEST_IN_ID] = { .type = NLA_U32 },
> > - [IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL] = { .type = NLA_U32 },
> > + [IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL] = NLA_POLICY_MIN(NLA_U32, 1),
> > [IFLA_BRIDGE_MRP_START_IN_TEST_MAX_MISS] = { .type = NLA_U32 },
> > [IFLA_BRIDGE_MRP_START_IN_TEST_PERIOD] = { .type = NLA_U32 },
> > };
>
> Alright, let's limit them :-)
>
> Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
>
^ permalink raw reply
* Re: [PATCH net-next v10 03/14] net: Add lease info to queue-get response
From: Nikolay Aleksandrov @ 2026-03-28 6:44 UTC (permalink / raw)
To: Daniel Borkmann, netdev
Cc: bpf, kuba, davem, pabeni, willemb, sdf, john.fastabend,
martin.lau, jordan, maciej.fijalkowski, magnus.karlsson, dw, toke,
yangzhenze, wangdongdong.6
In-Reply-To: <20260327121049.334562-4-daniel@iogearbox.net>
On 27/03/2026 14:10, Daniel Borkmann wrote:
> Populate nested lease info to the queue-get response that returns the
> ifindex, queue id with type and optionally netns id if the device
> resides in a different netns.
>
> Example with ynl client when using AF_XDP via queue leasing:
>
> # ip a
> [...]
> 4: enp10s0f0np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 xdp/id:24 qdisc mq state UP group default qlen 1000
> link/ether e8:eb:d3:a3:43:f6 brd ff:ff:ff:ff:ff:ff
> inet 10.0.0.2/24 scope global enp10s0f0np0
> valid_lft forever preferred_lft forever
> inet6 fe80::eaeb:d3ff:fea3:43f6/64 scope link proto kernel_ll
> valid_lft forever preferred_lft forever
> [...]
>
> # ethtool -i enp10s0f0np0
> driver: mlx5_core
> [...]
>
> # ynl --family netdev --output-json --do queue-get \
> --json '{"ifindex": 4, "id": 15, "type": "rx"}'
> {'id': 15,
> 'ifindex': 4,
> 'lease': {'ifindex': 8, 'netns-id': 0, 'queue': {'id': 1, 'type': 'rx'}},
> 'napi-id': 8227,
> 'type': 'rx',
> 'xsk': {}}
>
> # ip netns list
> foo (id: 0)
>
> # ip netns exec foo ip a
> [...]
> 8: nk@NONE: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
> link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::200:ff:fe00:0/64 scope link proto kernel_ll
> valid_lft forever preferred_lft forever
> [...]
>
> # ip netns exec foo ethtool -i nk
> driver: netkit
> [...]
>
> # ip netns exec foo ls /sys/class/net/nk/queues/
> rx-0 rx-1 tx-0
>
> # ip netns exec foo ynl --family netdev --output-json --do queue-get \
> --json '{"ifindex": 8, "id": 1, "type": "rx"}'
> {"id": 1, "type": "rx", "ifindex": 8, "xsk": {}}
>
> Note that the caller of netdev_nl_queue_fill_one() holds the netdevice
> lock. For the queue-get we do not lock both devices. When queues get
> {un,}leased, both devices are locked, thus if __netif_get_rx_queue_lease()
> returns a lease pointer, it points to a valid device. The netns-id is
> fetched via peernet2id_alloc() similarly as done in OVS.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Co-developed-by: David Wei <dw@davidwei.uk>
> Signed-off-by: David Wei <dw@davidwei.uk>
> ---
> include/net/netdev_rx_queue.h | 14 ++++++++
> net/core/netdev-genl.c | 66 ++++++++++++++++++++++++++++++++---
> net/core/netdev_rx_queue.c | 54 ++++++++++++++++++++++++++++
> 3 files changed, 130 insertions(+), 4 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net v2] bridge: mrp: reject zero test interval to avoid OOM panic
From: Nikolay Aleksandrov @ 2026-03-28 6:43 UTC (permalink / raw)
To: Xiang Mei, netdev
Cc: bridge, horms, kuba, idosch, davem, edumazet, pabeni, bestswngs
In-Reply-To: <20260328063000.1845376-1-xmei5@asu.edu>
On 28/03/2026 08:30, Xiang Mei wrote:
> br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
> interval value from netlink without validation. When interval is 0,
> usecs_to_jiffies(0) yields 0, causing the delayed work
> (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
> itself with zero delay. This creates a tight loop on system_percpu_wq
> that allocates and transmits MRP test frames at maximum rate, exhausting
> all system memory and causing a kernel panic via OOM deadlock.
>
> The same zero-interval issue applies to br_mrp_start_in_test_parse()
> for interconnect test frames.
>
> Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
> IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
> IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
> netlink attribute parsing layer before the value ever reaches the
> workqueue scheduling code. This is consistent with how other bridge
> subsystems (br_fdb, br_mst) enforce range constraints on netlink
> attributes.
>
> Fixes: 20f6a05ef635 ("bridge: mrp: Rework the MRP netlink interface")
> Fixes: 7ab1748e4ce6 ("bridge: mrp: Extend MRP netlink interface for configuring MRP interconnect")
> Reported-by: Weiming Shi <bestswngs@gmail.com>
> Signed-off-by: Xiang Mei <xmei5@asu.edu>
> ---
> net/bridge/br_mrp_netlink.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/bridge/br_mrp_netlink.c b/net/bridge/br_mrp_netlink.c
> index ce6f63c77cc0..86f0e75d6e34 100644
> --- a/net/bridge/br_mrp_netlink.c
> +++ b/net/bridge/br_mrp_netlink.c
> @@ -196,7 +196,7 @@ static const struct nla_policy
> br_mrp_start_test_policy[IFLA_BRIDGE_MRP_START_TEST_MAX + 1] = {
> [IFLA_BRIDGE_MRP_START_TEST_UNSPEC] = { .type = NLA_REJECT },
> [IFLA_BRIDGE_MRP_START_TEST_RING_ID] = { .type = NLA_U32 },
> - [IFLA_BRIDGE_MRP_START_TEST_INTERVAL] = { .type = NLA_U32 },
> + [IFLA_BRIDGE_MRP_START_TEST_INTERVAL] = NLA_POLICY_MIN(NLA_U32, 1),
> [IFLA_BRIDGE_MRP_START_TEST_MAX_MISS] = { .type = NLA_U32 },
> [IFLA_BRIDGE_MRP_START_TEST_PERIOD] = { .type = NLA_U32 },
> [IFLA_BRIDGE_MRP_START_TEST_MONITOR] = { .type = NLA_U32 },
> @@ -316,7 +316,7 @@ static const struct nla_policy
> br_mrp_start_in_test_policy[IFLA_BRIDGE_MRP_START_IN_TEST_MAX + 1] = {
> [IFLA_BRIDGE_MRP_START_IN_TEST_UNSPEC] = { .type = NLA_REJECT },
> [IFLA_BRIDGE_MRP_START_IN_TEST_IN_ID] = { .type = NLA_U32 },
> - [IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL] = { .type = NLA_U32 },
> + [IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL] = NLA_POLICY_MIN(NLA_U32, 1),
> [IFLA_BRIDGE_MRP_START_IN_TEST_MAX_MISS] = { .type = NLA_U32 },
> [IFLA_BRIDGE_MRP_START_IN_TEST_PERIOD] = { .type = NLA_U32 },
> };
Alright, let's limit them :-)
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net-next v10 02/14] net: Implement netdev_nl_queue_create_doit
From: Nikolay Aleksandrov @ 2026-03-28 6:42 UTC (permalink / raw)
To: Daniel Borkmann, netdev
Cc: bpf, kuba, davem, pabeni, willemb, sdf, john.fastabend,
martin.lau, jordan, maciej.fijalkowski, magnus.karlsson, dw, toke,
yangzhenze, wangdongdong.6
In-Reply-To: <20260327121049.334562-3-daniel@iogearbox.net>
On 27/03/2026 14:10, Daniel Borkmann wrote:
> Implement netdev_nl_queue_create_doit which creates a new rx queue in a
> virtual netdev and then leases it to a rx queue in a physical netdev.
>
> Example with ynl client:
>
> # ynl --family netdev --output-json --do queue-create \
> --json '{"ifindex": 8, "type": "rx", "lease": {"ifindex": 4, "queue": {"type": "rx", "id": 15}}}'
> {'id': 1}
>
> Note that the netdevice locking order is always from the virtual to
> the physical device.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Co-developed-by: David Wei <dw@davidwei.uk>
> Signed-off-by: David Wei <dw@davidwei.uk>
> ---
> Documentation/networking/netdevices.rst | 6 +
> include/linux/netdevice.h | 9 +-
> include/net/netdev_queues.h | 19 ++-
> include/net/netdev_rx_queue.h | 15 ++-
> include/net/xdp_sock_drv.h | 2 +-
> net/core/dev.c | 8 ++
> net/core/dev.h | 5 +
> net/core/netdev-genl.c | 164 +++++++++++++++++++++++-
> net/core/netdev_queues.c | 62 +++++++++
> net/core/netdev_rx_queue.c | 46 ++++++-
> net/xdp/xsk.c | 2 +-
> 11 files changed, 325 insertions(+), 13 deletions(-)
>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
^ permalink raw reply
* Re: [PATCH net] bridge: mrp: reject zero test interval to avoid OOM panic
From: Nikolay Aleksandrov @ 2026-03-28 6:38 UTC (permalink / raw)
To: Xiang Mei
Cc: Simon Horman, netdev, bridge, idosch, davem, edumazet, pabeni,
bestswngs
In-Reply-To: <cxf6kerzseqczgsdgznoqaxcgnx3hql65tbupt7rk4arjp6www@5jnc3nkrvljt>
On 28/03/2026 08:19, Xiang Mei wrote:
> On Fri, Mar 27, 2026 at 01:46:39PM +0200, Nikolay Aleksandrov wrote:
>> On 27/03/2026 13:34, Simon Horman wrote:
>>> On Wed, Mar 25, 2026 at 08:24:38PM -0700, Xiang Mei wrote:
>>>> br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
>>>> interval value from netlink without validation. When interval is 0,
>>>> usecs_to_jiffies(0) yields 0, causing the delayed work
>>>> (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
>>>> itself with zero delay. This creates a tight loop on system_percpu_wq
>>>> that allocates and transmits MRP test frames at maximum rate, exhausting
>>>> all system memory and causing a kernel panic via OOM deadlock.
>>>
>>> I would suspect the primary outcome of this problem is high CPU consumption
>>> rather than memory exhaustion. Is there a reason to expect that
>>> the transmitted fames can't be consumed as fast as they are created?
>>>
>>
>> +1
>> More so with CAP_NET_ADMIN you can cause all sorts of OOM and high-cpu usage
>> conditions. This is a configuration error and OOM doesn't lead to panic unless
>> instructed to. I don't think this is worth changing at all.
>
> Thanks for your review. This path is reachable from an unprivileged user
> namespace. The capability check goes through rtnetlink_rcv_msg() ->
> netlink_net_capable() -> netlink_ns_capable(), which checks
> CAP_NET_ADMIN against the network namespace's user_ns, not init_user_ns.
> An unprivileged user can create a user+net namespace, get CAP_NET_ADMIN>
within it, set up a bridge with MRP, and trigger the zero-interval loop.
> This is not a privileged misconfiguration scenario.
Technically this is also conditional on configuration. It depends first if users
can create namespaces at all, then on the effective and inheritable caps.
Anyway, as I said in a previous reply, I'm fine either way. Please resubmit
with the fixes tag.
>
> Also, the PoC can crash a kernel without "oops=panic" with this bug.
>
>>
>>>>
>>>> The same zero-interval issue applies to br_mrp_start_in_test_parse()
>>>> for interconnect test frames.
>>>>
>>>> Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
>>>> IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
>>>> IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
>>>> netlink attribute parsing layer before the value ever reaches the
>>>> workqueue scheduling code. This is consistent with how other bridge
>>>> subsystems (br_fdb, br_mst) enforce range constraints on netlink
>>>> attributes.
>>>>
>>>> Fixes: 7ab1748e4ce6 ("bridge: mrp: Extend MRP netlink interface for configuring MRP interconnect")
>>>
>>> I think you also want
>>>
>>> Fixes: 20f6a05ef635 ("bridge: mrp: Rework the MRP netlink interface")
>>>
>>> As highlighted by AI review.
>>>
>>>> Reported-by: Weiming Shi <bestswngs@gmail.com>
>>>> Signed-off-by: Xiang Mei <xmei5@asu.edu>
>>>
>>> ...
>>
^ permalink raw reply
* [PATCH net v2] bridge: mrp: reject zero test interval to avoid OOM panic
From: Xiang Mei @ 2026-03-28 6:30 UTC (permalink / raw)
To: netdev
Cc: bridge, horms, razor, kuba, idosch, davem, edumazet, pabeni,
bestswngs, Xiang Mei
br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
interval value from netlink without validation. When interval is 0,
usecs_to_jiffies(0) yields 0, causing the delayed work
(br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
itself with zero delay. This creates a tight loop on system_percpu_wq
that allocates and transmits MRP test frames at maximum rate, exhausting
all system memory and causing a kernel panic via OOM deadlock.
The same zero-interval issue applies to br_mrp_start_in_test_parse()
for interconnect test frames.
Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
netlink attribute parsing layer before the value ever reaches the
workqueue scheduling code. This is consistent with how other bridge
subsystems (br_fdb, br_mst) enforce range constraints on netlink
attributes.
Fixes: 20f6a05ef635 ("bridge: mrp: Rework the MRP netlink interface")
Fixes: 7ab1748e4ce6 ("bridge: mrp: Extend MRP netlink interface for configuring MRP interconnect")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Signed-off-by: Xiang Mei <xmei5@asu.edu>
---
net/bridge/br_mrp_netlink.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_mrp_netlink.c b/net/bridge/br_mrp_netlink.c
index ce6f63c77cc0..86f0e75d6e34 100644
--- a/net/bridge/br_mrp_netlink.c
+++ b/net/bridge/br_mrp_netlink.c
@@ -196,7 +196,7 @@ static const struct nla_policy
br_mrp_start_test_policy[IFLA_BRIDGE_MRP_START_TEST_MAX + 1] = {
[IFLA_BRIDGE_MRP_START_TEST_UNSPEC] = { .type = NLA_REJECT },
[IFLA_BRIDGE_MRP_START_TEST_RING_ID] = { .type = NLA_U32 },
- [IFLA_BRIDGE_MRP_START_TEST_INTERVAL] = { .type = NLA_U32 },
+ [IFLA_BRIDGE_MRP_START_TEST_INTERVAL] = NLA_POLICY_MIN(NLA_U32, 1),
[IFLA_BRIDGE_MRP_START_TEST_MAX_MISS] = { .type = NLA_U32 },
[IFLA_BRIDGE_MRP_START_TEST_PERIOD] = { .type = NLA_U32 },
[IFLA_BRIDGE_MRP_START_TEST_MONITOR] = { .type = NLA_U32 },
@@ -316,7 +316,7 @@ static const struct nla_policy
br_mrp_start_in_test_policy[IFLA_BRIDGE_MRP_START_IN_TEST_MAX + 1] = {
[IFLA_BRIDGE_MRP_START_IN_TEST_UNSPEC] = { .type = NLA_REJECT },
[IFLA_BRIDGE_MRP_START_IN_TEST_IN_ID] = { .type = NLA_U32 },
- [IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL] = { .type = NLA_U32 },
+ [IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL] = NLA_POLICY_MIN(NLA_U32, 1),
[IFLA_BRIDGE_MRP_START_IN_TEST_MAX_MISS] = { .type = NLA_U32 },
[IFLA_BRIDGE_MRP_START_IN_TEST_PERIOD] = { .type = NLA_U32 },
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] bridge: mrp: reject zero test interval to avoid OOM panic
From: Xiang Mei @ 2026-03-28 6:23 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Nikolay Aleksandrov, Simon Horman, netdev, bridge, idosch, davem,
edumazet, pabeni, bestswngs
In-Reply-To: <20260327171917.7575d715@kernel.org>
Thanks for your review. interval=1 works fine even in the case when we
use netem to delay the consumer. I'll correct the fix tag and send a
v2.
On Fri, Mar 27, 2026 at 5:19 PM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Fri, 27 Mar 2026 13:46:39 +0200 Nikolay Aleksandrov wrote:
> > On 27/03/2026 13:34, Simon Horman wrote:
> > > On Wed, Mar 25, 2026 at 08:24:38PM -0700, Xiang Mei wrote:
> > >> br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
> > >> interval value from netlink without validation. When interval is 0,
> > >> usecs_to_jiffies(0) yields 0, causing the delayed work
> > >> (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
> > >> itself with zero delay. This creates a tight loop on system_percpu_wq
> > >> that allocates and transmits MRP test frames at maximum rate, exhausting
> > >> all system memory and causing a kernel panic via OOM deadlock.
> > >
> > > I would suspect the primary outcome of this problem is high CPU consumption
> > > rather than memory exhaustion. Is there a reason to expect that
> > > the transmitted fames can't be consumed as fast as they are created?
> >
> > +1
> > More so with CAP_NET_ADMIN you can cause all sorts of OOM and high-cpu usage
> > conditions. This is a configuration error and OOM doesn't lead to panic unless
> > instructed to. I don't think this is worth changing at all.
>
> Then again if there's no practical use for 0 we should consider
> the risk of getting this sort of submission over and over again?
> Dunno..
^ permalink raw reply
* Re: [PATCH net] bridge: mrp: reject zero test interval to avoid OOM panic
From: Xiang Mei @ 2026-03-28 6:19 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Simon Horman, netdev, bridge, idosch, davem, edumazet, pabeni,
bestswngs
In-Reply-To: <f7fea291-bde9-4f95-8a59-1b209407ee27@blackwall.org>
On Fri, Mar 27, 2026 at 01:46:39PM +0200, Nikolay Aleksandrov wrote:
> On 27/03/2026 13:34, Simon Horman wrote:
> > On Wed, Mar 25, 2026 at 08:24:38PM -0700, Xiang Mei wrote:
> > > br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
> > > interval value from netlink without validation. When interval is 0,
> > > usecs_to_jiffies(0) yields 0, causing the delayed work
> > > (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
> > > itself with zero delay. This creates a tight loop on system_percpu_wq
> > > that allocates and transmits MRP test frames at maximum rate, exhausting
> > > all system memory and causing a kernel panic via OOM deadlock.
> >
> > I would suspect the primary outcome of this problem is high CPU consumption
> > rather than memory exhaustion. Is there a reason to expect that
> > the transmitted fames can't be consumed as fast as they are created?
> >
>
> +1
> More so with CAP_NET_ADMIN you can cause all sorts of OOM and high-cpu usage
> conditions. This is a configuration error and OOM doesn't lead to panic unless
> instructed to. I don't think this is worth changing at all.
Thanks for your review. This path is reachable from an unprivileged user
namespace. The capability check goes through rtnetlink_rcv_msg() ->
netlink_net_capable() -> netlink_ns_capable(), which checks
CAP_NET_ADMIN against the network namespace's user_ns, not init_user_ns.
An unprivileged user can create a user+net namespace, get CAP_NET_ADMIN
within it, set up a bridge with MRP, and trigger the zero-interval loop.
This is not a privileged misconfiguration scenario.
Also, the PoC can crash a kernel without "oops=panic" with this bug.
>
> > >
> > > The same zero-interval issue applies to br_mrp_start_in_test_parse()
> > > for interconnect test frames.
> > >
> > > Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
> > > IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
> > > IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
> > > netlink attribute parsing layer before the value ever reaches the
> > > workqueue scheduling code. This is consistent with how other bridge
> > > subsystems (br_fdb, br_mst) enforce range constraints on netlink
> > > attributes.
> > >
> > > Fixes: 7ab1748e4ce6 ("bridge: mrp: Extend MRP netlink interface for configuring MRP interconnect")
> >
> > I think you also want
> >
> > Fixes: 20f6a05ef635 ("bridge: mrp: Rework the MRP netlink interface")
> >
> > As highlighted by AI review.
> >
> > > Reported-by: Weiming Shi <bestswngs@gmail.com>
> > > Signed-off-by: Xiang Mei <xmei5@asu.edu>
> >
> > ...
>
^ permalink raw reply
* Re: [PATCH net] bridge: mrp: reject zero test interval to avoid OOM panic
From: Nikolay Aleksandrov @ 2026-03-28 6:18 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Simon Horman, Xiang Mei, netdev, bridge, idosch, davem, edumazet,
pabeni, bestswngs
In-Reply-To: <20260327171917.7575d715@kernel.org>
On 28/03/2026 02:19, Jakub Kicinski wrote:
> On Fri, 27 Mar 2026 13:46:39 +0200 Nikolay Aleksandrov wrote:
>> On 27/03/2026 13:34, Simon Horman wrote:
>>> On Wed, Mar 25, 2026 at 08:24:38PM -0700, Xiang Mei wrote:
>>>> br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
>>>> interval value from netlink without validation. When interval is 0,
>>>> usecs_to_jiffies(0) yields 0, causing the delayed work
>>>> (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
>>>> itself with zero delay. This creates a tight loop on system_percpu_wq
>>>> that allocates and transmits MRP test frames at maximum rate, exhausting
>>>> all system memory and causing a kernel panic via OOM deadlock.
>>>
>>> I would suspect the primary outcome of this problem is high CPU consumption
>>> rather than memory exhaustion. Is there a reason to expect that
>>> the transmitted fames can't be consumed as fast as they are created?
>>
>> +1
>> More so with CAP_NET_ADMIN you can cause all sorts of OOM and high-cpu usage
>> conditions. This is a configuration error and OOM doesn't lead to panic unless
>> instructed to. I don't think this is worth changing at all.
>
> Then again if there's no practical use for 0 we should consider
> the risk of getting this sort of submission over and over again?
> Dunno..
Sure, I'm fine either way. To that end the patch looks good, just need the
fixes tag as mentioned earlier.
^ permalink raw reply
* [PATCH net v6] bnxt_en: validate firmware backing store types
From: Pengpeng Hou @ 2026-03-28 6:08 UTC (permalink / raw)
To: michael.chan
Cc: pavan.chebbi, andrew+netdev, davem, edumazet, kuba, pabeni,
netdev, linux-kernel, pengpeng
bnxt_hwrm_func_backing_store_qcaps_v2() stores resp->type from the
firmware response in ctxm->type and later uses that value to index
fixed backing-store metadata arrays such as ctx_arr[] and
bnxt_bstore_to_trace[].
ctxm->type is fixed by the current backing-store query type and matches
the array index of ctx->ctx_arr. Avoid depending on resp->type and assign
ctxm->type from the current loop variable instead. Keep next_valid_type in
a dedicated variable so loop control stays clear for non-valid or
unchanged entries.
Fixes: 6a4d0774f02d ("bnxt_en: Add support for new backing store query firmware API")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
v6:
- assign ctxm->type from the current query type
- stop depending on resp->type
Link: https://lore.kernel.org/r/20260327010235.42668-1-pengpeng@iscas.ac.cn
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 0751c0e4581a..db8152c66d32 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -8692,6 +8692,7 @@ static int bnxt_hwrm_func_backing_store_qcaps_v2(struct bnxt *bp)
u8 init_val, init_off, i;
u32 max_entries;
u16 entry_size;
+ u16 next_type;
__le32 *p;
u32 flags;
@@ -8700,22 +8701,24 @@ static int bnxt_hwrm_func_backing_store_qcaps_v2(struct bnxt *bp)
if (rc)
goto ctx_done;
flags = le32_to_cpu(resp->flags);
- type = le16_to_cpu(resp->next_valid_type);
+ next_type = le16_to_cpu(resp->next_valid_type);
if (!(flags & BNXT_CTX_MEM_TYPE_VALID)) {
bnxt_free_one_ctx_mem(bp, ctxm, true);
+ type = next_type;
continue;
}
entry_size = le16_to_cpu(resp->entry_size);
max_entries = le32_to_cpu(resp->max_num_entries);
if (ctxm->mem_valid) {
- if (!(flags & BNXT_CTX_MEM_PERSIST) ||
- ctxm->entry_size != entry_size ||
- ctxm->max_entries != max_entries)
- bnxt_free_one_ctx_mem(bp, ctxm, true);
- else
+ if ((flags & BNXT_CTX_MEM_PERSIST) &&
+ ctxm->entry_size == entry_size &&
+ ctxm->max_entries == max_entries) {
+ type = next_type;
continue;
+ }
+ bnxt_free_one_ctx_mem(bp, ctxm, true);
}
- ctxm->type = le16_to_cpu(resp->type);
+ ctxm->type = type;
ctxm->entry_size = entry_size;
ctxm->flags = flags;
ctxm->instance_bmap = le32_to_cpu(resp->instance_bit_map);
@@ -8731,6 +8734,7 @@ static int bnxt_hwrm_func_backing_store_qcaps_v2(struct bnxt *bp)
for (i = 0, p = &resp->split_entry_0; i < ctxm->split_entry_cnt;
i++, p++)
ctxm->split[i] = le32_to_cpu(*p);
+ type = next_type;
}
rc = bnxt_alloc_all_ctx_pg_info(bp, BNXT_CTX_V2_MAX);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH net] bridge: mrp: reject zero test interval to avoid OOM panic
From: Xiang Mei @ 2026-03-28 6:06 UTC (permalink / raw)
To: Simon Horman
Cc: netdev, bridge, razor, idosch, davem, edumazet, pabeni, bestswngs
In-Reply-To: <20260327113412.GD567789@horms.kernel.org>
On Fri, Mar 27, 2026 at 11:34:12AM +0000, Simon Horman wrote:
> On Wed, Mar 25, 2026 at 08:24:38PM -0700, Xiang Mei wrote:
> > br_mrp_start_test() and br_mrp_start_in_test() accept the user-supplied
> > interval value from netlink without validation. When interval is 0,
> > usecs_to_jiffies(0) yields 0, causing the delayed work
> > (br_mrp_test_work_expired / br_mrp_in_test_work_expired) to reschedule
> > itself with zero delay. This creates a tight loop on system_percpu_wq
> > that allocates and transmits MRP test frames at maximum rate, exhausting
> > all system memory and causing a kernel panic via OOM deadlock.
>
> I would suspect the primary outcome of this problem is high CPU consumption
> rather than memory exhaustion. Is there a reason to expect that
> the transmitted fames can't be consumed as fast as they are created?
>
yes, you are right. In the default veth setup, the primary effect there
is CPU exhaustion. However, if a qdisc with delay (e.g., netem) is
attached to the bridge port, skbs accumulate in the qdisc and are never
freed, leading to actual OOM. Both the qdisc attachment and the MRP
configuration are reachable from the same unprivileged context.
In our test, for a 3.5GB ram machine, with interval=0, OOM leads to a
kernel panic in 10 sec:
[ 10.901868] Kernel panic - not syncing: System is deadlocked on memory
[ 10.902139] CPU: 0 UID: 0 PID: 2 Comm: kthreadd Not tainted 7.0.0-rc4+ #6 PREEMPTLAZY
[ 10.902525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
[ 10.903045] Call Trace:
[ 10.903163] <TASK>
[ 10.903262] vpanic+0x694/0x780
[ 10.903451] ? __pfx_vpanic+0x10/0x10
[ 10.903625] ? __pfx__raw_spin_lock+0x10/0x10
[ 10.903811] panic+0xca/0xd0
[ 10.903952] ? __pfx_panic+0x10/0x10
[ 10.904118] ? panic_on_this_cpu+0x1a/0x40
[ 10.904319] out_of_memory+0x124e/0x1350
[ 10.904497] ? __pfx_out_of_memory+0x10/0x10
[ 10.904694] __alloc_pages_slowpath.constprop.0+0x2325/0x2dd0
[ 10.904949] ? __pfx___alloc_pages_slowpath.constprop.0+0x10/0x10
[ 10.905214] __alloc_frozen_pages_noprof+0x4f8/0x800
[ 10.905445] ? __pfx___alloc_frozen_pages_noprof+0x10/0x10
[ 10.905686] ? kasan_save_track+0x14/0x30
When interval=1, we can't crash the kernel even though netem reaching
sch->limit. You are right, it's a race between creating and comsuming.
But interval=0 gives the the user too much power to win the race easily.
> >
> > The same zero-interval issue applies to br_mrp_start_in_test_parse()
> > for interconnect test frames.
> >
> > Use NLA_POLICY_MIN(NLA_U32, 1) in the nla_policy tables for both
> > IFLA_BRIDGE_MRP_START_TEST_INTERVAL and
> > IFLA_BRIDGE_MRP_START_IN_TEST_INTERVAL, so zero is rejected at the
> > netlink attribute parsing layer before the value ever reaches the
> > workqueue scheduling code. This is consistent with how other bridge
> > subsystems (br_fdb, br_mst) enforce range constraints on netlink
> > attributes.
> >
> > Fixes: 7ab1748e4ce6 ("bridge: mrp: Extend MRP netlink interface for configuring MRP interconnect")
>
> I think you also want
>
> Fixes: 20f6a05ef635 ("bridge: mrp: Rework the MRP netlink interface")
>
> As highlighted by AI review.
Thanks for the reminder.
>
> > Reported-by: Weiming Shi <bestswngs@gmail.com>
> > Signed-off-by: Xiang Mei <xmei5@asu.edu>
>
> ...
^ permalink raw reply
* [syzbot] [mm?] [cgroups?] WARNING in page_counter_uncharge (2)
From: syzbot @ 2026-03-28 5:14 UTC (permalink / raw)
To: akpm, cgroups, hannes, linux-kernel, linux-mm, mhocko,
muchun.song, netdev, roman.gushchin, shakeel.butt, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 5597dd284ff8 net: ti: icssg-prueth: fix missing data copy ..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=17f536da580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6754c86e8d9e4c91
dashboard link: https://syzkaller.appspot.com/bug?extid=226c1f947186f8fef796
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=131baeda580000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=167d6f72580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b6c0ef6a1be9/disk-5597dd28.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/38b971059ff5/vmlinux-5597dd28.xz
kernel image: https://storage.googleapis.com/syzbot-assets/55dd4bd79e77/bzImage-5597dd28.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+226c1f947186f8fef796@syzkaller.appspotmail.com
------------[ cut here ]------------
page_counter underflow: -512 nr_pages=512
WARNING: mm/page_counter.c:61 at page_counter_cancel mm/page_counter.c:60 [inline], CPU#1: syz.0.3396/16434
WARNING: mm/page_counter.c:61 at page_counter_uncharge+0xd2/0x150 mm/page_counter.c:184, CPU#1: syz.0.3396/16434
Modules linked in:
CPU: 1 UID: 0 PID: 16434 Comm: syz.0.3396 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
RIP: 0010:page_counter_cancel mm/page_counter.c:60 [inline]
RIP: 0010:page_counter_uncharge+0xd8/0x150 mm/page_counter.c:184
Code: f7 e8 7c 88 f8 ff 4d 8b 36 4d 85 f6 74 6e e8 cf 3f 8e ff e9 6c ff ff ff e8 c5 3f 8e ff 48 8d 3d 2e ea df 0d 4c 89 fe 48 89 da <67> 48 0f b9 3a 4c 89 f7 be 08 00 00 00 e8 e6 8a f8 ff 4c 89 f0 48
RSP: 0018:ffffc9000da772b0 EFLAGS: 00010093
RAX: ffffffff82376eab RBX: 0000000000000200 RCX: ffff88807c631e80
RDX: 0000000000000200 RSI: fffffffffffffe00 RDI: ffffffff901758e0
RBP: fffffffffffffe00 R08: ffff888032fd5387 R09: 1ffff110065faa70
R10: dffffc0000000000 R11: ffffed10065faa71 R12: 0000000000000001
R13: dffffc0000000000 R14: ffff888032fd5380 R15: fffffffffffffe00
FS: 0000000000000000(0000) GS:ffff88812555a000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f14ec9d5ff8 CR3: 000000000e54c000 CR4: 00000000003526f0
Call Trace:
<TASK>
__hugetlb_cgroup_uncharge_folio+0x15e/0x510 mm/hugetlb_cgroup.c:354
free_huge_folio+0xaef/0x11e0 mm/hugetlb.c:1782
folios_put_refs+0x553/0x8d0 mm/swap.c:983
folio_batch_release include/linux/pagevec.h:101 [inline]
remove_inode_hugepages+0xf50/0x11a0 fs/hugetlbfs/inode.c:608
hugetlbfs_evict_inode+0xaf/0x260 fs/hugetlbfs/inode.c:623
evict+0x61e/0xb10 fs/inode.c:846
__dentry_kill+0x1a2/0x5e0 fs/dcache.c:670
finish_dput+0xc9/0x480 fs/dcache.c:879
__fput+0x691/0xa70 fs/file_table.c:477
task_work_run+0x1d9/0x270 kernel/task_work.c:233
exit_task_work include/linux/task_work.h:40 [inline]
do_exit+0x70f/0x23c0 kernel/exit.c:976
do_group_exit+0x21b/0x2d0 kernel/exit.c:1118
get_signal+0x1284/0x1330 kernel/signal.c:3034
arch_do_signal_or_restart+0xbc/0x830 arch/x86/kernel/signal.c:337
__exit_to_user_mode_loop kernel/entry/common.c:64 [inline]
exit_to_user_mode_loop+0x86/0x480 kernel/entry/common.c:98
__exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]
syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]
syscall_exit_to_user_mode include/linux/entry-common.h:325 [inline]
do_syscall_64+0x32d/0xf80 arch/x86/entry/syscall_64.c:100
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f14ebb9c799
Code: Unable to access opcode bytes at 0x7f14ebb9c76f.
RSP: 002b:00007f14ec9d60e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 00007f14ebe16098 RCX: 00007f14ebb9c799
RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007f14ebe16098
RBP: 00007f14ebe16090 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f14ebe16128 R14: 00007ffc404c7910 R15: 00007ffc404c79f8
</TASK>
----------------
Code disassembly (best guess):
0: f7 e8 imul %eax
2: 7c 88 jl 0xffffff8c
4: f8 clc
5: ff 4d 8b decl -0x75(%rbp)
8: 36 4d 85 f6 ss test %r14,%r14
c: 74 6e je 0x7c
e: e8 cf 3f 8e ff call 0xff8e3fe2
13: e9 6c ff ff ff jmp 0xffffff84
18: e8 c5 3f 8e ff call 0xff8e3fe2
1d: 48 8d 3d 2e ea df 0d lea 0xddfea2e(%rip),%rdi # 0xddfea52
24: 4c 89 fe mov %r15,%rsi
27: 48 89 da mov %rbx,%rdx
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 4c 89 f7 mov %r14,%rdi
32: be 08 00 00 00 mov $0x8,%esi
37: e8 e6 8a f8 ff call 0xfff88b22
3c: 4c 89 f0 mov %r14,%rax
3f: 48 rex.W
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* Re: [PATCH net 2/2] net: bcmgenet: fix racing timeout handler
From: Jakub Kicinski @ 2026-03-28 4:13 UTC (permalink / raw)
To: justin.chen
Cc: netdev, pabeni, edumazet, davem, andrew+netdev,
bcm-kernel-feedback-list, florian.fainelli, opendmb, nb
In-Reply-To: <20260326184529.1393438-3-justin.chen@brodcom.com>
On Thu, 26 Mar 2026 11:45:29 -0700 justin.chen@broadcom.com wrote:
> The bcmgenet_timeout handler tries to take down all tx queues when
> a single queue times out. This is over zealous and causes many race
> conditions with queues that are still chugging along. Instead lets
> only restart the timed out queue.
FWIW AI seems to suggest we should also stop NAPI and the DMA in this
case, just to make sure that the queue in question doesn't suddenly
wake up either. Which seems fair but probably as a follow up and only
if not too hard in itself..
^ permalink raw reply
* Re: [PATCH net 1/2] net: bcmgenet: fix leaking free_bds
From: Jakub Kicinski @ 2026-03-28 4:11 UTC (permalink / raw)
To: justin.chen
Cc: netdev, pabeni, edumazet, davem, andrew+netdev,
bcm-kernel-feedback-list, florian.fainelli, opendmb, nb
In-Reply-To: <20260326184529.1393438-2-justin.chen@brodcom.com>
On Thu, 26 Mar 2026 11:45:28 -0700 justin.chen@broadcom.com wrote:
> From: Justin Chen <justin.chen@broadcom.com>
>
> While reclaiming the tx queue we fast forward the write pointer to
> drop any data in flight. These dropped frames are not added back
> to the pool of free bds. We also need to tell the netdev that we
> are dropping said data.
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index 482a31e7b72b..3e1fc3bb8297 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -1985,6 +1985,7 @@ static unsigned int bcmgenet_tx_reclaim(struct net_device *dev,
> drop = (ring->prod_index - ring->c_index) & DMA_C_INDEX_MASK;
> released += drop;
> ring->prod_index = ring->c_index & DMA_C_INDEX_MASK;
> + ring->free_bds += drop;
> while (drop--) {
> cb_ptr = bcmgenet_put_txcb(priv, ring);
> skb = cb_ptr->skb;
> @@ -1996,6 +1997,7 @@ static unsigned int bcmgenet_tx_reclaim(struct net_device *dev,
> }
> if (skb)
> dev_consume_skb_any(skb);
> + netdev_tx_reset_queue(netdev_get_tx_queue(dev, ring->index));
> bcmgenet_tdma_ring_writel(priv, ring->index,
> ring->prod_index, TDMA_PROD_INDEX);
> wr_ptr = ring->write_ptr * WORDS_PER_BD(priv);
AI says you may be off by one here?
Does this loop miss the oldest dropped descriptor and leak its SKB and
DMA mapping?
Since bcmgenet_get_txcb() increments write_ptr after a transmission,
write_ptr always points to the next available empty slot.
When this loops backwards drop times, the first iteration retrieves that
empty descriptor (where cb->skb is NULL), and the loop will finish before
reaching the oldest uncompleted descriptor at c_index.
When write_ptr is rolled back to c_index, won't subsequent transmissions
overwrite the descriptor at c_index and permanently leak the unmapped DMA
buffer and SKB memory?
^ 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