* Re: [PATCH net] net/sched: act_ct: fix skb leak on fragment check failure
From: Jamal Hadi Salim @ 2026-04-16 15:31 UTC (permalink / raw)
To: Dudu Lu; +Cc: netdev, jiri, horms
In-Reply-To: <20260416130138.38050-1-phx0fer@gmail.com>
On Thu, Apr 16, 2026 at 9:01 AM Dudu Lu <phx0fer@gmail.com> wrote:
>
> When tcf_ct_handle_fragments() returns an error other than -EINPROGRESS
> (e.g. -EINVAL from malformed fragments), tcf_ct_act() jumps to out_frag
> which unconditionally returns TC_ACT_CONSUMED. This tells the caller the
> skb was consumed, but it was not freed, leaking one skb per malformed
> fragment.
>
> TC_ACT_CONSUMED is only correct for -EINPROGRESS, where defragmentation
> is genuinely in progress and the skb has been queued. For all other
> errors the skb is still owned by the caller and must be freed via
> TC_ACT_SHOT.
>
> Fixes: 3f14b377d01d ("net/sched: act_ct: fix skb leak and crash on ooo frags")
> Signed-off-by: Dudu Lu <phx0fer@gmail.com>
Do you have a reproducer? Always helps adding at least a tdc test.
Also: How did you find this issue? was it AI? If yes, please add the
tag "Assisted-by:<AI name here>"
cheers,
jamal
> ---
> net/sched/act_ct.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/sched/act_ct.c b/net/sched/act_ct.c
> index 7d5e50c921a0..870655f682bd 100644
> --- a/net/sched/act_ct.c
> +++ b/net/sched/act_ct.c
> @@ -1107,8 +1107,10 @@ TC_INDIRECT_SCOPE int tcf_ct_act(struct sk_buff *skb, const struct tc_action *a,
> return retval;
>
> out_frag:
> - if (err != -EINPROGRESS)
> + if (err != -EINPROGRESS) {
> tcf_action_inc_drop_qstats(&c->common);
> + return TC_ACT_SHOT;
> + }
> return TC_ACT_CONSUMED;
>
> drop:
> --
> 2.39.3 (Apple Git-145)
>
^ permalink raw reply
* Re: [PATCH net-next v6 0/2] net: mana: add ethtool private flag for full-page RX buffers
From: Jakub Kicinski @ 2026-04-16 15:31 UTC (permalink / raw)
To: Dipayaan Roy
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
pabeni, leon, longli, kotaranov, horms, shradhagupta, ssengar,
ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, leitao, kees, john.fastabend,
hawk, bpf, daniel, ast, sdf, dipayanroy
In-Reply-To: <ad5kuCZz+gR1TlSh@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
On Tue, 14 Apr 2026 09:00:56 -0700 Dipayaan Roy wrote:
> I still see roughly a 5% overhead from the atomic refcount operation
> itself, but on that platform there is no throughput drop when using
> page fragments versus full-page mode.
That seems to contradict your claim that it's a problem with a specific
platform.. Since we're in the merge window I asked David Wei to try to
experiment with disabling page fragmentation on the ARM64 platforms we
have at Meta. If it repros we should use the generic rx-buf-len
ringparam because more NICs may want to implement this strategy.
^ permalink raw reply
* Re: [PATCH v5 net-next 0/8] dpll/ice: Add TXC DPLL type and full TX reference clock control for E825
From: Jakub Kicinski @ 2026-04-16 15:27 UTC (permalink / raw)
To: Kubalewski, Arkadiusz
Cc: Nitka, Grzegorz, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
Oros, Petr, richardcochran@gmail.com, andrew+netdev@lunn.ch,
Kitszel, Przemyslaw, Nguyen, Anthony L,
Prathosh.Satish@microchip.com, Vecera, Ivan, jiri@resnulli.us,
vadim.fedorenko@linux.dev, donald.hunter@gmail.com,
horms@kernel.org, pabeni@redhat.com, davem@davemloft.net,
edumazet@google.com
In-Reply-To: <IA0PR11MB737842E2098D0952A8BA1FE29B222@IA0PR11MB7378.namprd11.prod.outlook.com>
On Wed, 15 Apr 2026 13:23:22 +0000 Kubalewski, Arkadiusz wrote:
> >> Well, the true is that we did not anticipated per-port control of the
> >> TX clock source, as a single DPLL device could drive multiple of such.
> >>
> >> This is not true, that we pretend there is a second PLL - there is a
> >> PLL on each TX clock, maybe not a full DPLL, but still the loop with
> >> a control over it's sources is there and it has the same 2 external
> >> sources + default XO.
> >
> >Don't we put that MAC PLL into bypass mode if we feed a clock from
> >the EEC DPLL?
>
> This HW doesn't use EEC DPLL signal to feed MAC clock, as DPLL is
> external from NIC point of view. Only 2 signals from such external DPLL
> device are used by NIC:
> - synce (a single source for all those TXC per-port DPLL device)
> - time_ref (a source for the TS_PLL - which drives PTP timer)
No bypass? The PLL is actually in the loop? oof, this is beyond
my understanding of clocks and signals :S
> >> A mentioned try of adding per port MUX-type pin, just to give some
> >>control
> >> to the user, is where we wanted to simplify things, but in the end the
> >>API
> >> would have to be modified in significant way, various paths related to
> >>pin
> >> registration and keeping correct references, just to make working case
> >> for the pin_on_pin_register and it's internals. We decided that the
> >>burden
> >> and impact for existing design was to high.
> >>
> >> And that is why the TXC approach emerged, the change of DPLL is minimal,
> >> The model is still correct from user perspective, SyncE SW controller
> >>shall
> >> anticipate possibility that per-port TXC dpll is there
> >
> >We are starting to push into what was previously the domain of
> >drivers/clk, tho. IIUC the "ASIC PLL"s are usually integrated with
> >clock dividers. And cannot be "configured" after chip init / async
> >reset (which is why I presume you whack a reset in patch 7?).
>
> Well, we need CGU-dividers change for a frequency-compliance with lower
> link speeds, the link reset which is required as part of tx-clk switch
> and link establishment on a new clock.
>
> >
> >> This particular device and driver doesn't implement any EEC-type DPLL
> >> device, the one could think that we can just change the type here and
> >>use
> >> EEC type instead of new one TXC - since we share pins from external dpll
> >> driver, which is EEC type, and our DPLL device would have different
> >>clock_id
> >> and module. But, further designs, where a single NIC is having control
> >>over
> >> both a EEC DPLL and ability to control each source per-port this would
> >>be
> >> problematic. At least one NIC Port driver would have to have 2 EEC-type
> >>DPLLs
> >> leaving user with extra confusion.
> >
> >The distinction between TXC and EEC dpll is confusing.
> >I thought EEC one _was_supposed_to_ drive the Tx clock?
> >What PPS means is obvious, what EEC means if not driving Tx clock is
> >unclear to me..
> >
>
> Yes, correct, EEC DPLL main task would be to drive TX clocks of NIC
> ports, but if there is a per-port control something extra is required.
>
> >Let me summarize my concerns - we need to navigate the split between
> >drivers/clk and dpll. We need a distinction on what goes where, because
> >every ASIC has a bunch of PLLs which until now have been controlled by
> >device tree (if at all). If the main question we want to answer is
> >"which clock ref is used to drive internal clock" all we need is a MUX.
> >If we want to make dpll cover also ASIC PLLs for platforms without
> >device tree we need a more generic name than TXC, IMHO.
>
> Well, 'floating' MUX type pin not connected to any dpll would require a
> lot of additional implementations, just to allow source selection, as we
> have tried it already.
>
> Wouldn't more generic name cause a DPLL purpose problem?
The old proposal in netdev family was to to have source selection
without creating a real mux. Not saying I'm dead set on that direction.
> We still want to make sure that given DPLL device would serve the role
> of source selection for particular port where a source pin should be an
> output either on EEC dpll or some external signal generator but somehow
> related to SyncE or similar solutions.
Right, but adding a new "type" per location of the PLL (especially if
we lean into covering any ASIC PLL) may not scale, and opens us up to
"vendor X calls it Y" and "in design A clock is fed by pll type X and
in design B by type Y".
IIUC you do provide "linking" of the pins? netdev will have the MAC pin
assigned. Is the pin that connects the PLLs also annotated so that user
knows what's on the "other side"? Maybe the topology would be clear
enough from just that, and we don't have to add a TXC type.
Call the PLL "integrated" or something generic. User should be able to
trace the path of the signals?
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-net 2/2] idpf: fix skb datapath queue based scheduling crashes and timeouts
From: Salin, Samuel @ 2026-04-16 15:24 UTC (permalink / raw)
To: Loktionov, Aleksandr, Hay, Joshua A,
intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org
In-Reply-To: <IA3PR11MB8986B2581A07EC756D0D9186E55BA@IA3PR11MB8986.namprd11.prod.outlook.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf Of
> Loktionov, Aleksandr
> Sent: Tuesday, April 7, 2026 11:37 PM
> To: Hay, Joshua A <joshua.a.hay@intel.com>; intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org
> Subject: Re: [Intel-wired-lan] [PATCH iwl-net 2/2] idpf: fix skb datapath queue
> based scheduling crashes and timeouts
>
>
>
> > -----Original Message-----
> > From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> > Of Joshua Hay
> > Sent: Tuesday, April 7, 2026 1:33 AM
> > To: intel-wired-lan@lists.osuosl.org
> > Cc: netdev@vger.kernel.org
> > Subject: [Intel-wired-lan] [PATCH iwl-net 2/2] idpf: fix skb datapath
> > queue based scheduling crashes and timeouts
> >
> > The splitq Tx resource checks were assuming that the queues were using
> > flow based scheduling and checking the refillqs for free buffers.
> > However, the Tx refillqs are not allocated when using queue based
> > scheduling resulting in a NULL ptr dereference. Adjust the Tx resource
> > checks to only check available descriptor resources when using queue
> > based scheduling. Because queue based scheduling does not have any
> > notion of descriptor only completions, there cannot be any packets in
> > flight, meaning there is no need to check for pending completions.
> >
> > The driver also only supported 8 byte completion descriptors in the
> > skb datapath previously. However, currently the FW only supports 4
> > byte completion descriptors when using queue based scheduling. This
> > meant we were skipping over completions, resulting in Tx timeouts.
> > Add support to process both 4 and 8 byte completion descriptors,
> > depending on the scheduling mode. Cache the next_to_clean completion
> > descriptor in the completion queue struct, and fetch this descriptor
> > before the start of each cleaning loop. Access the next descriptor in
> > the loop by calculating the index based on raw byte count.
> >
> > Fixes: 0c3f135e840d ("idpf: stop Tx if there are insufficient buffer
> > resources")
> > Fixes: 1c325aac10a8 ("idpf: configure resources for TX queues")
> > Signed-off-by: Joshua Hay <joshua.a.hay@intel.com>
> > Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
> > ---
> > drivers/net/ethernet/intel/idpf/idpf_txrx.c | 49 +++++++++++++-------
> > - drivers/net/ethernet/intel/idpf/idpf_txrx.h | 6 ++-
> > 2 files changed, 36 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> > b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> > index f6b3b15364ff..4fc0bb14c5b1 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
> > @@ -270,11 +270,9 @@ static int idpf_tx_desc_alloc(const struct
> > idpf_vport *vport, static int idpf_compl_desc_alloc(const struct
> > idpf_vport *vport,
> > struct idpf_compl_queue *complq) {
>
> ...
>
> >
> > /**
> > * struct idpf_sw_queue
> > --
> > 2.39.2
>
>
> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
^ permalink raw reply
* Re: [PATCH v2] net: phy: air_en8811h: add AN8811HB MCU assert/deassert support
From: Lucien.Jheng @ 2026-04-16 15:24 UTC (permalink / raw)
To: Eric Woudstra, andrew, hkallweit1, linux, davem, edumazet, kuba,
pabeni, netdev, linux-kernel, bjorn
Cc: frank-w, daniel, lucien.jheng
In-Reply-To: <5de3f9ca-ffe7-40ca-93a7-fb7e8e513ec2@gmail.com>
Hi Eric
Lucien.Jheng 於 2026/3/29 下午 01:04 寫道:
>
> Eric Woudstra 於 2026/3/27 下午 12:41 寫道:
>>
>> On 3/26/26 4:35 PM, Lucien.Jheng wrote:
>>> AN8811HB needs a MCU soft-reset cycle before firmware loading begins.
>>> Assert the MCU (hold it in reset) and immediately deassert (release)
>>> via a dedicated PBUS register pair (0x5cf9f8 / 0x5cf9fc), accessed
>>> through the PHY-addr+8 MDIO bus node rather than the BUCKPBUS indirect
>>> path. This clears the MCU state before the firmware loading sequence
>>> starts.
>>>
>>> Add __air_pbus_reg_write() as a low-level helper for this access, then
>>> implement an8811hb_mcu_assert() / _deassert() on top of it. Wire both
>>> into an8811hb_load_firmware() and en8811h_restart_mcu() so every
>>> firmware load or MCU restart on AN8811HB correctly sequences the reset
>>> control registers.
>>>
>>> Fixes: 0a55766b7711 ("net: phy: air_en8811h: add Airoha AN8811HB
>>> support")
>>> Signed-off-by: Lucien Jheng <lucienzx159@gmail.com>
>>> ---
>>> Changes in v2:
>>> - Rewrite commit message: The previous wording was ambiguous,
>>> as it suggested the MCU remains asserted during the entire
>>> firmware loading process, rather than a quick reset cycle
>>> before it starts.
>>> Clarify that assert and deassert is an immediate soft-reset
>>> cycle to clear MCU state before firmware loading begins.
>>> - Add Fixes: 0a55766b7711 ("net: phy: air_en8811h: add Airoha AN8811HB
>>> support").
>>> - Change phydev_info() to phydev_dbg() in an8811hb_mcu_assert() and
>>> an8811hb_mcu_deassert() to avoid noise during normal boot.
>>>
>>> drivers/net/phy/air_en8811h.c | 105
>>> ++++++++++++++++++++++++++++++++++
>>> 1 file changed, 105 insertions(+)
>>>
>>> diff --git a/drivers/net/phy/air_en8811h.c
>>> b/drivers/net/phy/air_en8811h.c
>>> index 29ae73e65caa..01fce1b93618 100644
>>> --- a/drivers/net/phy/air_en8811h.c
>>> +++ b/drivers/net/phy/air_en8811h.c
>>> @@ -170,6 +170,16 @@
>>> #define AN8811HB_CLK_DRV_CKO_LDPWD BIT(13)
>>> #define AN8811HB_CLK_DRV_CKO_LPPWD BIT(14)
>>>
>>> +#define AN8811HB_MCU_SW_RST 0x5cf9f8
>>> +#define AN8811HB_MCU_SW_RST_HOLD BIT(16)
>>> +#define AN8811HB_MCU_SW_RST_RUN (BIT(16) | BIT(0))
>>> +#define AN8811HB_MCU_SW_START 0x5cf9fc
>>> +#define AN8811HB_MCU_SW_START_EN BIT(16)
>>> +
>>> +/* MII register constants for PBUS access (PHY addr + 8) */
>>> +#define AIR_PBUS_ADDR_HIGH 0x1c
>>> +#define AIR_PBUS_DATA_HIGH 0x10
>>> +
>>> /* Led definitions */
>>> #define EN8811H_LED_COUNT 3
>>>
>>> @@ -254,6 +264,36 @@ static int air_phy_write_page(struct phy_device
>>> *phydev, int page)
>>> return __phy_write(phydev, AIR_EXT_PAGE_ACCESS, page);
>>> }
>>>
>>> +static int __air_pbus_reg_write(struct phy_device *phydev,
>>> + u32 pbus_reg, u32 pbus_data)
>>> +{
>>> + struct mii_bus *bus = phydev->mdio.bus;
>>> + int pbus_addr = phydev->mdio.addr + 8;
>>> + int ret;
>>> +
>>> + ret = __mdiobus_write(bus, pbus_addr, AIR_EXT_PAGE_ACCESS,
>>> + upper_16_bits(pbus_reg));
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = __mdiobus_write(bus, pbus_addr, AIR_PBUS_ADDR_HIGH,
>>> + (pbus_reg & GENMASK(15, 6)) >> 6);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = __mdiobus_write(bus, pbus_addr, (pbus_reg & GENMASK(5,
>>> 2)) >> 2,
>>> + lower_16_bits(pbus_data));
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = __mdiobus_write(bus, pbus_addr, AIR_PBUS_DATA_HIGH,
>>> + upper_16_bits(pbus_data));
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + return 0;
>>> +}
>>> +
>> Maybe you can use mutex_lock() and mutex_unlock() here also, like so:
After checking, I decided not to implement mutex_lock in pbus_read/write.
This is because these functions are only used within
an8811hb_mcu_assert/deassert.
Since these sequences cannot be interrupted, a mutex lock is not required.
Thanks
>>
>> static int __air_pbus_reg_write(struct mdio_device *mdio, u32
>> pbus_address,
>> u32 pbus_data)
>> {
>> int ret;
>>
>> ret = __mdiobus_write(mdio->bus, mdio->addr, AIR_EXT_PAGE_ACCESS,
>> (u16)(pbus_address >> 6));
>> if (ret < 0)
>> return ret;
>>
>> ret = __mdiobus_write(mdio->bus, mdio->addr, (pbus_address >> 2)
>> & 0xf,
>> (u16)pbus_data);
>> if (ret < 0)
>> return ret;
>>
>> ret = __mdiobus_write(mdio->bus, mdio->addr, AIR_PBUS_DATA_HIGH,
>> (u16)(pbus_data >> 16));
>> if (ret < 0)
>> return ret;
>>
>> return 0;
>> }
>>
>> static int air_pbus_reg_write(struct mdio_device *mdio, u32
>> pbus_address,
>> u32 pbus_data)
>> {
>> int ret;
>>
>> mutex_lock(&mdio->bus->mdio_lock);
>>
>> ret = __air_pbus_reg_write(mdio, pbus_address, pbus_data);
>> if (ret < 0)
>> dev_err(&mdio->dev, "%s 0x%08x failed: %d\n", __func__,
>> pbus_address, ret);
>>
>> mutex_unlock(&mdio->bus->mdio_lock);
>>
>> return ret;
>> }
>>
>> static int __air_pbus_reg_read(struct mdio_device *mdio, u32
>> pbus_address,
>> u32 *pbus_data)
>> {
>> int ret, pbus_data_low;
>>
>> ret = __mdiobus_write(mdio->bus, mdio->addr, AIR_EXT_PAGE_ACCESS,
>> (u16)(pbus_address >> 6));
>> if (ret < 0)
>> return ret;
>>
>> ret = __mdiobus_read(mdio->bus, mdio->addr, (pbus_address >> 2) &
>> 0xf);
>> if (ret < 0)
>> return ret;
>> pbus_data_low = ret;
>>
>> ret = __mdiobus_read(mdio->bus, mdio->addr, AIR_PBUS_DATA_HIGH);
>> if (ret < 0)
>> return ret;
>>
>> *pbus_data = (ret << 16) + pbus_data_low;
>>
>> return 0;
>> }
>>
>> static int air_pbus_reg_read(struct mdio_device *mdio, u32 pbus_address,
>> u32 *pbus_data)
>> {
>> int ret;
>>
>> mutex_lock(&mdio->bus->mdio_lock);
>>
>> ret = __air_pbus_reg_read(mdio, pbus_address, pbus_data);
>> if (ret < 0)
>> dev_err(&mdio->dev, "%s 0x%08x failed: %d\n", __func__,
>> pbus_address, ret);
>>
>> mutex_unlock(&mdio->bus->mdio_lock);
>>
>> return ret;
>> }
>>
>> With:
>>
>> #define AIR_PBUS_DATA_HIGH 0x10
>>
> Thank you for your feedback.
>
> I should add mutex_lock() and mutex_unlock() to protect these operations.
>
> I will include this in the next version.
>
>>> static int __air_buckpbus_reg_write(struct phy_device *phydev,
>>> u32 pbus_address, u32 pbus_data)
>>> {
>>> @@ -570,10 +610,65 @@ static int an8811hb_load_file(struct
>>> phy_device *phydev, const char *name,
>>> return ret;
>>> }
>>>
>>> +static int an8811hb_mcu_assert(struct phy_device *phydev)
>>> +{
>>> + int ret;
>>> +
>>> + phy_lock_mdio_bus(phydev);
>>> +
>>> + ret = __air_pbus_reg_write(phydev, AN8811HB_MCU_SW_RST,
>>> + AN8811HB_MCU_SW_RST_HOLD);
>>> + if (ret < 0)
>>> + goto unlock;
>>> +
>>> + ret = __air_pbus_reg_write(phydev, AN8811HB_MCU_SW_START, 0);
>>> + if (ret < 0)
>>> + goto unlock;
>>> +
>>> + msleep(50);
>>> + phydev_dbg(phydev, "MCU asserted\n");
>>> +
>>> +unlock:
>>> + phy_unlock_mdio_bus(phydev);
>>> + return ret;
>>> +}
>>> +
>>> +static int an8811hb_mcu_deassert(struct phy_device *phydev)
>>> +{
>>> + int ret;
>>> +
>>> + phy_lock_mdio_bus(phydev);
>>> +
>>> + ret = __air_pbus_reg_write(phydev, AN8811HB_MCU_SW_START,
>>> + AN8811HB_MCU_SW_START_EN);
>>> + if (ret < 0)
>>> + goto unlock;
>>> +
>>> + ret = __air_pbus_reg_write(phydev, AN8811HB_MCU_SW_RST,
>>> + AN8811HB_MCU_SW_RST_RUN);
>>> + if (ret < 0)
>>> + goto unlock;
>>> +
>>> + msleep(50);
>>> + phydev_dbg(phydev, "MCU deasserted\n");
>>> +
>>> +unlock:
>>> + phy_unlock_mdio_bus(phydev);
>>> + return ret;
>>> +}
>>> +
>>> static int an8811hb_load_firmware(struct phy_device *phydev)
>>> {
>>> int ret;
>>>
>>> + ret = an8811hb_mcu_assert(phydev);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = an8811hb_mcu_deassert(phydev);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> ret = air_buckpbus_reg_write(phydev, EN8811H_FW_CTRL_1,
>>> EN8811H_FW_CTRL_1_START);
>>> if (ret < 0)
>>> @@ -662,6 +757,16 @@ static int en8811h_restart_mcu(struct
>>> phy_device *phydev)
>>> {
>>> int ret;
>>>
>>> + if (phy_id_compare_model(phydev->phy_id, AN8811HB_PHY_ID)) {
>>> + ret = an8811hb_mcu_assert(phydev);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + ret = an8811hb_mcu_deassert(phydev);
>>> + if (ret < 0)
>>> + return ret;
>>> + }
>>> +
>>> ret = air_buckpbus_reg_write(phydev, EN8811H_FW_CTRL_1,
>>> EN8811H_FW_CTRL_1_START);
>>> if (ret < 0)
>>> --
>>> 2.34.1
>>>
^ permalink raw reply
* Re: [PATCH] net/sched: act_mirred: Fix blockcast recursion bypass leading to stack overflow
From: Jamal Hadi Salim @ 2026-04-16 15:23 UTC (permalink / raw)
To: Simon Horman
Cc: hxzene, jiri, davem, edumazet, kuba, pabeni, victor, pctammela,
netdev, linux-kernel, Stephen Hemminger
In-Reply-To: <20260415141931.808383-1-horms@kernel.org>
On Wed, Apr 15, 2026 at 10:19 AM Simon Horman <horms@kernel.org> wrote:
>
> From: 'Simon Horman' <horms@kernel.org>
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://sashiko.dev
> ---
> net/sched: act_mirred: Fix blockcast recursion bypass leading to stack overflow
>
> This patch fixes a stack overflow bug where mirred blockcast actions would
> bypass the recursion limit check because the recursion counter was not
> incremented for blockcast actions.
>
> > diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
> > index 05e0b14b57731..5928fcf3e6514 100644
> > --- a/net/sched/act_mirred.c
> > +++ b/net/sched/act_mirred.c
> > @@ -444,8 +444,12 @@ TC_INDIRECT_SCOPE int tcf_mirred_act(struct sk_buff *skb,
> > tcf_action_update_bstats(&m->common, skb);
> >
> > blockid = READ_ONCE(m->tcfm_blockid);
> > - if (blockid)
> > - return tcf_blockcast(skb, m, blockid, res, retval);
> > + if (blockid) {
> > + xmit->sched_mirred_nest++;
>
> Could this leave a stale pointer in sched_mirred_dev since netdev_xmit is
> persistent per-CPU (or per-task in PREEMPT_RT) memory?
>
> If a nested mirred action later iterates over sched_mirred_dev up to the new
> nesting depth to detect routing loops, could it match a stale pointer from
> whatever unrelated packet previously reached this nesting level?
>
> This might cause a false-positive loop detection and incorrectly drop a valid
> packet. Should we set xmit->sched_mirred_dev[xmit->sched_mirred_nest] = NULL
> before incrementing the counter?
>
> > + retval = tcf_blockcast(skb, m, blockid, res, retval);
>
> This isn't a regression introduced by this patch, but it exists in the early
> error returns of tcf_mirred_act() (e.g., when the target device is gone, or a
> routing loop is detected) and in tcf_blockcast() (e.g., when
> xa_empty(&block->ports) is true).
>
> In these error paths, the functions simply return retval. For mirred redirect
> actions, retval is initialized to m->tcf_action, which is typically
> TC_ACT_STOLEN.
>
> When TC_ACT_STOLEN is returned, the TC framework assumes the action has taken
> ownership of the packet and will not free the sk_buff. Since the code does
> not free the sk_buff before returning in these error paths, does this leak
> the sk_buff?
>
> Could an unprivileged user inside a network namespace trigger this
> intentionally by creating a routing loop with mirred redirect rules, leading
> to continuous sk_buff leaks and system memory exhaustion?
>
> Should these error paths ensure the sk_buff is freed or force the return value
> to TC_ACT_SHOT if the action is a redirect, mirroring the existing behavior in
> tcf_mirred_to_dev()?
>
> > + xmit->sched_mirred_nest--;
> > + return retval;
> > + }
There's a dependency with the skb bits patch[1] with this one.
Stephen, I will take this set and consider what Sashiko is saying here
[2]. I just became aware of this - but it seems to have some merit.
I will also review this patch and sashiko's input from that
perspective. If it merits it, I will resend the set incorporating this
fix and Sashiko's suggestions.
cheers,
jamal
[1]https://lore.kernel.org/netdev/20260326181701.308275-1-stephen@networkplumber.org/
[2] https://sashiko.dev/#/patchset/20260326181701.308275-1-stephen%40networkplumber.org
^ permalink raw reply
* Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Marek Vasut @ 2026-04-16 15:05 UTC (permalink / raw)
To: Andrew Lunn, Fidelio LAWSON
Cc: Woojung Huh, UNGLinuxDriver, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Maxime Chevallier,
Simon Horman, Heiner Kallweit, Russell King, netdev, linux-kernel,
Fidelio Lawson
In-Reply-To: <6a8fc2e6-830f-4f57-869b-41efe70557e5@lunn.ch>
On 4/16/26 4:30 PM, Andrew Lunn wrote:
>> With this model, we don’t need to return -EINVAL for combinations or
>> ordering, and userspace does not need detailed error reporting. The
>> tunables behave more like simple setters than a mode switch, which
>> keeps the API predictable and avoids the need for extack or netlink
>> ethtool support at this point.
>
> Sounds good.
Fine by me too.
^ permalink raw reply
* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Leon Romanovsky @ 2026-04-16 15:02 UTC (permalink / raw)
To: Keith Busch
Cc: Zhiping Zhang, Jason Gunthorpe, Bjorn Helgaas, linux-rdma,
linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas,
Bjorn Helgaas
In-Reply-To: <ad56liSM4zI2SWWp@kbusch-mbp>
On Tue, Apr 14, 2026 at 11:34:14AM -0600, Keith Busch wrote:
> On Thu, Apr 09, 2026 at 03:04:15PM +0300, Leon Romanovsky wrote:
> > Something like that, on top of this proposal:
>
> ...
>
> > +struct vfio_region_dma_tph {
> > + u16 tag;
> > + u8 ph;
> > +};
> > +
> > struct vfio_region_dma_range {
> > - __u64 offset;
> > - __u64 length;
> > + union {
> > + __u64 offset;
> > + struct vfio_region_dma_tph tph;
> > + };
> > + union {
> > + __u64 length;
> > + __u64 reserved;
> > + };
> > +};
> > +
> > +enum {
> > + VFIO_DMABUF_FLAG_TPH = 1 << 0,
> > };
>
> Okay, so you have the hints as a separate action from the dmabuf
> creation.
I'm not sure I fully understood your point, but in my proposal the entire
operation is done in one pass, with the hints provided as the final entry in
the dma_range array.
Thanks
^ permalink raw reply
* Re: [RFC PATCH 1/2] kernel/notifier: replace single-linked list with double-linked list for reverse traversal
From: Petr Mladek @ 2026-04-16 14:54 UTC (permalink / raw)
To: David Laight
Cc: chensong_2000, rafael, lenb, mturquette, sboyd, viresh.kumar, agk,
snitzer, mpatocka, bmarzins, song, yukuai, linan122, jason.wessel,
danielt, dianders, horms, davem, edumazet, kuba, pabeni, paulmck,
frederic, mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin,
jpoimboe, jikos, mbenes, joe.lawrence, rostedt, mhiramat,
mark.rutland, mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <20260416133004.07bd2886@pumpkin>
On Thu 2026-04-16 13:30:04, David Laight wrote:
> On Wed, 15 Apr 2026 15:01:37 +0800
> chensong_2000@189.cn wrote:
>
> > From: Song Chen <chensong_2000@189.cn>
> >
> > The current notifier chain implementation uses a single-linked list
> > (struct notifier_block *next), which only supports forward traversal
> > in priority order. This makes it difficult to handle cleanup/teardown
> > scenarios that require notifiers to be called in reverse priority order.
>
> If it is only cleanup/teardown then the list can be order-reversed
> as part of that process at the same time as the list is deleted.
Interesting idea. But it won't work in all situations.
Note that the motivation for this update are the module loader
notifiers which are called several times for each loaded/removed module.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH] mISDN: socket: drop device references acquired by get_mdevice()
From: Shuvam Pandey @ 2026-04-16 14:50 UTC (permalink / raw)
To: Simon Horman; +Cc: netdev, linux-kernel
In-Reply-To: <20260416125029.851168-2-horms@kernel.org>
> Could this introduce a use-after-free regression if the underlying
> hardware is removed before the socket is closed?
>
> [...]
>
> This isn't a regression, but is there a use-after-free in the stack
> teardown when the hardware is removed?
Thanks for the review.
Looking at it more closely, I agree the close-path part of this patch is
not safe as posted.
While get_mdevice() does return a referenced device, the sockets also
keep raw mISDNdevice / mISDNstack pointers across bind, and
mISDN_unregister_device() tears the stack down while those pointers can
still be reached later from socket release. In addition, several mISDN
drivers free the enclosing allocation immediately after
mISDN_unregister_device() returns, so adding put_device() in the socket
release paths can turn this into a close-time UAF. The delete_channel()
/ ch->st case on the data-socket side is the same underlying lifetime
problem.
I'll drop this version and revisit it after reworking the unregister /
socket lifetime handling first. I also want to re-check whether the
temporary get_mdevice() lookup references should be fixed separately or
only once that lifetime side is addressed.
Thanks,
Shuvam
^ permalink raw reply
* Re: [RFC PATCH 2/2] kernel/module: Decouple klp and ftrace from load_module
From: Petr Mladek @ 2026-04-16 14:49 UTC (permalink / raw)
To: Petr Pavlu
Cc: Song Chen, rafael, lenb, mturquette, sboyd, viresh.kumar, agk,
snitzer, mpatocka, bmarzins, song, yukuai, linan122, jason.wessel,
danielt, dianders, horms, davem, edumazet, kuba, pabeni, paulmck,
frederic, mcgrof, da.gomez, samitolvanen, atomlin, jpoimboe,
jikos, mbenes, joe.lawrence, rostedt, mhiramat, mark.rutland,
mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <1db425bf-58a9-4768-8c38-3ae25d7662a5@suse.com>
On Thu 2026-04-16 13:18:30, Petr Pavlu wrote:
> On 4/15/26 8:43 AM, Song Chen wrote:
> > On 4/14/26 22:33, Petr Pavlu wrote:
> >> On 4/13/26 10:07 AM, chensong_2000@189.cn wrote:
> >>> diff --git a/include/linux/module.h b/include/linux/module.h
> >>> index 14f391b186c6..0bdd56f9defd 100644
> >>> --- a/include/linux/module.h
> >>> +++ b/include/linux/module.h
> >>> @@ -308,6 +308,14 @@ enum module_state {
> >>> MODULE_STATE_COMING, /* Full formed, running module_init. */
> >>> MODULE_STATE_GOING, /* Going away. */
> >>> MODULE_STATE_UNFORMED, /* Still setting it up. */
> >>> + MODULE_STATE_FORMED,
> >>
> >> I don't see a reason to add a new module state. Why is it necessary and
> >> how does it fit with the existing states?
> >>
> > because once notifier fails in state MODULE_STATE_UNFORMED (now only ftrace has someting to do in this state), notifier chain will roll back by calling blocking_notifier_call_chain_robust, i'm afraid MODULE_STATE_GOING is going to jeopardise the notifers which don't handle it appropriately, like:
> >
> > case MODULE_STATE_COMING:
> > kmalloc();
> > case MODULE_STATE_GOING:
> > kfree();
>
> My understanding is that the current module "state machine" operates as
> follows. Transitions marked with an asterisk (*) are announced via the
> module notifier.
>
> ---> UNFORMED --*> COMING --*> LIVE --*> GOING -.
> ^ | ^ |
> | '---------------------* |
> '---------------------------------------'
>
> The new code aims to replace the current ftrace_module_init() call in
> load_module(). To achieve this, it adds a notification for the UNFORMED
> state (only when loading a module) and introduces a new FORMED state for
> rollback. FORMED is purely a fake state because it never appears in
> module::state. The new structure is as follows:
>
> ,--*> (FORMED)
> |
> --*> UNFORMED --*> COMING --*> LIVE --*> GOING -.
> ^ | ^ |
> | '---------------------* |
> '---------------------------------------'
>
> I'm afraid this is quite complex and inconsistent. Unless it can be kept
> simple, we would be just replacing one special handling with a different
> complexity, which is not worth it.
> >>
> >>> + if (err)
> >>> + goto ddebug_cleanup;
> >>> /* Finally it's fully formed, ready to start executing. */
> >>> err = complete_formation(mod, info);
> >>> - if (err)
> >>> + if (err) {
> >>> + blocking_notifier_call_chain_reverse(&module_notify_list,
> >>> + MODULE_STATE_FORMED, mod);
> >>> goto ddebug_cleanup;
> >>> + }
> >>> - err = prepare_coming_module(mod);
> >>> + err = prepare_module_state_transaction(mod,
> >>> + MODULE_STATE_COMING, MODULE_STATE_GOING);
> >>> if (err)
> >>> goto bug_cleanup;
> >>> @@ -3522,7 +3519,6 @@ static int load_module(struct load_info *info, const char __user *uargs,
> >>> destroy_params(mod->kp, mod->num_kp);
> >>> blocking_notifier_call_chain(&module_notify_list,
> >>> MODULE_STATE_GOING, mod);
> >>
> >> My understanding is that all notifier chains for MODULE_STATE_GOING
> >> should be reversed.
> > yes, all, from lowest priority notifier to highest.
> > I will resend patch 1 which was failed due to my proxy setting.
>
> What I meant here is that the call:
>
> blocking_notifier_call_chain(&module_notify_list, MODULE_STATE_GOING, mod);
>
> should be replaced with:
>
> blocking_notifier_call_chain_reverse(&module_notify_list, MODULE_STATE_GOING, mod);
>
> >
> >>
> >>> - klp_module_going(mod);
> >>> bug_cleanup:
> >>> mod->state = MODULE_STATE_GOING;
> >>> /* module_bug_cleanup needs module_mutex protection */
> >>
> >> The patch removes the klp_module_going() cleanup call in load_module().
> >> Similarly, the ftrace_release_mod() call under the ddebug_cleanup label
> >> should be removed and appropriately replaced with a cleanup via
> >> a notifier.
> >>
> > err = prepare_module_state_transaction(mod,
> > MODULE_STATE_UNFORMED, MODULE_STATE_FORMED);
> > if (err)
> > goto ddebug_cleanup;
> >
> > ftrace will be cleanup in blocking_notifier_call_chain_robust rolling back.
> >
> > err = prepare_module_state_transaction(mod,
> > MODULE_STATE_COMING, MODULE_STATE_GOING);
> >
> > each notifier including ftrace and klp will be cleanup in blocking_notifier_call_chain_robust rolling back.
> >
> > if all notifiers are successful in MODULE_STATE_COMING, they all will be clean up in
> > coming_cleanup:
> > mod->state = MODULE_STATE_GOING;
> > destroy_params(mod->kp, mod->num_kp);
> > blocking_notifier_call_chain(&module_notify_list,
> > MODULE_STATE_GOING, mod);
> >
> > if something wrong underneath.
>
> My point is that the patch leaves a call to ftrace_release_mod() in
> load_module(), which I expected to be handled via a notifier.
I think that I have got it. The ftrace code needs two notifiers when
the module is being loaded and two when it is going.
This is why Sond added the new state. But I think that we would
need two new states to call:
+ ftrace_module_init() in MODULE_STATE_UNFORMED
+ ftrace_module_enable() in MODULE_STATE_FORMED
and
+ ftrace_free_mem() in MODULE_STATE_PRE_GOING
+ ftrace_free_mem() in MODULE_STATE_GOING
By using the ascii art:
-*> UNFORMED -*> FORMED -> COMING -*> LIVE -*> PRE_GOING -*> GOING -.
| | | ^ ^ ^
| | '----------------' | |
| '--------------------------------------' |
'------------------------------------------------------'
But I think that this is not worth it.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH bpf] bpf: Fix precedence bug in convert_bpf_ld_abs alignment check
From: patchwork-bot+netdevbpf @ 2026-04-16 14:40 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: bpf, netdev, edumazet, willemdebruijn.kernel
In-Reply-To: <20260416122719.661033-1-daniel@iogearbox.net>
Hello:
This patch was applied to bpf/bpf.git (master)
by Alexei Starovoitov <ast@kernel.org>:
On Thu, 16 Apr 2026 14:27:19 +0200 you wrote:
> Fix an operator precedence issue in convert_bpf_ld_abs() where the
> expression offset + ip_align % size evaluates as offset + (ip_align % size)
> due to % having higher precedence than +. That latter evaluation does
> not make any sense. The intended check is (offset + ip_align) % size == 0
> to verify that the packet load offset is properly aligned for direct
> access.
>
> [...]
Here is the summary with links:
- [bpf] bpf: Fix precedence bug in convert_bpf_ld_abs alignment check
https://git.kernel.org/bpf/bpf/c/e5f635edd393
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Andrew Lunn @ 2026-04-16 14:30 UTC (permalink / raw)
To: Fidelio LAWSON
Cc: Marek Vasut, Woojung Huh, UNGLinuxDriver, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Maxime Chevallier, Simon Horman, Heiner Kallweit, Russell King,
netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <bf93f620-1288-46a3-8798-6d70aeb2c7c6@gmail.com>
> With this model, we don’t need to return -EINVAL for combinations or
> ordering, and userspace does not need detailed error reporting. The
> tunables behave more like simple setters than a mode switch, which
> keeps the API predictable and avoids the need for extack or netlink
> ethtool support at this point.
Sounds good.
Andrew
^ permalink raw reply
* Re: [PATCH v1 net 1/1] net/sched: sch_dualpi2: fix limit/memlimit enforcement when dequeueing L-queue
From: Victor Nogueira @ 2026-04-16 14:26 UTC (permalink / raw)
To: chia-yu.chang, linux-hardening, kees, gustavoars, jhs, jiri,
davem, edumazet, kuba, pabeni, linux-kernel, netdev, horms, ij,
ncardwell, koen.de_schepper, g.white, ingemar.s.johansson,
mirja.kuehlewind, cheshire, rs.ietf, Jason_Livingood, vidhi_goel
In-Reply-To: <20260413163711.56191-1-chia-yu.chang@nokia-bell-labs.com>
On 13/04/2026 13:37, chia-yu.chang@nokia-bell-labs.com wrote:
> From: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
>
> Fix dualpi2_change() to correctly enforce updated limit and memlimit values
> after a configuration change of the dualpi2 qdisc.
>
> Before this patch, dualpi2_change() always attempted to dequeue packets via
> the root qdisc (C-queue) when reducing backlog or memory usage, and
> unconditionally assumed that a valid skb will be returned. When traffic
> classification results in packets being queued in the L-queue while the
> C-queue is empty, this leads to a NULL skb dereference during limit or
> memlimit enforcement.
>
> This is fixed by first dequeuing from the C-queue path if it is non-empty.
> Once the C-queue is empty, packets are dequeued directly from the L-queue.s
> Return values from qdisc_dequeue_internal() are checked for both queues. When
> dequeuing from the L-queue, the parent qdisc qlen and backlog counters are
> updated explicitly to keep overall qdisc statistics consistent.
> [...]
> ---
> net/sched/sch_dualpi2.c | 24 +++++++++++++++++++-----
> 1 file changed, 19 insertions(+), 5 deletions(-)
>
> diff --git a/net/sched/sch_dualpi2.c b/net/sched/sch_dualpi2.c
> index 6d7e6389758d..56d4422970b6 100644
> --- a/net/sched/sch_dualpi2.c
> +++ b/net/sched/sch_dualpi2.c
> @@ -872,11 +872,25 @@ static int dualpi2_change(struct Qdisc *sch, struct nlattr *opt,
> old_backlog = sch->qstats.backlog;
> while (qdisc_qlen(sch) > sch->limit ||
> q->memory_used > q->memory_limit) {
> - struct sk_buff *skb = qdisc_dequeue_internal(sch, true);
> -
> - q->memory_used -= skb->truesize;
> - qdisc_qstats_backlog_dec(sch, skb);
> - rtnl_qdisc_drop(skb, sch);
> + int c_len = qdisc_qlen(sch) - qdisc_qlen(q->l_queue);
> + struct sk_buff *skb = NULL;
> +
> + if (c_len) {
> + skb = qdisc_dequeue_internal(sch, true);
> + if (!skb)
> + break;
> + q->memory_used -= skb->truesize;
> + rtnl_qdisc_drop(skb, sch);
> + } else if (qdisc_qlen(q->l_queue)) {
> + skb = qdisc_dequeue_internal(q->l_queue, true);
> + if (!skb)
> + break;
> + q->memory_used -= skb->truesize;
> + rtnl_qdisc_drop(skb, q->l_queue);
> + /* Keep the overall qdisc stats consistent */
> + --sch->q.qlen;
> + qdisc_qstats_backlog_dec(sch, skb);
Sashiko is hallucinating saying this will cause a UAF, it won't.
However it is good to maintain a consistent order here.
For example, see how sch_choke is doing [1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_choke.c?id=1f5ffc672165ff851063a5fd044b727ab2517ae3#n394
cheers,
Victor
^ permalink raw reply
* Re: [PATCH v3 1/3] net: dsa: microchip: implement KSZ87xx Module 3 low-loss cable errata
From: Fidelio LAWSON @ 2026-04-16 14:25 UTC (permalink / raw)
To: Andrew Lunn
Cc: Marek Vasut, Woojung Huh, UNGLinuxDriver, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Maxime Chevallier, Simon Horman, Heiner Kallweit, Russell King,
netdev, linux-kernel, Fidelio Lawson
In-Reply-To: <03040421-89e7-4422-9fb5-0367a34323e4@lunn.ch>
On 4/16/26 14:25, Andrew Lunn wrote:
>> Yes, I think a reasonable compromise could be to expose three tunables:
>>
>> - a boolean "short-cable" tunable, which applies the known good settings
>> (LPF 62 MHz BW, DSP EQ initial value 0).
>>
>> - an integer LPF bandwidth tunable, for advanced use cases where further
>> tuning is needed;
>>
>> - an integer DSP EQ initial value tunable, for the same advanced cases.
>>
>> The boolean tunable would follow the KISS principle and cover the common
>> scenario, while the more granular controls would remain optional.
>
> How do the three interact? Do you need to first enable short-cable
> before you set LPG bandwidth or DSP EQ? If it is not enabled, do you
> get -EINVAL?
>
> It seems like having extack would be useful to return informative
> error messages to user space, however, that requires netlink
> ethtool. And ETHTOOL_PHY_STUNABLE has not been added to netlink
> ethtool yet :-(
>
> Andrew
My intention would be to keep the interactions as simple and
non-surprising as possible, and avoid requiring any particular ordering
or state machine between the tunables.
The boolean short-cable tunable would simply apply the preset
in one step. The LPF bandwidth and DSP EQ initial value tunables would
be orthogonal knobs which can be set independently at any time,
regardless of whether short-cable is enabled or not.
With this model, we don’t need to return -EINVAL for combinations or
ordering, and userspace does not need detailed error reporting. The
tunables behave more like simple setters than a mode switch, which
keeps the API predictable and avoids the need for extack or netlink
ethtool support at this point.
Fidelio
^ permalink raw reply
* Re: [PATCH net v3 4/5] ice: skip unnecessary VF reset when setting trust
From: Simon Horman @ 2026-04-16 13:55 UTC (permalink / raw)
To: jtornosm
Cc: Simon Horman, stable, davem, jesse.brandeburg, edumazet,
przemyslaw.kitszel, netdev, pabeni, intel-wired-lan,
anthony.l.nguyen, kuba
In-Reply-To: <20260414110006.124286-5-jtornosm@redhat.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
ice: skip unnecessary VF reset when setting trust
Similar to the i40e fix, ice_set_vf_trust() unconditionally calls
ice_reset_vf() when the trust setting changes. The ice driver already
has logic to clean up MAC LLDP filters when removing trust, which is
the only operation that requires filter synchronization. After this
cleanup, the VF reset is only necessary if there were actually filters
to remove.
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
> @@ -1399,14 +1399,19 @@ int ice_set_vf_trust(struct net_device *netdev, int vf_id, bool trusted)
>
> mutex_lock(&vf->cfg_lock);
>
> - while (!trusted && vf->num_mac_lldp)
> - ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf), false);
> -
> vf->trusted = trusted;
> - ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
> dev_info(ice_pf_to_dev(pf), "VF %u is now %strusted\n",
> vf_id, trusted ? "" : "un");
>
> + /* Only reset VF if removing trust and there are MAC LLDP filters
> + * to clean up. Reset is needed to ensure filter removal completes.
> + */
> + if (!trusted && vf->num_mac_lldp) {
> + while (vf->num_mac_lldp)
> + ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf), false);
> + ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
> + }
> +
Does setting vf->trusted before the cleanup loop break the filter
removal? Looking at the cleanup mechanism, ice_vf_update_mac_lldp_num()
calls ice_vf_is_lldp_ena() which checks both num_mac_lldp AND
vf->trusted:
ice_vf_lib.h:ice_vf_is_lldp_ena():
return vf->num_mac_lldp && vf->trusted;
With the new ordering where vf->trusted is set to false before the loop:
ice_vf_update_mac_lldp_num() logic:
was_ena = ice_vf_is_lldp_ena(vf); // evaluates to (num > 0 && FALSE) = FALSE
vf->num_mac_lldp--;
is_ena = ice_vf_is_lldp_ena(vf); // evaluates to FALSE
if (was_ena != is_ena) // FALSE != FALSE is FALSE
ice_vsi_cfg_sw_lldp(vsi, false, false); // NEVER called
But in the old code, vf->trusted was still TRUE during the loop:
was_ena = (num > 0 && TRUE) = TRUE
vf->num_mac_lldp--;
is_ena = (0 && TRUE) = FALSE // when last filter removed
if (was_ena != is_ena) // TRUE != FALSE is TRUE
ice_vsi_cfg_sw_lldp(...) // called to remove LLDP filters
So the ETH_P_LLDP packet filters are not removed from the hardware
switch, leaving stale filter rules. Should vf->trusted be set after the
cleanup loop instead?
> mutex_unlock(&vf->cfg_lock);
>
> out_put_vf:
^ permalink raw reply
* Re: [RFC PATCH net-next 0/3] seg6: SRv6 L2 VPN with End.DT2U and srl2 device
From: Ferenc Fejes @ 2026-04-16 13:55 UTC (permalink / raw)
To: justin.iurman@6wind.com, stefano.salsano@uniroma2.it,
andrea.mayer@uniroma2.it
Cc: davem@davemloft.net, dsahern@kernel.org,
paolo.lungaroni@uniroma2.it, ahabdels@cisco.com, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, edumazet@google.com
In-Reply-To: <6fef33af-b351-4bf6-a210-ae2283ec9f69@uniroma2.it>
Hi
...
>
> > I would personally love to have
> > "l2srv6", although I suspect we may end up with "l2seg6" to remain
> > consistent.
>
> I'd like to keep it as short as possible, our initial idea was
> seg6l2,
> very close to your last suggestion, then we opted for srl2 losing the
> "6" concept
>
> now it comes to my mind that l2 is somehow redudant in an interface
> type
> name, as an interface is an l2 concept per se, so my preferred option
> becomes:
>
> sr6
For this type I agree that srl2 and sr6 both makes sense. For the long
run, maybe someone else want to implement [SR-]MPLS pseudowire for L2
in linux (AFAIK only L3 LSR mode supported right now). For such
interface type, srl2 name would make more sense.
Or use "pwl2" or "srpw" which would cover both SR-MPLS and SRv6 case?
If case SR-MPLS PW and SRv6 L2 must be different iface types, I would
use seg6 or sr6 to be consistent with the naming we have in iproute2
right now. Linux/iproute2 use seg6 and seg6local instead of the IETF
names like SRv6 H.End and SRv6 End, so I think its more consistent if
we stick to it.
>
> (short and memorable...)
>
> as an alternative seg6 can work but I strongly prefer sr6
>
> ciao
> Stefano
>
>
> >
> > Cheers,
> > Justin
>
Best,
Ferenc
^ permalink raw reply
* RE: [PATCH v1 net 1/1] net/sched: sch_dualpi2: fix limit/memlimit enforcement when dequeueing L-queue
From: Chia-Yu Chang (Nokia) @ 2026-04-16 13:52 UTC (permalink / raw)
To: Paolo Abeni, linux-hardening@vger.kernel.org, kees@kernel.org,
gustavoars@kernel.org, jhs@mojatatu.com, jiri@resnulli.us,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
horms@kernel.org, ij@kernel.org, ncardwell@google.com,
Koen De Schepper (Nokia), g.white@cablelabs.com,
ingemar.s.johansson@ericsson.com, mirja.kuehlewind@ericsson.com,
cheshire@apple.com, rs.ietf@gmx.at, Jason_Livingood@comcast.com,
vidhi_goel@apple.com
In-Reply-To: <9ff2df3e-08cf-4f61-8a58-cac0a6980b2d@redhat.com>
> -----Original Message-----
> From: Paolo Abeni <pabeni@redhat.com>
> Sent: Thursday, April 16, 2026 3:26 PM
> To: Chia-Yu Chang (Nokia) <chia-yu.chang@nokia-bell-labs.com>; linux-hardening@vger.kernel.org; kees@kernel.org; gustavoars@kernel.org; jhs@mojatatu.com; jiri@resnulli.us; davem@davemloft.net; edumazet@google.com; kuba@kernel.org; linux-kernel@vger.kernel.org; netdev@vger.kernel.org; horms@kernel.org; ij@kernel.org; ncardwell@google.com; Koen De Schepper (Nokia) <koen.de_schepper@nokia-bell-labs.com>; g.white@cablelabs.com; ingemar.s.johansson@ericsson.com; mirja.kuehlewind@ericsson.com; cheshire@apple.com; rs.ietf@gmx.at; Jason_Livingood@comcast.com; vidhi_goel@apple.com
> Subject: Re: [PATCH v1 net 1/1] net/sched: sch_dualpi2: fix limit/memlimit enforcement when dequeueing L-queue
>
>
> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.
>
>
>
> On 4/13/26 6:37 PM, chia-yu.chang@nokia-bell-labs.com wrote:
> > From: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
> >
> > Fix dualpi2_change() to correctly enforce updated limit and memlimit
> > values after a configuration change of the dualpi2 qdisc.
> >
> > Before this patch, dualpi2_change() always attempted to dequeue
> > packets via the root qdisc (C-queue) when reducing backlog or memory
> > usage, and unconditionally assumed that a valid skb will be returned.
> > When traffic classification results in packets being queued in the
> > L-queue while the C-queue is empty, this leads to a NULL skb
> > dereference during limit or memlimit enforcement.
> >
> > This is fixed by first dequeuing from the C-queue path if it is non-empty.
> > Once the C-queue is empty, packets are dequeued directly from the L-queue.
> > Return values from qdisc_dequeue_internal() are checked for both
> > queues. When dequeuing from the L-queue, the parent qdisc qlen and
> > backlog counters are updated explicitly to keep overall qdisc statistics consistent.
> >
> > Fixes: 320d031ad6e4 ("sched: Struct definition and parsing of dualpi2
> > qdisc")
> > Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
> > ---
> > net/sched/sch_dualpi2.c | 24 +++++++++++++++++++-----
> > 1 file changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/net/sched/sch_dualpi2.c b/net/sched/sch_dualpi2.c index
> > 6d7e6389758d..56d4422970b6 100644
> > --- a/net/sched/sch_dualpi2.c
> > +++ b/net/sched/sch_dualpi2.c
> > @@ -872,11 +872,25 @@ static int dualpi2_change(struct Qdisc *sch, struct nlattr *opt,
> > old_backlog = sch->qstats.backlog;
> > while (qdisc_qlen(sch) > sch->limit ||
> > q->memory_used > q->memory_limit) {
> > - struct sk_buff *skb = qdisc_dequeue_internal(sch, true);
> > -
> > - q->memory_used -= skb->truesize;
> > - qdisc_qstats_backlog_dec(sch, skb);
> > - rtnl_qdisc_drop(skb, sch);
> > + int c_len = qdisc_qlen(sch) - qdisc_qlen(q->l_queue);
> > + struct sk_buff *skb = NULL;
> > +
> > + if (c_len) {
> > + skb = qdisc_dequeue_internal(sch, true);
> > + if (!skb)
> > + break;
> > + q->memory_used -= skb->truesize;
> > + rtnl_qdisc_drop(skb, sch);
> > + } else if (qdisc_qlen(q->l_queue)) {
> > + skb = qdisc_dequeue_internal(q->l_queue, true);
> > + if (!skb)
> > + break;
> > + q->memory_used -= skb->truesize;
> > + rtnl_qdisc_drop(skb, q->l_queue);
> > + /* Keep the overall qdisc stats consistent */
> > + --sch->q.qlen;
> > + qdisc_qstats_backlog_dec(sch, skb);
>
> Sashiko says:
> ---
> The drop counter is incremented for the L-queue via rtnl_qdisc_drop(), but it appears the drop counter for the parent qdisc (sch) is not updated.
> Will this cause user-facing statistics for the overall dualpi2 qdisc to underreport drops?
> ---
Hi Paolo,
You are right, this is my miss.
I will add "qdisc_qstats_drop(sch)" for the L-queue dropping case.
Thanks!
Chia-Yu
^ permalink raw reply
* Re: [PATCH net-next 5/6] net: stmmac: move PHY handling out of __stmmac_open()/release()
From: Russell King (Oracle) @ 2026-04-16 13:47 UTC (permalink / raw)
To: Alexander Stein
Cc: Andrew Lunn, Heiner Kallweit, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-stm32, Maxime Coquelin, netdev, Paolo Abeni
In-Reply-To: <aeDSTIS9-TDSihbX@shell.armlinux.org.uk>
On Thu, Apr 16, 2026 at 01:13:00PM +0100, Russell King (Oracle) wrote:
> On Thu, Apr 16, 2026 at 02:02:53PM +0200, Alexander Stein wrote:
> > Hi Russel,
> >
> > Am Donnerstag, 16. April 2026, 12:49:25 CEST schrieb Russell King (Oracle):
> > > On Thu, Apr 16, 2026 at 08:20:13AM +0200, Alexander Stein wrote:
> > > > Am Mittwoch, 15. April 2026, 14:59:32 CEST schrieb Russell King (Oracle):
> > > > > On Wed, Apr 15, 2026 at 08:08:40AM +0200, Alexander Stein wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Am Dienstag, 23. September 2025, 13:26:19 CEST schrieb Russell King (Oracle):
> > > > > > > Move the PHY attachment/detachment from the network driver out of
> > > > > > > __stmmac_open() and __stmmac_release() into stmmac_open() and
> > > > > > > stmmac_release() where these actions will only happen when the
> > > > > > > interface is administratively brought up or down. It does not make
> > > > > > > sense to detach and re-attach the PHY during a change of MTU.
> > > > > >
> > > > > > Sorry for coming up now. But I recently noticed this commit breaks changing
> > > > > > the MTU on i.MX8MP. Once I simply change the MTU I run into some DMA error:
> > > > > > $ ip link set dev end1 mtu 1400
> > > > > > imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-0
> > > > > > imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-1
> > > > > > imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-2
> > > > > > imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-3
> > > > > > imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-4
> > > > > > imx-dwmac 30bf0000.ethernet end1: Link is Down
> > > > > > imx-dwmac 30bf0000.ethernet end1: Failed to reset the dma
> > > > > > imx-dwmac 30bf0000.ethernet end1: stmmac_hw_setup: DMA engine initialization failed
> > > > >
> > > > > This basically means that a clock is missing. Please provide more
> > > > > information:
> > > > >
> > > > > - what kernel version are you using?
> > > >
> > > > Currently I am using v6.18.22.
> > > > $ ethtool -i end1
> > > > driver: st_gmac
> > > > version: 6.18.22
> > > > firmware-version:
> > > > expansion-rom-version:
> > > > bus-info: 30bf0000.ethernet
> > > > supports-statistics: yes
> > > > supports-test: no
> > > > supports-eeprom-access: no
> > > > supports-register-dump: yes
> > > > supports-priv-flags: no
> > > >
> > > > > - has EEE been negotiated?
> > > >
> > > > No. It is marked as not supported
> > > >
> > > > $ ethtool --show-eee end1
> > > > EEE settings for end1:
> > > > EEE status: not supported
> > > >
> > > > > - does the problem persist when EEE is disabled?
> > > >
> > > > As EEE is not supported the problem occurs even with EEE disabled.
> > > >
> > > > > - which PHY is attached to stmmac?
> > > >
> > > > It is a TI DP83867.
> > > >
> > > > imx-dwmac 30bf0000.ethernet eth1: PHY [stmmac-1:03] driver [TI DP83867] (irq=136)
> > > >
> > > > > - which PHY interface mode is being used to connect the PHY to stmmac?
> > > >
> > > > For this interface
> > > > > phy-mode = "rgmii-id";
> > > > is set.
> > > >
> > > > In case it is helpful. My platform is arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
> > > > Thanks for assisting. If there a further questions, don't hesitate to ask.
> > >
> > > Thanks.
> > >
> > > So, as best I can determine at the moment, we end up with the following
> > > sequence:
> > >
> > > stmmac_change_mtu()
> > > __stmmac_release()
> > > phylink_stop()
> > > phy_stop()
> > > phy->state = PHY_HALTED
> > > _phy_state_machine() returns PHY_STATE_WORK_SUSPEND
> > > _phy_state_machine_post_work()
> > > phy_suspend()
> > > genphy_suspend()
> > > phy_set_bits(phydev, MII_BMCR, BMCR_PDOWN)
> > >
> > > With the DP83867, this causes most of the PHY to be powered down, thus
> > > stopping the clocks, and this causes the stmmac reset to time out.
> > >
> > > Prior to this commit, we would have called phylink_disconnect_phy()
> > > immediately after phylink_stop(), but I can see nothing that would
> > > be affected by this change there (since that also calls
> > > phy_suspend(), but as the PHY is already suspended, this becomes a
> > > no-op.)
> > >
> > > However, __stmmac_open() would have called stmmac_init_phy(), which
> > > would reattach the PHY. This would have called phy_init_hw(),
> > > resetting the PHY, and phy_resume() which would ensure that the
> > > PDOWN bit is clear - thus clocks would be running.
> > >
> > > As a hack, please can you try calling phylink_prepare_resume()
> > > between the __stmmac_release() and __stmmac_open() in
> > > stmmac_change_mtu(). This should resume the PHY, thus restoring the
> > > clocks necessary for stmmac to reset.
> >
> > I tried the following patch. This works as you suspected.
>
> Brilliant, thanks for proving the theory why it broke.
>
> I'll have a think about the best way to solve this, because
> phylink_prepare_resume() is supposed to be paired with phylink_resume()
> and that isn't the case here.
>
> Please bear with me as my availability for looking at the kernel is
> very unpredictable at present (family health issues.)
I have some patches which passed build testing, but more chaos means
I can't post them nor test them. I'll do something when I'm next able
to, whenever that will be.
The next problem will be netdev's policy over reviews vs patches
balance which I'm already in deficit, and I have *NO* *TIME*
what so ever to review patches - let alone propose patches to
fix people's problems.
So I'm going to say this plainly: if netdev wants to enforce that
rule, then I won't be fixing people's problems.
--
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 net] selftests: net: add missing CMAC to tcp_ao config
From: Matthieu Baerts @ 2026-04-16 13:47 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, shuah, fw,
antonio, phil, linux-kselftest
In-Reply-To: <20260416010439.1053587-1-kuba@kernel.org>
Hi Jakub,
On 16/04/2026 03:04, Jakub Kicinski wrote:
> Recent changes to crypto and wifi made CMAC no longer
> selected by default on x86 and tcp_ao needs it.
> Add the missing config.
Thank you for the fix, I see that CMAC is the default algo used in the
TCP AO selftests, and this modification fixes the recent issue.
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* Re: [PATCH net] sctp: fix OOB write to userspace in sctp_getsockopt_peer_auth_chunks
From: Xin Long @ 2026-04-16 13:46 UTC (permalink / raw)
To: Michael Bommarito
Cc: linux-sctp, Marcelo Ricardo Leitner, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman, netdev,
linux-kernel, stable
In-Reply-To: <20260416031903.1447072-1-michael.bommarito@gmail.com>
On Wed, Apr 15, 2026 at 11:19 PM Michael Bommarito
<michael.bommarito@gmail.com> wrote:
>
> sctp_getsockopt_peer_auth_chunks() checks that the caller's optval
> buffer is large enough for the peer AUTH chunk list with
>
> if (len < num_chunks)
> return -EINVAL;
>
> but then writes num_chunks bytes to p->gauth_chunks, which lives
> at offset offsetof(struct sctp_authchunks, gauth_chunks) == 8
> inside optval. The check is missing the sizeof(struct
> sctp_authchunks) = 8-byte header. When the caller supplies
> len == num_chunks (for any num_chunks > 0) the test passes but
> copy_to_user() writes sizeof(struct sctp_authchunks) = 8 bytes
> past the declared buffer.
>
> The sibling function sctp_getsockopt_local_auth_chunks() at the
> next line already has the correct check:
>
> if (len < sizeof(struct sctp_authchunks) + num_chunks)
> return -EINVAL;
>
> Align the peer variant with its sibling.
>
> Reproducer confirms on v7.0-13-generic: an unprivileged userspace
> caller that opens a loopback SCTP association with AUTH enabled,
> queries num_chunks with a short optval, then issues the real
> getsockopt with len == num_chunks and sentinel bytes painted past
> the buffer observes those sentinel bytes overwritten with the
> peer's AUTH chunk type. The bytes written are under the peer's
> control but land in the caller's own userspace; this is not a
> kernel memory corruption, but it is a kernel-side contract
> violation that can silently corrupt adjacent userspace data.
>
> Fixes: 65b07e5d0d09 ("[SCTP]: API updates to suport SCTP-AUTH extensions.")
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-6
> Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
> ---
> net/sctp/socket.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 05fb00c9c335..f5d442753dc9 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -7033,7 +7033,7 @@ static int sctp_getsockopt_peer_auth_chunks(struct sock *sk, int len,
>
> /* See if the user provided enough room for all the data */
> num_chunks = ntohs(ch->param_hdr.length) - sizeof(struct sctp_paramhdr);
> - if (len < num_chunks)
> + if (len < sizeof(struct sctp_authchunks) + num_chunks)
> return -EINVAL;
>
> if (copy_to_user(to, ch->chunks, num_chunks))
> --
> 2.53.0
>
Acked-by: Xin Long <lucien.xin@gmail.com>
^ permalink raw reply
* Re: [patch 35/38] s390: Select ARCH_HAS_RANDOM_ENTROPY
From: Heiko Carstens @ 2026-04-16 13:42 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, linux-s390, Arnd Bergmann, x86, Lu Baolu, iommu,
Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka, linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.924028412@kernel.org>
On Fri, Apr 10, 2026 at 02:21:19PM +0200, Thomas Gleixner wrote:
> The only remaining non-architecture usage of get_cycles() is to provide
> random_get_entropy().
>
> Switch s390 over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY and
> providing random_get_entropy() in asm/random.h.
>
> Add 'asm/timex.h' includes to the relevant files, so the global include can
> be removed once all architectures are converted over.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Heiko Carstens <hca@linux.ibm.com>
> Cc: linux-s390@vger.kernel.org
> ---
> arch/s390/Kconfig | 1 +
> arch/s390/include/asm/random.h | 12 ++++++++++++
> arch/s390/include/asm/timex.h | 6 ------
> arch/s390/kernel/time.c | 1 +
> arch/s390/kernel/vtime.c | 1 +
> 5 files changed, 15 insertions(+), 6 deletions(-)
Acked-by: Heiko Carstens <hca@linux.ibm.com>
Thomas, would you mind adding the below as minor improvement to this
series?
From 7072e5d66b99a7fa666d17c6ad8cb254f2d8f473 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <hca@linux.ibm.com>
Date: Thu, 16 Apr 2026 15:08:15 +0200
Subject: [PATCH] s390: Use get_tod_clock_fast() for random_get_entropy()
Use get_tod_clock_fast() instead of get_tod_clock_monotonic() to implement
random_get_entropy().
There is no need for random_get_entropy() to provide monotonic increasing
values, nor is there any need to provide (close to) nanosecond granularity
timestamps by shifting the result.
This slightly reduces the execution time of random_get_entropy() and adds
two bits of randomness.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
---
arch/s390/include/asm/random.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/s390/include/asm/random.h b/arch/s390/include/asm/random.h
index 7daf42dbed32..f6d9312efdbf 100644
--- a/arch/s390/include/asm/random.h
+++ b/arch/s390/include/asm/random.h
@@ -6,7 +6,7 @@
static inline unsigned long random_get_entropy(void)
{
- return (unsigned long)get_tod_clock_monotonic() >> 2;
+ return get_tod_clock_fast();
}
#endif
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net 00/14] Netfilter/IPVS fixes for net
From: Fernando Fernandez Mancera @ 2026-04-16 13:37 UTC (permalink / raw)
To: Florian Westphal
Cc: Pablo Neira Ayuso, netfilter-devel, davem, netdev, kuba, pabeni,
edumazet, horms
In-Reply-To: <aeDgvwlyuGF4HnWK@strlen.de>
On 4/16/26 3:14 PM, Florian Westphal wrote:
> Fernando Fernandez Mancera <fmancera@suse.de> wrote:
>> I would like to propose to add netfilter-devel mailing list to
>> sashiko.dev and also to Netdev CI.. I think Jakub mentioned it was
>> possible on a previous situation.
>
> I already run all my pull requests through most of NIPAs test, with
> additional netfilter-specific tests.
>
>> I think it isn't sustainable to review and address the AI/LLM comments
>> when sending the pull request to for net/net-next.
>
> The current bug report influx is already unsustainable for us.
>
Yes, it isn't. It should be fine to just delay everything. The resources
are limited and if the influx of LLM/AI generated reports increases, it
will just take more time to get through them.
>> If you agree I could help moving this forward.
>
> If you know who to contact to make sashiko also digest netfilter-devel
> that would be good to have.
>
Yes, I can reach out to Roman Gushchin regarding it.
Thanks,
Fernando.
^ permalink raw reply
* Re: [PATCH net 1/1] 8021q: free cleared egress QoS mappings safely
From: Simon Horman @ 2026-04-16 13:34 UTC (permalink / raw)
To: Yuan Tan
Cc: Ren Wei, netdev, andrew+netdev, davem, edumazet, kuba, pabeni,
kees, yifanwucs, tomapufckgml, bird, ylong030
In-Reply-To: <d22967f1-789d-4f53-baa8-492f64fc725a@gmail.com>
On Wed, Apr 15, 2026 at 10:35:19PM -0700, Yuan Tan wrote:
>
> On 4/15/26 08:15, Simon Horman wrote:
> > On Mon, Apr 13, 2026 at 05:07:20PM +0800, Ren Wei wrote:
> >> From: Longxuan Yu <ylong030@ucr.edu>
> >>
> >> vlan_dev_set_egress_priority() leaves cleared egress priority mapping
> >> nodes in the hash until device teardown. Repeated set/clear cycles with
> >> distinct skb priorities therefore allocate an unbounded number of
> >> vlan_priority_tci_mapping objects and leak memory.
> >>
> >> Delete mappings when vlan_prio is cleared instead of keeping
> >> tombstones. The TX fast path and reporting paths walk the lists without
> >> RTNL, so convert the egress mapping lists to RCU-protected pointers and
> >> defer freeing removed nodes until after a grace period.
> >>
> >> Cc: stable@kernel.org
> >> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> >> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> >> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> >> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> >> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> >> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> >> Signed-off-by: Longxuan Yu <ylong030@ucr.edu>
> >> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
> >> ---
> >> include/linux/if_vlan.h | 23 +++++++++++--------
> >> net/8021q/vlan_dev.c | 48 +++++++++++++++++++++++-----------------
> >> net/8021q/vlan_netlink.c | 9 +++-----
> >> net/8021q/vlanproc.c | 12 ++++++----
> >> 4 files changed, 53 insertions(+), 39 deletions(-)
> > There is a lot of change here. And I'd suggest splitting the patch up into
> > (at least) two patches:
> >
> > 1. Convert mappings to use RCU
> > 2. Fix bug
> >
> > As is, the bug fix itself is difficult to isolate amongst the other changes.
> >
> > Also, AI generated review suggests that this bug was introduced by commit
> > b020cb488586 ("[VLAN]: Keep track of number of QoS mappings"). If so,
> > it would be appropriate to use that commit in the Fixes tag.
> >
> Thank you very much for your review and suggestions. We will try to
> revise it in this direction.
> May I ask whether we should include your “Suggested-by” tag in the patch?
I don't think you should include a Suggested-by tag.
My reasoning is that I'm only providing feedback and possible enhancements
to your approach. While I think Suggested-by would be appropriate if I'd
suggested creating this patch in the first place.
^ permalink raw reply
* Re: [PATCH net v2] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Simon Horman @ 2026-04-16 13:29 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <ad_DrrC6duye_lR0@lore-desk>
On Wed, Apr 15, 2026 at 06:58:22PM +0200, Lorenzo Bianconi wrote:
> On Apr 15, Simon Horman wrote:
> > On Tue, Apr 14, 2026 at 08:50:52AM +0200, Lorenzo Bianconi wrote:
> > > Similar to airoha_qdma_cleanup_rx_queue(), reset DMA TX descriptors in
> > > airoha_qdma_cleanup_tx_queue routine. Moreover, reset TX_DMA_IDX to
> > > TX_CPU_IDX to notify the NIC the QDMA TX ring is empty.
> > >
> > > Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> > > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > > ---
> > > Changes in v2:
> > > - Move q->ndesc initialization at end of airoha_qdma_init_tx routine in
> > > order to avoid any possible NULL pointer dereference in
> > > airoha_qdma_cleanup_tx_queue()
> >
> > This seems to be a separate issue.
> > If so, I think it should be split out into a separate patch.
> >
> > > - Check if q->tx_list is empty in airoha_qdma_cleanup_tx_queue()
> > > - Link to v1: https://lore.kernel.org/r/20260410-airoha_qdma_cleanup_tx_queue-fix-net-v1-1-b7171c8f1e78@kernel.org
> >
> > I think it was covered in the review Jakub forwarded for v1. But FTR,
> > Sashiko has some feedback on this patch in the form of an existing bug
> > (that should almost certainly be handled separately from this patch).
>
> Hi Simon,
>
> I took a look to the Sashiko's report [0] but this issue is not introduced by
> this patch and, even if it would be a better approach, I guess the hw is
> capable of managing out-of-order TX descriptors. So I guess this patch is fine
> in this way, agree?
>
> [0] https://sashiko.dev/#/patchset/20260414-airoha_qdma_cleanup_tx_queue-fix-net-v2-1-875de57cc022%40kernel.org
Hi Lorenzo,
You responded in a different sub thread, so I think this is probably
implied. But FTR:
1. I agree [0] is not introduced by this patch
2. If the hw is capable of managing TX descriptors then
I think that [0] is a false positive
Regardless, [0] doesn't effect this patch.
^ 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