* Re: [PATCH 10/23] cpu: Use RCU to protect access of HK_TYPE_TIMER cpumask
From: Thomas Gleixner @ 2026-04-21 8:57 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-11-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_TIMER cpumask is going to be changeable at run time, use
> RCU to protect access to the cpumask.
>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> kernel/cpu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index bc4f7a9ba64e..0d02b5d7a7ba 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -1890,6 +1890,8 @@ int freeze_secondary_cpus(int primary)
> cpu_maps_update_begin();
> if (primary == -1) {
> primary = cpumask_first(cpu_online_mask);
> +
> + guard(rcu)();
> if (!housekeeping_cpu(primary, HK_TYPE_TIMER))
> primary = housekeeping_any_cpu(HK_TYPE_TIMER);
housekeeping_cpu() and housekeeping_any_cpu() can operate on two
different CPU masks once the runtime update is enabled.
Seriously?
^ permalink raw reply
* Re: [PATCH 11/23] hrtimer: Use RCU to protect access of HK_TYPE_TIMER cpumask
From: Thomas Gleixner @ 2026-04-21 8:59 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-12-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_TIMER cpumask is going to be changeable at run time, use
As the ...
> RCU to protect access to the cpumask.
>
> The access of HK_TYPE_TIMER cpumask within hrtimers_cpu_dying() is
> protected as interrupt is disabled and all the other CPUs are stopped
interrupts are disabled
> when this function is invoked as part of the CPU tear down process.
^ permalink raw reply
* [PATCH 0/2] mfd: rsmu_spi: fixes and new IC support
From: Matthew Bystrin @ 2026-04-21 9:07 UTC (permalink / raw)
To: Lee Jones, Richard Cochran, Min Li; +Cc: linux-kernel, netdev
Greetings!
First patch fixes Renesas 8A34002 SPI driver.
In my setup 8A34002 is connected to VisionFive2 via SPI. I've discovered that
upstream driver does not work:
[ 4.728771] 8a3400x-phc 8a3400x-phc.0.auto: 4.8.7, Id: 0x4002 HW Rev: 5 OTP Config Select: 0
[ 4.737389] 8a3400x-phc 8a3400x-phc.0.auto: requesting firmware 'idtcm.bin'
[ 4.744462] 8a3400x-phc 8a3400x-phc.0.auto: Direct firmware load for idtcm.bin failed with error -2
[ 4.753547] 8a3400x-phc 8a3400x-phc.0.auto: Failed at line 1273 in idtcm_load_firmware!
[ 4.761576] 8a3400x-phc 8a3400x-phc.0.auto: loading firmware failed with -2
[ 4.769411] 8a3400x-phc 8a3400x-phc.0.auto: No wait state: DPLL_SYS_STATE 0
[ 4.776374] 8a3400x-phc 8a3400x-phc.0.auto: Continuing while SYS APLL/DPLL is not locked
[ 4.785206] 8a3400x-phc 8a3400x-phc.0.auto: Unsupported MANUAL_REFERENCE: 0x00
[ 4.796930] 8a3400x-phc 8a3400x-phc.0.auto: PLL2 registered as ptp0
This being caused by a piece of code in rsmu_write_page_register() function:
if (reg < RSMU_CM_SCSR_BASE)
return 0;
All addresses in include/linux/mfd/idt8a340_reg.h are less than
RSMU_CM_SCSR_BASE so function was returning early, before any modifications to
the page register. Valid read of versions - is just a coincidence, because
default value of the page register is zero.
There were 2 separate patch series which have to be merged in one time: mfd and
ptp. The latter have been merged, the former[1] have not. As result we've got a
broken driver.
This patch can be reverted later when the second part will be ready (of course
if it is planned to do so). Any comments, Min? I could support with testing.
Also I've had a quick look into I2C part. It may also require the same kind of
fixes to work properly. But I didn't tested it. I could do some experiments and
return with patches later.
Second patch just adds support for 8A34002, which is compatible with 8A34001. As
I can see there is no need to update bindings, everything is already being done.
Link: https://lore.kernel.org/netdev/LV3P220MB1202F8E2FCCFBA2519B4966EA0192@LV3P220MB1202.NAMP220.PROD.OUTLOOK.COM/
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
Matthew Bystrin (2):
mfd: rsmu_spi: fix page register setup
mfd: rsmu_spi: add 8a34002 support
drivers/mfd/rsmu_spi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH 1/2] mfd: rsmu_spi: fix page register setup
From: Matthew Bystrin @ 2026-04-21 9:07 UTC (permalink / raw)
To: Lee Jones, Richard Cochran, Min Li; +Cc: linux-kernel, netdev
In-Reply-To: <20260421090710.395591-1-dev.mbstr@gmail.com>
Fix writes to page register in 8A3400x family (Clock Matrix).
All calls to rsmu_write_page_register() have resulted in early return,
becase all addresses in include/linux/mfd/idt8a340_reg.h are less than
RSMU_CM_SCSR_BASE.
There were 2 separate patch series which have to be merged in one time:
mfd and ptp. The latter have been merged, the former[1] have not.
Link: https://lore.kernel.org/netdev/LV3P220MB1202F8E2FCCFBA2519B4966EA0192@LV3P220MB1202.NAMP220.PROD.OUTLOOK.COM/
Fixes: 67d6c76fc815 ("mfd: rsmu: Support 32-bit address space")
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
---
drivers/mfd/rsmu_spi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mfd/rsmu_spi.c b/drivers/mfd/rsmu_spi.c
index 39d9be1e141f..55c5698e7e77 100644
--- a/drivers/mfd/rsmu_spi.c
+++ b/drivers/mfd/rsmu_spi.c
@@ -101,11 +101,9 @@ static int rsmu_write_page_register(struct rsmu_ddata *rsmu, u32 reg)
switch (rsmu->type) {
case RSMU_CM:
- /* Do not modify page register for none-scsr registers */
- if (reg < RSMU_CM_SCSR_BASE)
- return 0;
page_reg = RSMU_CM_PAGE_ADDR;
page = reg & RSMU_PAGE_MASK;
+ page |= RSMU_CM_SCSR_BASE;
buf[0] = (u8)(page & 0xFF);
buf[1] = (u8)((page >> 8) & 0xFF);
buf[2] = (u8)((page >> 16) & 0xFF);
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] mfd: rsmu_spi: add 8a34002 support
From: Matthew Bystrin @ 2026-04-21 9:07 UTC (permalink / raw)
To: Lee Jones, Richard Cochran, Min Li; +Cc: linux-kernel, netdev
In-Reply-To: <20260421090710.395591-1-dev.mbstr@gmail.com>
Add separate compatible string and spi_devcie_id to support 8a34002.
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
---
drivers/mfd/rsmu_spi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/rsmu_spi.c b/drivers/mfd/rsmu_spi.c
index 55c5698e7e77..2d4ad9606aec 100644
--- a/drivers/mfd/rsmu_spi.c
+++ b/drivers/mfd/rsmu_spi.c
@@ -242,6 +242,7 @@ static void rsmu_spi_remove(struct spi_device *client)
static const struct spi_device_id rsmu_spi_id[] = {
{ "8a34000", RSMU_CM },
{ "8a34001", RSMU_CM },
+ { "8a34002", RSMU_CM },
{ "82p33810", RSMU_SABRE },
{ "82p33811", RSMU_SABRE },
{}
@@ -251,6 +252,7 @@ MODULE_DEVICE_TABLE(spi, rsmu_spi_id);
static const struct of_device_id rsmu_spi_of_match[] = {
{ .compatible = "idt,8a34000", .data = (void *)RSMU_CM },
{ .compatible = "idt,8a34001", .data = (void *)RSMU_CM },
+ { .compatible = "idt,8a34002", .data = (void *)RSMU_CM },
{ .compatible = "idt,82p33810", .data = (void *)RSMU_SABRE },
{ .compatible = "idt,82p33811", .data = (void *)RSMU_SABRE },
{}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 16/23] genirq/cpuhotplug: Use RCU to protect access of HK_TYPE_MANAGED_IRQ cpumask
From: Thomas Gleixner @ 2026-04-21 9:02 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-17-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_MANAGED_IRQ cpumask is going to be changeable at run time,
> use RCU to protect access to the cpumask.
>
> To enable the new HK_TYPE_MANAGED_IRQ cpumask to take effect, the
> following steps can be done.
Can be done?
> 1) Update the HK_TYPE_MANAGED_IRQ cpumask to take out the newly isolated
> CPUs and add back the de-isolated CPUs.
> 2) Tear down the affected CPUs to cause irq_migrate_all_off_this_cpu()
> to be called on the affected CPUs to migrate the irqs to other
> HK_TYPE_MANAGED_IRQ housekeeping CPUs.
> 3) Bring up the previously offline CPUs to invoke
> irq_affinity_online_cpu() to allow the newly de-isolated CPUs to
> be used for managed irqs.
Which previously offline CPUs?
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 2e8072437826..8270c4de260b 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -263,6 +263,7 @@ int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask, bool
> housekeeping_enabled(HK_TYPE_MANAGED_IRQ)) {
> const struct cpumask *hk_mask;
>
> + guard(rcu)();
> hk_mask = housekeeping_cpumask(HK_TYPE_MANAGED_IRQ);
>
> cpumask_and(tmp_mask, mask, hk_mask);
How is this hunk related to $Subject?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH iwl-net v2 0/4] iavf: fix VLAN filter state machine races
From: Simon Horman @ 2026-04-21 9:02 UTC (permalink / raw)
To: Petr Oros
Cc: netdev, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jesse Brandeburg, Mitch Williams, Aaron Brown,
Przemyslaw Patynowski, Jedrzej Jagielski, intel-wired-lan,
linux-kernel, jacob.e.keller
In-Reply-To: <cover.1776426683.git.poros@redhat.com>
On Fri, Apr 17, 2026 at 04:29:41PM +0200, Petr Oros wrote:
> The iavf VLAN filter state machine has several design issues that lead
> to race conditions between userspace add/del calls and the watchdog
> task's virtchnl processing. Filters can get lost or leak HW resources,
> especially during interface down/up cycles and namespace moves.
...
Hi Petr,
Sashiko has a bit to say about this patch.
I'd appreciate it if you could look over that.
In particular, the feedback on patches 2 and 3 may warrant
some updates to this patchset, while I think 4 is more
in the realm of possible future work.
^ 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-21 9:05 UTC (permalink / raw)
To: Masami Hiramatsu
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, 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: <20260420144429.57b45f2beece690bceea96ec@kernel.org>
On Mon 2026-04-20 14:44:29, Masami Hiramatsu wrote:
> Hi Song,
>
> 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.
>
> What about introducing a new notification callback API that allows you
> to describe dependencies between callback functions?
>
> For example, when registering a callback, you could register a string
> as an ID and specify whether to call it before or after that ID,
> or you could register a comparison function that is called when adding
> to a list. (I prefer @name and @depends fields so that it can be easily
> maintained.)
This looks too complex. It would make sense only
when this API has more users.
Also this won't be enough for the ftrace/livepatch callbacks.
They need to be ordered against against each other. But they
also need to be called before/after all other callbacks.
For example, when the module is loaded:
+ 1st frace
+ 2nd livepatch
+ then other notifiers
See the commit c1bf08ac26e92122 ("ftrace: Be first to run code
modification on modules").
> This would allow for better dependency building when adding to the list.
> >
> > A concrete example is the ordering dependency between ftrace and
> > livepatch during module load/unload. see the detail here [1].
>
> If this only concerns notification callback issues with the ftrace
> and livepatch modules, it's far more robust to simply call the
> necessary processing directly when the modules load and unload,
> rather than registering notification callbacks externally.
>
> There are fprobe, kprobe and its trace-events, all of them are using
> ftrace as its fundation layer. In this case, I always needs to
> consider callback order when a module is unloaded.
>
> If ftrace is working as a part of module callbacks, it will conflict
> with fprobe/kprobe module callback. Of course we can reorder it with
> modifying its priority. But this is ugly, because when we introduce
> a new other feature which depends on another layer, we need to
> reorder the callback's priority number on the list.
>
> Based on the above, I don't think this can be resolved simply by
> changing the list of notification callbacks to a bidirectional list.
I agree. I would keep it as is (hardcoded).
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH net v3 1/1] net: l3mdev: Reject non-L3 uppers in slave helpers
From: Ido Schimmel @ 2026-04-21 9:10 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, idosch, dsahern, davem, edumazet, kuba, pabeni, horms,
jiri, yifanwucs, tomapufckgml, yuantan098, bird, royenheart
In-Reply-To: <20260420182640.GA1027405@shredder>
On Mon, Apr 20, 2026 at 09:26:50PM +0300, Ido Schimmel wrote:
> On Mon, Apr 20, 2026 at 02:32:08PM +0300, Ido Schimmel wrote:
> > On Sun, Apr 19, 2026 at 10:53:32PM +0800, Ren Wei wrote:
> > > From: Haoze Xie <royenheart@gmail.com>
> > >
> > > Several l3mdev slave-side helpers resolve an upper device and then use
> > > l3mdev_ops without first proving that the resolved device is still a
> > > valid L3 master.
> > >
> > > During slave transition, an RCU reader can transiently observe an upper
> > > that is not an L3 master. Guard the affected slave-resolved paths by
> > > requiring the resolved upper to still be an L3 master before using
> > > l3mdev_ops, while keeping existing L3 RX handler providers intact.
> > >
> > > Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking")
> > > Cc: stable@kernel.org
> > > 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>
> > > Tested-by: Haoze Xie <royenheart@gmail.com>
> > > Signed-off-by: Haoze Xie <royenheart@gmail.com>
> > > Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
> >
> > I think it's fine for net:
> >
> > Reviewed-by: Ido Schimmel <idosch@nvidia.com>
>
> Thought about this again. I would like to check another approach
> (synchronize_net() after clearing IFF_L3MDEV_SLAVE). Will update
> tomorrow.
Sorry about the back and forth, but I thought about it again last night
and I think that this is a better fix:
https://github.com/idosch/linux/commit/e67517758ebcddf8a1b97817e4ab0fbf82f467fe.patch
It's a minimal fix in the control plane of the VRF driver which doesn't
add more checks in the data path. I can submit it later this week unless
there are objections.
^ permalink raw reply
* Re: [PATCH net] netdevsim: Initialize all fields of ip header when building dummy sk_buff
From: Breno Leitao @ 2026-04-21 9:12 UTC (permalink / raw)
To: Nikola Z. Ivanov
Cc: kuba, andrew+netdev, davem, edumazet, pabeni, netdev,
linux-kernel
In-Reply-To: <9ce273bd-6912-4442-8672-4c89bebf32ed@gmail.com>
On Tue, Apr 21, 2026 at 11:54:19AM +0300, Nikola Z. Ivanov wrote:
> On 4/21/26 11:19 AM, Breno Leitao wrote:
> > On Tue, Apr 21, 2026 at 10:37:38AM +0300, Nikola Z. Ivanov wrote:
> > >
> > > Closes: https://syzkaller.appspot.com/bug?extid=23d7fcd204e3837866ff
> >
> > How do you check in the report above that the missig un-initialized
> > fields are "tos" and "id"?
>
> I don't think it is visible here, my guess would
> be because the checksum calculator walks the
> header in small chunks instead of referencing
> its fields.
>
> The whole "KMSAN: uninit-value in irqentry_exit_to_kernel_mode_preempt"
> doesn't really sound quite right.
That's precisely my question - how does this fix relate to that specific
report?
Were you able to reproduce the KMSAN report?
Thanks for the quick answer,
--breno
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove unused ATM protocols and legacy ATM device drivers
From: David Woodhouse @ 2026-04-21 9:26 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3, razor,
idosch, jani.nikula, mchehab+huawei, tytso, herbert, geert,
ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
fourier.thomas, andriy.shevchenko, rdunlap, akpm, linux-doc,
linux-mips, linuxppc-dev, bridge
In-Reply-To: <20260421021943.1295109-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]
On Mon, 2026-04-20 at 19:19 -0700, Jakub Kicinski wrote:
> Remove the ATM protocol modules and PCI/SBUS ATM device drivers
> that are no longer in active use.
>
> The ATM core protocol stack, PPPoATM, and USB DSL modem drivers
> (drivers/usb/atm/) are retained in-tree to maintain PPP over ATM
> (PPPoA) support for DSL connections.
>
> Removed ATM protocol modules:
> - net/atm/clip.c - Classical IP over ATM (RFC 2225)
> - net/atm/br2684.c - RFC 2684 bridged protocols
I believe PPPoE over BR2684 is also used on ADSL lines.
https://git.kernel.org/torvalds/c/ae088d663bee strongly seems to imply
that I used to use it myself, or at least was *able* to switch to it
for testing (although I could have sworn I mostly used PPPoA).
> - net/atm/lec.c - LAN Emulation Client (LANE)
> - net/atm/mpc.c, mpoa_caches.c, mpoa_proc.c - Multi-Protocol Over ATM
>
> Removed PCI/SBUS ATM device drivers (drivers/atm/):
> - adummy, atmtcp - software/testing ATM devices
> - eni - Efficient Networks ENI155P (OC-3, ~1995)
> - fore200e - FORE Systems 200E PCI/SBUS (OC-3, ~1999)
> - he - ForeRunner HE (OC-3/OC-12, ~2000)
> - idt77105 - IDT 77105 25 Mbps ATM PHY
> - idt77252 - IDT 77252 NICStAR II (OC-3, ~2000)
> - iphase - Interphase ATM PCI (OC-3/DS3/E3)
> - lanai - Efficient Networks Speedstream 3010
> - nicstar - IDT 77201 NICStAR (155/25 Mbps, ~1999)
> - solos-pci - Traverse Technologies ADSL2+ PCI (defunct vendor)
Traverse still exists: https://traverse.com.au/
I suspect they don't have a huge amount of interest in the Solos any
more, or the Geode-based SBC they sold with two of them on-board. But
OpenWrt does still support them, and I even have one here (although no
ADSL line to test it with). They were briefly popular as fully Linux-
supported ADSL routers.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] bitfield: add FIELD_GET_SIGNED()
From: David Laight @ 2026-04-21 9:27 UTC (permalink / raw)
To: Yury Norov
Cc: Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andy Lutomirski,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Ping-Ke Shih, Richard Cochran, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexandre Belloni,
Yury Norov, Rasmus Villemoes, Hans de Goede, Linus Walleij,
Sakari Ailus, Salah Triki, Achim Gratz, Ben Collins, linux-kernel,
linux-iio, linux-wireless, netdev, linux-rtc
In-Reply-To: <aeZocbNjbvzMZO8b@yury>
On Mon, 20 Apr 2026 13:54:57 -0400
Yury Norov <ynorov@nvidia.com> wrote:
> On Mon, Apr 20, 2026 at 01:19:40PM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 17, 2026 at 01:36:12PM -0400, Yury Norov wrote:
> > > The bitfields are designed in assumption that fields contain unsigned
> > > integer values, thus extracting the values from the field implies
> > > zero-extending.
> > >
> > > Some drivers need to sign-extend their fields, and currently do it like:
> > >
> > > dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > > dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> > >
> > > It's error-prone because it relies on user to provide the correct
> > > index of the most significant bit and proper 32 vs 64 function flavor.
> > >
> > > Thus, introduce a FIELD_GET_SIGNED() macro, which is the more
> > > convenient and compiles (on x86_64) to just a couple instructions:
> > > shl and sar.
> > >
> > > Signed-off-by: Yury Norov <ynorov@nvidia.com>
> > > ---
> > > include/linux/bitfield.h | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> > > index 54aeeef1f0ec..35ef63972810 100644
> > > --- a/include/linux/bitfield.h
> > > +++ b/include/linux/bitfield.h
> > > @@ -178,6 +178,22 @@
> > > __FIELD_GET(_mask, _reg, "FIELD_GET: "); \
> > > })
> > >
> > > +/**
> > > + * FIELD_GET_SIGNED() - extract a signed bitfield element
> > > + * @mask: shifted mask defining the field's length and position
> > > + * @reg: value of entire bitfield
> > > + *
> > > + * Returns the sign-extended field specified by @_mask from the
> > > + * bitfield passed in as @_reg by masking and shifting it down.
> > > + */
> > > +#define FIELD_GET_SIGNED(mask, reg) \
> > > + ({ \
> > > + __BF_FIELD_CHECK(mask, reg, 0U, "FIELD_GET_SIGNED: "); \
> > > + ((__signed_scalar_typeof(mask))((long long)(reg) << \
> > > + __builtin_clzll(mask) >> (__builtin_clzll(mask) + \
> > > + __builtin_ctzll(mask))));\
> > > + })
> >
> > IIRC clz is count-leading-zeros and ctz is count-trailing-zeros. Most of
> > the other FIELD things use __bf_shf() which is defined in terms of ffs -
> > 1 (which is another way of writing ctz).
> >
> > So how about you start by redefining __bf_shf() in ctz, and then add
> > another helper for the clz and write the thing something like:
> >
> > ((long long)(reg) << __bf_clz(mask)) >> (__bf_clz(mask) + __bf_shf(mask));
>
> So...
>
> I like the shorter form, but whatever we add in the bitfield.h - we'll
> have to support it.
>
> For example, __bf_shf() wasn't intended to be used outsize of the
> header, thus double underscored. But there's over 100 external users
> now. And to make it worse, it's broken for GCC 14 and earlier:
For anyone who hasn't followed the gory details it isn't 'very broken'.
Basically __builtin_ffsll() doesn't always generate an 'integer constant
expression' from constant input so you can get a compile fail.
> https://lore.kernel.org/all/20260409-field-prep-fix-v1-1-f0e9ae64f63c@imgtec.com/
>
> So needs to get fixed.
>
> The bitfield.h has two __bf macros: __bf_shf() and __bf_cast_unsigned().
> They are thin wrappers,
__bf_cast_unsigned() isn't exactly thin.
David
> but after all do something with the corresponding
> builtins output. The __bf_cls() would be a pure renaming. I'm OK with
> that, but some people don't:
>
> https://lore.kernel.org/all/20260303182845.250bb2de@kernel.org/
>
> That's why I didn't make FIELD_GET_SIGNED() implementation looking nicer.
> If you strongly prefer the shorter version, I can do that in v2.
>
> > Also, since the order of the shifts is rather important, I think it
> > makes sense to add this extra pair of (), even when not strictly needed,
> > just to make it easier to read.
>
> Sure, will do.
>
^ permalink raw reply
* Re: [PATCH] ieee802154: ca8210: fix cas_ctl leak on spi_async failure
From: Markus Elfring @ 2026-04-21 9:47 UTC (permalink / raw)
To: Shitalkumar Gandhi, linux-wpan, netdev, Alexander Aring,
Miquel Raynal, Stefan Schmidt
Cc: Shitalkumar Gandhi, stable, LKML, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
In-Reply-To: <20260421073259.2259783-1-shitalkumar.gandhi@cambiumnetworks.com>
…
> Fix it by freeing cas_ctl on the spi_async() error path. While here,
> correct the misleading error string: the function calls spi_async(),
> not spi_sync().
Would it be safer to offer desired changes as separate patches?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.0#n81
Regards,
Markus
^ permalink raw reply
* [PATCH net] net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels
From: Andrea Mayer @ 2026-04-21 9:47 UTC (permalink / raw)
To: davem, dsahern, edumazet, kuba, pabeni, horms
Cc: bigeasy, clrkwllms, rostedt, david.lebrun, alex.aring,
stefano.salsano, andrea.mayer, netdev, linux-rt-devel,
linux-kernel, stable
seg6_input_core() and rpl_input() call ip6_route_input() which sets a
NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking
dst_hold() unconditionally.
On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can
release the underlying pcpu_rt between the lookup and the caching
through a concurrent FIB lookup on a shared nexthop.
Simplified race sequence:
ksoftirqd/X higher-prio task (same CPU X)
----------- --------------------------------
seg6_input_core(,skb)/rpl_input(skb)
dst_cache_get()
-> miss
ip6_route_input(skb)
-> ip6_pol_route(,skb,flags)
[RT6_LOOKUP_F_DST_NOREF in flags]
-> FIB lookup resolves fib6_nh
[nhid=N route]
-> rt6_make_pcpu_route()
[creates pcpu_rt, refcount=1]
pcpu_rt->sernum = fib6_sernum
[fib6_sernum=W]
-> cmpxchg(fib6_nh.rt6i_pcpu,
NULL, pcpu_rt)
[slot was empty, store succeeds]
-> skb_dst_set_noref(skb, dst)
[dst is pcpu_rt, refcount still 1]
rt_genid_bump_ipv6()
-> bumps fib6_sernum
[fib6_sernum from W to Z]
ip6_route_output()
-> ip6_pol_route()
-> FIB lookup resolves fib6_nh
[nhid=N]
-> rt6_get_pcpu_route()
pcpu_rt->sernum != fib6_sernum
[W <> Z, stale]
-> prev = xchg(rt6i_pcpu, NULL)
-> dst_release(prev)
[prev is pcpu_rt,
refcount 1->0, dead]
dst = skb_dst(skb)
[dst is the dead pcpu_rt]
dst_cache_set_ip6(dst)
-> dst_hold() on dead dst
-> WARN / use-after-free
For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without
PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release
the pcpu_rt. Shared nexthop objects provide such a path, as two routes
pointing to the same nhid share the same fib6_nh and its rt6i_pcpu
entry.
Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after
ip6_route_input() to force the NOREF dst into a refcounted one before
caching.
The output path is not affected as ip6_route_output() already returns a
refcounted dst.
Fixes: af4a2209b134 ("ipv6: sr: use dst_cache in seg6_input")
Fixes: a7a29f9c361f ("net: ipv6: add rpl sr tunnel")
Cc: stable@vger.kernel.org
Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
---
net/ipv6/rpl_iptunnel.c | 9 +++++++++
net/ipv6/seg6_iptunnel.c | 9 +++++++++
2 files changed, 18 insertions(+)
diff --git a/net/ipv6/rpl_iptunnel.c b/net/ipv6/rpl_iptunnel.c
index c7942cf65567..4e10adcd70e8 100644
--- a/net/ipv6/rpl_iptunnel.c
+++ b/net/ipv6/rpl_iptunnel.c
@@ -287,7 +287,16 @@ static int rpl_input(struct sk_buff *skb)
if (!dst) {
ip6_route_input(skb);
+
+ /* ip6_route_input() sets a NOREF dst; force a refcount on it
+ * before caching or further use.
+ */
+ skb_dst_force(skb);
dst = skb_dst(skb);
+ if (unlikely(!dst)) {
+ err = -ENETUNREACH;
+ goto drop;
+ }
/* cache only if we don't create a dst reference loop */
if (!dst->error && lwtst != dst->lwtstate) {
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index 97b50d9b1365..94284b483be0 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -515,7 +515,16 @@ static int seg6_input_core(struct net *net, struct sock *sk,
if (!dst) {
ip6_route_input(skb);
+
+ /* ip6_route_input() sets a NOREF dst; force a refcount on it
+ * before caching or further use.
+ */
+ skb_dst_force(skb);
dst = skb_dst(skb);
+ if (unlikely(!dst)) {
+ err = -ENETUNREACH;
+ goto drop;
+ }
/* cache only if we don't create a dst reference loop */
if (!dst->error && lwtst != dst->lwtstate) {
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net v8 03/15] net: cache snapshot entries for ndo_set_rx_mode_async
From: Paolo Abeni @ 2026-04-21 9:52 UTC (permalink / raw)
To: Stanislav Fomichev, netdev; +Cc: davem, edumazet, kuba
In-Reply-To: <20260416185712.2155425-4-sdf@fomichev.me>
On 4/16/26 8:57 PM, Stanislav Fomichev wrote:
> Add a per-device netdev_hw_addr_list cache (rx_mode_addr_cache) that
> allows __hw_addr_list_snapshot() and __hw_addr_list_reconcile() to
> reuse previously allocated entries instead of hitting GFP_ATOMIC on
> every snapshot cycle.
>
> snapshot pops entries from the cache when available, falling back to
> __hw_addr_create(). reconcile splices both snapshot lists back into
> the cache via __hw_addr_splice(). The cache is flushed in
> free_netdev().
>
> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
> (cherry picked from commit ba3ab1832a511f660fdc6231245b14bf610c05bd)
Are you backporting from 7.2 via time machine??? :-P
> @@ -611,8 +633,8 @@ void __hw_addr_list_reconcile(struct netdev_hw_addr_list *real_list,
> }
> }
>
> - __hw_addr_flush(work);
> - __hw_addr_flush(ref);
> + __hw_addr_splice(cache, work);
> + __hw_addr_splice(cache, ref);
I think here sashiko has a point, with the cache size being unbounded. I
guess syzkaller or the like will find a way to make it grow too much.
What about hard-limit it to some reasonable value?!?
/P
^ permalink raw reply
* [PATCH] mptcp: add per-reason MIB counters for MPTCP_RST_EMPTCP resets
From: Shardul Bankar @ 2026-04-21 9:56 UTC (permalink / raw)
To: matttbe, martineau
Cc: geliang, davem, edumazet, kuba, pabeni, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani, shardulsb08, Shardul Bankar
MPTCP_RST_EMPTCP (reset reason 1) is used as a catch-all for seven
distinct error conditions across subflow setup, authentication, and
data path validation. The existing MPRstTx/MPRstRx counters only
track aggregate reset volume, making it difficult to diagnose which
code path is triggering subflow resets in production.
Add per-reason MIB counters for each MPTCP_RST_EMPTCP use site:
MPRstMD5SIG - MD5SIG on listener, incompatible with MPTCP
MPRstNoToken - JOIN token lookup failed, no matching conn
MPRstNoMPJ - SYN/ACK missing MP_JOIN option
MPRstHMAC - HMAC validation failed during subflow join
MPRstFatalFallback - fatal fallback during child socket creation
MPRstBadMap - invalid data mapping on established subflow
MPRstNotEstablished - JOIN on not-fully-established msk
These counters are incremented alongside the existing reset_reason
assignment and are visible via nstat as MPTcpExtMPRst*. The
aggregate MPRstTx/MPRstRx counters remain unchanged.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/511
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
---
net/mptcp/mib.c | 7 +++++++
net/mptcp/mib.h | 7 +++++++
net/mptcp/protocol.c | 1 +
net/mptcp/subflow.c | 14 +++++++++++---
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/net/mptcp/mib.c b/net/mptcp/mib.c
index f23fda0c55a7..ec42583c59cf 100644
--- a/net/mptcp/mib.c
+++ b/net/mptcp/mib.c
@@ -71,6 +71,13 @@ static const struct snmp_mib mptcp_snmp_list[] = {
SNMP_MIB_ITEM("MPFastcloseRx", MPTCP_MIB_MPFASTCLOSERX),
SNMP_MIB_ITEM("MPRstTx", MPTCP_MIB_MPRSTTX),
SNMP_MIB_ITEM("MPRstRx", MPTCP_MIB_MPRSTRX),
+ SNMP_MIB_ITEM("MPRstMD5SIG", MPTCP_MIB_MPRSTMD5SIG),
+ SNMP_MIB_ITEM("MPRstNoToken", MPTCP_MIB_MPRSTNOTOKEN),
+ SNMP_MIB_ITEM("MPRstNoMPJ", MPTCP_MIB_MPRSTNOMPJ),
+ SNMP_MIB_ITEM("MPRstHMAC", MPTCP_MIB_MPRSTHMAC),
+ SNMP_MIB_ITEM("MPRstFatalFallback", MPTCP_MIB_MPRSTFATALFALLBACK),
+ SNMP_MIB_ITEM("MPRstBadMap", MPTCP_MIB_MPRSTBADMAP),
+ SNMP_MIB_ITEM("MPRstNotEstablished", MPTCP_MIB_MPRSTNOTESTABLISHED),
SNMP_MIB_ITEM("SubflowStale", MPTCP_MIB_SUBFLOWSTALE),
SNMP_MIB_ITEM("SubflowRecover", MPTCP_MIB_SUBFLOWRECOVER),
SNMP_MIB_ITEM("SndWndShared", MPTCP_MIB_SNDWNDSHARED),
diff --git a/net/mptcp/mib.h b/net/mptcp/mib.h
index 812218b5ed2b..0ac109b52d35 100644
--- a/net/mptcp/mib.h
+++ b/net/mptcp/mib.h
@@ -70,6 +70,13 @@ enum linux_mptcp_mib_field {
MPTCP_MIB_MPFASTCLOSERX, /* Received a MP_FASTCLOSE */
MPTCP_MIB_MPRSTTX, /* Transmit a MP_RST */
MPTCP_MIB_MPRSTRX, /* Received a MP_RST */
+ MPTCP_MIB_MPRSTMD5SIG, /* MP_RST: MD5SIG enabled on listener */
+ MPTCP_MIB_MPRSTNOTOKEN, /* MP_RST: JOIN token not found */
+ MPTCP_MIB_MPRSTNOMPJ, /* MP_RST: missing MPJ in SYN/ACK */
+ MPTCP_MIB_MPRSTHMAC, /* MP_RST: HMAC validation failed */
+ MPTCP_MIB_MPRSTFATALFALLBACK, /* MP_RST: fatal fallback on child */
+ MPTCP_MIB_MPRSTBADMAP, /* MP_RST: bad data mapping */
+ MPTCP_MIB_MPRSTNOTESTABLISHED, /* MP_RST: JOIN on not-established msk */
MPTCP_MIB_SUBFLOWSTALE, /* Subflows entered 'stale' status */
MPTCP_MIB_SUBFLOWRECOVER, /* Subflows returned to active status after being stale */
MPTCP_MIB_SNDWNDSHARED, /* Subflow snd wnd is overridden by msk's one */
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 17b9a8c13ebf..b06cbcf983f4 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3836,6 +3836,7 @@ bool mptcp_finish_join(struct sock *ssk)
/* mptcp socket already closing? */
if (!mptcp_is_fully_established(parent)) {
+ MPTCP_INC_STATS(sock_net(parent), MPTCP_MIB_MPRSTNOTESTABLISHED);
subflow->reset_reason = MPTCP_RST_EMPTCP;
return false;
}
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index e2cb9d23e4a0..71bffcda0138 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -160,6 +160,7 @@ static int subflow_check_req(struct request_sock *req,
* TCP option space.
*/
if (rcu_access_pointer(tcp_sk(sk_listener)->md5sig_info)) {
+ MPTCP_INC_STATS(sock_net(sk_listener), MPTCP_MIB_MPRSTMD5SIG);
subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP);
return -EINVAL;
}
@@ -227,6 +228,7 @@ static int subflow_check_req(struct request_sock *req,
/* Can't fall back to TCP in this case. */
if (!subflow_req->msk) {
+ MPTCP_INC_STATS(sock_net(sk_listener), MPTCP_MIB_MPRSTNOTOKEN);
subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP);
return -EPERM;
}
@@ -568,6 +570,7 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
u8 hmac[SHA256_DIGEST_SIZE];
if (!(mp_opt.suboptions & OPTION_MPTCP_MPJ_SYNACK)) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPRSTNOMPJ);
subflow->reset_reason = MPTCP_RST_EMPTCP;
goto do_reset;
}
@@ -582,6 +585,7 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
if (!subflow_thmac_valid(subflow)) {
MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINACKMAC);
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPRSTHMAC);
subflow->reset_reason = MPTCP_RST_EMPTCP;
goto do_reset;
}
@@ -870,6 +874,7 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
*/
if (!ctx || fallback) {
if (fallback_is_fatal) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPRSTFATALFALLBACK);
subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP);
goto dispose_child;
}
@@ -1421,9 +1426,12 @@ static bool subflow_check_data_avail(struct sock *ssk)
* subflow_error_report() will introduce the appropriate barriers
*/
subflow->reset_transient = 0;
- subflow->reset_reason = status == MAPPING_NODSS ?
- MPTCP_RST_EMIDDLEBOX :
- MPTCP_RST_EMPTCP;
+ if (status == MAPPING_NODSS) {
+ subflow->reset_reason = MPTCP_RST_EMIDDLEBOX;
+ } else {
+ MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_MPRSTBADMAP);
+ subflow->reset_reason = MPTCP_RST_EMPTCP;
+ }
reset:
WRITE_ONCE(ssk->sk_err, EBADMSG);
--
2.34.1
^ permalink raw reply related
* [PATCH net] iavf: iavf_virtchnl_completion: drop duplicate ether_addr_equal() test
From: Corinna Vinschen @ 2026-04-21 9:59 UTC (permalink / raw)
To: intel-wired-lan, netdev
Cc: Jose Ignacio Tornos Martinez, Michal Schmidt, Corinna Vinschen
This is just a simple cleanup fix. Commit 35a2443d0910f ("iavf: Add
waiting for response from PF in set mac") introduced a duplicate
ether_addr_equal() check, so the current code tests the new MAC twice
against the former MAC.
Remove the outer ether_addr_equal() test, remnant of commit c5c922b3e09b
("iavf: fix MAC address setting for VFs when filter is rejected")
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
Fixes: 35a2443d0910f ("iavf: Add waiting for response from PF in set mac")
---
drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
index a52c100dcbc5..9b8e7e4376c2 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
@@ -2579,13 +2579,11 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
case VIRTCHNL_OP_ADD_ETH_ADDR:
if (!v_retval)
iavf_mac_add_ok(adapter);
- if (!ether_addr_equal(netdev->dev_addr, adapter->hw.mac.addr))
- if (!ether_addr_equal(netdev->dev_addr,
- adapter->hw.mac.addr)) {
- netif_addr_lock_bh(netdev);
- eth_hw_addr_set(netdev, adapter->hw.mac.addr);
- netif_addr_unlock_bh(netdev);
- }
+ if (!ether_addr_equal(netdev->dev_addr, adapter->hw.mac.addr)) {
+ netif_addr_lock_bh(netdev);
+ eth_hw_addr_set(netdev, adapter->hw.mac.addr);
+ netif_addr_unlock_bh(netdev);
+ }
wake_up(&adapter->vc_waitqueue);
break;
case VIRTCHNL_OP_GET_STATS: {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] mptcp: add per-reason MIB counters for MPTCP_RST_EMPTCP resets
From: Matthieu Baerts @ 2026-04-21 10:14 UTC (permalink / raw)
To: Shardul Bankar, martineau
Cc: geliang, davem, edumazet, kuba, pabeni, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani, Shardul Bankar
In-Reply-To: <20260421095646.3741956-1-shardul.b@mpiricsoftware.com>
Hi Shardul,
On 21/04/2026 11:56, Shardul Bankar wrote:
> MPTCP_RST_EMPTCP (reset reason 1) is used as a catch-all for seven
> distinct error conditions across subflow setup, authentication, and
> data path validation. The existing MPRstTx/MPRstRx counters only
> track aggregate reset volume, making it difficult to diagnose which
> code path is triggering subflow resets in production.
>
> Add per-reason MIB counters for each MPTCP_RST_EMPTCP use site:
>
> MPRstMD5SIG - MD5SIG on listener, incompatible with MPTCP
> MPRstNoToken - JOIN token lookup failed, no matching conn
> MPRstNoMPJ - SYN/ACK missing MP_JOIN option
> MPRstHMAC - HMAC validation failed during subflow join
> MPRstFatalFallback - fatal fallback during child socket creation
> MPRstBadMap - invalid data mapping on established subflow
> MPRstNotEstablished - JOIN on not-fully-established msk
>
> These counters are incremented alongside the existing reset_reason
> assignment and are visible via nstat as MPTcpExtMPRst*. The
> aggregate MPRstTx/MPRstRx counters remain unchanged.
Thank you for this patch.
Even if the patch looks globally good, net-next is currently closed, and
only bug fixes are accepted, see:
https://docs.kernel.org/process/maintainer-netdev.html
pw-bot: defer
Instead, I suggest switching the discussions only on the MPTCP ML: I
will try to review this patch and only send a reply to you and the MPTCP
list, if that's OK.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net] iavf: iavf_virtchnl_completion: drop duplicate ether_addr_equal() test
From: Loktionov, Aleksandr @ 2026-04-21 10:20 UTC (permalink / raw)
To: Vinschen, Corinna, intel-wired-lan@osuosl.org,
netdev@vger.kernel.org
Cc: Vinschen, Corinna, Jose Ignacio Tornos Martinez
In-Reply-To: <20260421095947.868695-1-vinschen@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Corinna Vinschen
> Sent: Tuesday, April 21, 2026 12:00 PM
> To: intel-wired-lan@osuosl.org; netdev@vger.kernel.org
> Cc: Vinschen, Corinna <vinschen@redhat.com>; Jose Ignacio Tornos
> Martinez <jtornosm@redhat.com>
> Subject: [Intel-wired-lan] [PATCH net] iavf: iavf_virtchnl_completion:
> drop duplicate ether_addr_equal() test
>
> This is just a simple cleanup fix. Commit 35a2443d0910f ("iavf: Add
> waiting for response from PF in set mac") introduced a duplicate
> ether_addr_equal() check, so the current code tests the new MAC twice
> against the former MAC.
>
> Remove the outer ether_addr_equal() test, remnant of commit
> c5c922b3e09b
> ("iavf: fix MAC address setting for VFs when filter is rejected")
>
> Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
> Fixes: 35a2443d0910f ("iavf: Add waiting for response from PF in set
> mac")
I think Cc: stable@vger.kernel.org should be added.
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> index a52c100dcbc5..9b8e7e4376c2 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> @@ -2579,13 +2579,11 @@ void iavf_virtchnl_completion(struct
> iavf_adapter *adapter,
> case VIRTCHNL_OP_ADD_ETH_ADDR:
> if (!v_retval)
> iavf_mac_add_ok(adapter);
> - if (!ether_addr_equal(netdev->dev_addr, adapter-
> >hw.mac.addr))
> - if (!ether_addr_equal(netdev->dev_addr,
> - adapter->hw.mac.addr)) {
> - netif_addr_lock_bh(netdev);
> - eth_hw_addr_set(netdev, adapter-
> >hw.mac.addr);
> - netif_addr_unlock_bh(netdev);
> - }
> + if (!ether_addr_equal(netdev->dev_addr, adapter-
> >hw.mac.addr)) {
> + netif_addr_lock_bh(netdev);
> + eth_hw_addr_set(netdev, adapter->hw.mac.addr);
> + netif_addr_unlock_bh(netdev);
> + }
> wake_up(&adapter->vc_waitqueue);
> break;
> case VIRTCHNL_OP_GET_STATS: {
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH] mptcp: add per-reason MIB counters for MPTCP_RST_EMPTCP resets
From: Shardul Bankar @ 2026-04-21 10:24 UTC (permalink / raw)
To: Matthieu Baerts, martineau
Cc: geliang, davem, edumazet, kuba, pabeni, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani
In-Reply-To: <3dbda2d2-c7e5-4a12-90c0-d1f98e3d89ee@kernel.org>
On Tue, 2026-04-21 at 12:14 +0200, Matthieu Baerts wrote:
> Hi Shardul,
>
>
> Even if the patch looks globally good, net-next is currently closed,
> and
> only bug fixes are accepted, see:
>
> https://docs.kernel.org/process/maintainer-netdev.html
>
> pw-bot: defer
>
> Instead, I suggest switching the discussions only on the MPTCP ML: I
> will try to review this patch and only send a reply to you and the
> MPTCP
> list, if that's OK.
>
> Cheers,
> Matt
Hi Matt,
Thanks for looking at this. Happy to continue on the MPTCP list.
Thanks,
Shardul
^ permalink raw reply
* Re: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
From: Lee Jones @ 2026-04-21 10:35 UTC (permalink / raw)
To: Tung Quang Nguyen
Cc: Jon Maloy, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, netdev@vger.kernel.org,
tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org
In-Reply-To: <20260420151040.GF3202366@google.com>
On Mon, 20 Apr 2026, Lee Jones wrote:
> On Mon, 20 Apr 2026, Tung Quang Nguyen wrote:
>
> > >> Subject: [PATCH 1/1] tipc: fix double-free in tipc_buf_append()
> > >> >
> > >> >The tipc_msg_validate() function can potentially reallocate the skb
> > >> >it is validating, freeing the old one. In tipc_buf_append(), it was
> > >> >being called with a pointer to a local variable which was a copy of the
> > >caller's skb pointer.
> > >> >
> > >> >If the skb was reallocated and validation subsequently failed, the
> > >> >error handling path would free the original skb pointer, which had
> > >> >already been freed, leading to double-free.
> > >> >
> > >> >Fix this by passing the caller's skb pointer-pointer directly to
> > >> >tipc_msg_validate(), ensuring any modification is reflected correctly.
> > >> >The local skb pointer is then updated from the (possibly modified)
> > >> >caller's pointer.
> > >> >
> > >> >Fixes: d618d09a68e4 ("tipc: enforce valid ratio between skb truesize
> > >> >and
> > >> >contents")
> > >> >Assisted-by: Gemini:gemini-3.1-pro-preview
> > >> >Signed-off-by: Lee Jones <lee@kernel.org>
> > >> >---
> > >> > net/tipc/msg.c | 3 ++-
> > >> > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >> >
> > >> >diff --git a/net/tipc/msg.c b/net/tipc/msg.c index
> > >> >76284fc538eb..9f4f612ee027
> > >> >100644
> > >> >--- a/net/tipc/msg.c
> > >> >+++ b/net/tipc/msg.c
> > >> >@@ -177,8 +177,9 @@ int tipc_buf_append(struct sk_buff **headbuf,
> > >> >struct sk_buff **buf)
> > >> >
> > >> > if (fragid == LAST_FRAGMENT) {
> > >> > TIPC_SKB_CB(head)->validated = 0;
> > >> >- if (unlikely(!tipc_msg_validate(&head)))
> > >> >+ if (unlikely(!tipc_msg_validate(headbuf)))
> > >> > goto err;
> > >> >+ head = *headbuf;
> > >> This is a known issue and was reported via
> > >> https://patchwork.kernel.org/project/netdevbpf/patch/20260330205313.24
> > >> 33372-1-nicholas@carlini.com/ The author did not respond to my
> > >> comment.
> > >> Can you improve the fix by applying my patch?
> > >
> > >I'd be happy to make any required changes.
> > >
> > >However, is this approach superior to simply passing a reference?
> > >
> > >v1 appears to be simpler, easier to read and avoids the explanation.
> > >
> > As I explained, your fix adds extra overhead to normal path while the error path is corner case and it rarely happens.
> > Whatever approach is applied, we need to add explanation to understand more easily the logic and hidden trick in tipc_msg_validate().
>
> Very well. I have made the recommended changes.
>
> The patch is currently in my build-test environment.
>
> I will post v2, when everything has been satisfied.
Okay, I genuinely tried to apply your patch. It builds just fine, but
Gemini (the AI I use to pre-review patches before submission) has some
doubts that this is the correct approach:
> @@ -177,8 +177,20 @@ int tipc_buf_append(struct sk_buff **headbuf, struct sk_buff **buf)
>
> if (fragid == LAST_FRAGMENT) {
> TIPC_SKB_CB(head)->validated = 0;
> - if (unlikely(!tipc_msg_validate(&head)))
> +
> + /* If the reassembled skb has been freed in
> + * tipc_msg_validate() because of an invalid truesize,
> + * then head will point to a newly allocated reassembled
> + * skb, while *headbuf points to freed reassembled skb.
> + * In such cases, correct *headbuf for freeing the newly
> + * allocated reassembled skb later.
> + *
> + * Note: It's done this way instead of passing &head // I added this part to give
> + * to avoid slowing down the happy path since this failure // the reviewer some additoinal
> + * is a rare event. // context
> + */
> + if (unlikely(!tipc_msg_validate(headbuf))) {
> + if (head != *headbuf)
> + *headbuf = head;
> goto err;
> + }
> +
"It looks like this logic might re-introduce the double-free bug.
The call to `tipc_msg_validate(headbuf)` is correct, as it passes the
pointer-to-pointer and allows the callee to update `*headbuf` if the skb
is reallocated.
However, the subsequent check seems to undo this. If a reallocation
happens, `head` will hold the pointer to the old, freed skb, while
`*headbuf` will hold the new one. The condition `head != *headbuf` will
be true, and the assignment `*headbuf = head` will restore the stale
pointer, leading to a double-free on the `err` path.
The preceding comment also appears to have the pointer roles reversed.
Would it be simpler and more correct to remove the `if (head != *headbuf)`
check and the large comment block? The change from `&head` to `headbuf`
in the function call seems to be the only change required to fix the bug.
Also, please update the commit message to reflect the corrected logic."
I suggest that we go with the original patch. Although I find it admirable
that you are thinking about and attempting to protect the more common
happy-path, I think the resultant single additional variable assignment
is negligible and that the simplicity of the previous fix has greater
benefits in terms of code readability and maintainability.
If you like, I can add a small comment, but I doubt even that is necessary.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH net v3 3/5] iavf: send MAC change request synchronously
From: Jose Ignacio Tornos Martinez @ 2026-04-21 10:45 UTC (permalink / raw)
To: przemyslaw.kitszel
Cc: anthony.l.nguyen, davem, edumazet, intel-wired-lan, jtornosm,
kuba, netdev, pabeni, stable, horms
In-Reply-To: <d04d7827-f990-45ac-aadb-4079ab270159@intel.com>
Hello Przemek,
Thank you again for your comments, I appreciate your help.
I will try to include the new ones too in the next version.
I am also trying to analyze the comments from Simon with his AI review
tool.
Thanks
Best regards
Jose Ignacio
^ permalink raw reply
* Re: [PATCH net v8 03/15] net: cache snapshot entries for ndo_set_rx_mode_async
From: Paolo Abeni @ 2026-04-21 10:48 UTC (permalink / raw)
To: Stanislav Fomichev, netdev; +Cc: davem, edumazet, kuba
In-Reply-To: <1d871492-2da5-44b0-b6fe-860966dff55a@redhat.com>
On 4/21/26 11:52 AM, Paolo Abeni wrote:
> On 4/16/26 8:57 PM, Stanislav Fomichev wrote:
>> Add a per-device netdev_hw_addr_list cache (rx_mode_addr_cache) that
>> allows __hw_addr_list_snapshot() and __hw_addr_list_reconcile() to
>> reuse previously allocated entries instead of hitting GFP_ATOMIC on
>> every snapshot cycle.
>>
>> snapshot pops entries from the cache when available, falling back to
>> __hw_addr_create(). reconcile splices both snapshot lists back into
>> the cache via __hw_addr_splice(). The cache is flushed in
>> free_netdev().
>>
>> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
>> (cherry picked from commit ba3ab1832a511f660fdc6231245b14bf610c05bd)
>
> Are you backporting from 7.2 via time machine??? :-P
>
>> @@ -611,8 +633,8 @@ void __hw_addr_list_reconcile(struct netdev_hw_addr_list *real_list,
>> }
>> }
>>
>> - __hw_addr_flush(work);
>> - __hw_addr_flush(ref);
>> + __hw_addr_splice(cache, work);
>> + __hw_addr_splice(cache, ref);
>
> I think here sashiko has a point, with the cache size being unbounded. I
> guess syzkaller or the like will find a way to make it grow too much.
>
> What about hard-limit it to some reasonable value?!?
There are a few more remarks from sashiko at the driver level, but
AFAICS are all pre-existing issues.
I think even the above one it's better handled as a follow-up, so I'm
applying the series as-is (I'll just drop the cherry-pick statement above).
/P
^ permalink raw reply
* [PATCH v2] usb: rtl8150: avoid using uninitialized CSCR value
From: Morduan Zang @ 2026-04-21 10:51 UTC (permalink / raw)
To: zhangdandan
Cc: andrew+netdev, davem, edumazet, kuba, linux-kernel, linux-usb,
netdev, pabeni, petkan, syzbot+9db6c624635564ad813c, Simon Horman,
Andrew Lunn, Michal Pecio
In-Reply-To: <93FF85BB9F33CD2B+20260402070743.20641-1-zhangdandan@uniontech.com>
set_carrier() reads CSCR via get_registers() (a USB control transfer)
without checking the return value, so a transient control transfer
failure would leave the on-stack "tmp" uninitialized and then be used
to decide the netif carrier state.
Check the return value of get_registers() and bail out on error,
leaving the previously known carrier state untouched. A failed USB
control transfer here may be transient (e.g. EMI, flaky cable, retries
exhausted), so it is wrong to force the link down on such failures and
cause the carrier state to toggle unnecessarily.
This only addresses the uninitialized-value usage and does not change
link-state policy.
Reported-by: syzbot+9db6c624635564ad813c@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9db6c624635564ad813c
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Petko Manolov <petkan@nucleusys.com>
Cc: Simon Horman <horms@kernel.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Michal Pecio <michal.pecio@gmail.com>
Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
---
Changes in v2:
- Do not force netif_carrier_off() on get_registers() failure; instead
return and keep the previous carrier state. A transient USB control
transfer failure should not cause carrier to toggle.
(based on review feedback from Simon Horman, Petko Manolov,
Andrew Lunn and Michal Pecio.)
- Minimal change: only avoid the uninitialized read; no link-state
policy change. Petko's Ack on v1 is not carried over because v2
changes the error-handling behavior.
Changes in v1:
- Initial submission: on get_registers() failure call
netif_carrier_off() and return.
---
drivers/net/usb/rtl8150.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 4cda0643afb6..816759ced56c 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -722,7 +722,8 @@ static void set_carrier(struct net_device *netdev)
rtl8150_t *dev = netdev_priv(netdev);
short tmp;
- get_registers(dev, CSCR, 2, &tmp);
+ if (get_registers(dev, CSCR, 2, &tmp) < 0)
+ return;
if (tmp & CSCR_LINK_STATUS)
netif_carrier_on(netdev);
else
--
2.50.1
^ permalink raw reply related
* Re: [PATCH net v8 00/15] net: sleepable ndo_set_rx_mode
From: patchwork-bot+netdevbpf @ 2026-04-21 11:00 UTC (permalink / raw)
To: Stanislav Fomichev; +Cc: netdev, davem, edumazet, kuba, pabeni
In-Reply-To: <20260416185712.2155425-1-sdf@fomichev.me>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 16 Apr 2026 11:56:57 -0700 you wrote:
> This series adds a new ndo_set_rx_mode_async callback that enables
> drivers to handle address list updates in a sleepable context. The
> current ndo_set_rx_mode is called under the netif_addr_lock spinlock
> with BHs disabled, which prevents drivers from sleeping. This is
> problematic for ops-locked drivers that need to sleep.
>
> The approach:
> 1. Add snapshot/reconcile infrastructure for address lists
> 2. Introduce dev_rx_mode_work that takes snapshots under the lock,
> drops the lock, calls the driver, then reconciles changes back
> 3. Move promiscuity handling into the scheduled work as well
> 4. Convert existing ops-locked drivers to ndo_set_rx_mode_async
> 5. Add a warning for ops-locked drivers still using ndo_set_rx_mode
> 6. Add a selftest exercising the team+bridge+macvlan topology that
> triggers the addr_lock -> ops_lock ordering issue
>
> [...]
Here is the summary with links:
- [net,v8,01/15] net: add address list snapshot and reconciliation infrastructure
https://git.kernel.org/netdev/net/c/db9e726525e4
- [net,v8,02/15] net: introduce ndo_set_rx_mode_async and netdev_rx_mode_work
https://git.kernel.org/netdev/net/c/3554b4345d85
- [net,v8,03/15] net: cache snapshot entries for ndo_set_rx_mode_async
https://git.kernel.org/netdev/net/c/a4c833278144
- [net,v8,04/15] net: move promiscuity handling into netdev_rx_mode_work
https://git.kernel.org/netdev/net/c/7ef83bf1712b
- [net,v8,05/15] fbnic: convert to ndo_set_rx_mode_async
https://git.kernel.org/netdev/net/c/60dd9781e9b8
- [net,v8,06/15] mlx5: convert to ndo_set_rx_mode_async
https://git.kernel.org/netdev/net/c/5cf06fbdaf02
- [net,v8,07/15] bnxt: convert to ndo_set_rx_mode_async
https://git.kernel.org/netdev/net/c/f6c53cfa1217
- [net,v8,08/15] bnxt: use snapshot in bnxt_cfg_rx_mode
https://git.kernel.org/netdev/net/c/a453b5d9b3ed
- [net,v8,09/15] iavf: convert to ndo_set_rx_mode_async
https://git.kernel.org/netdev/net/c/d071c15b43e9
- [net,v8,10/15] netdevsim: convert to ndo_set_rx_mode_async
https://git.kernel.org/netdev/net/c/8a5df09e70c2
- [net,v8,11/15] dummy: convert to ndo_set_rx_mode_async
https://git.kernel.org/netdev/net/c/4d157e89bde4
- [net,v8,12/15] netkit: convert to ndo_set_rx_mode_async
https://git.kernel.org/netdev/net/c/754b7e1169a7
- [net,v8,13/15] net: warn ops-locked drivers still using ndo_set_rx_mode
https://git.kernel.org/netdev/net/c/3cbd22938877
- [net,v8,14/15] selftests: net: add team_bridge_macvlan rx_mode test
https://git.kernel.org/netdev/net/c/ee514cdb07b3
- [net,v8,15/15] selftests: net: use ip commands instead of teamd in team rx_mode test
https://git.kernel.org/netdev/net/c/c4dde411bc36
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ 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