* Re: [PATCH net] xfrm: hold skb->dev across async IPv6 transport reinject
From: Steffen Klassert @ 2026-03-31 7:59 UTC (permalink / raw)
To: Qi Tang; +Cc: davem, edumazet, herbert, horms, kuba, netdev, pabeni
In-Reply-To: <20260326124131.193796-1-tpluszz77@gmail.com>
On Thu, Mar 26, 2026 at 08:41:31PM +0800, Qi Tang wrote:
> I reworked the fix direction to avoid taking another netdev reference.
>
> The current idea is to reuse the existing dev_hold() in xfrm_input(),
> carry that reference across the async transport reinject path, and drop
> it only once the skb is either consumed earlier or the async reinject
> callback has completed.
>
> Very roughly, the change would look like this:
>
> - in xfrm_input(), do not drop the existing dev reference immediately
> on async resume
> - add a dedicated queueing path for skbs that already carry that
> input-side reference
> - in transport_finish(), switch from NF_HOOK() to nf_hook() so the
> ret != 1 path can drop the carried reference when the skb is consumed
> before okfn runs
> - in xfrm_trans_reinject(), drop the transferred reference after the
> callback completes
>
> Something along these lines:
>
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> @@
> if (encap_type == -1) {
> async = 1;
> - dev_put(skb->dev);
> seq = XFRM_SKB_CB(skb)->seq.input.low;
> ...
> }
>
> @@
> +int xfrm_trans_queue_in(struct net *net, struct sk_buff *skb, ...)
> +{
> + ...
> + XFRM_TRANS_SKB_CB(skb)->dev_ref_held = true;
> + ...
> +}
>
> diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
> @@
> - NF_HOOK(..., xfrm6_transport_finish2);
> + ret = nf_hook(..., async ? xfrm6_transport_finish2_async :
> + xfrm6_transport_finish2);
> + if (ret != 1) {
> + if (async)
> + dev_put(dev);
> + return 0;
> + }
> + (async ? xfrm6_transport_finish2_async :
> + xfrm6_transport_finish2)(net, NULL, skb);
>
> diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
> @@
> while ((skb = __skb_dequeue(&queue))) {
> + bool dev_ref_held = cb->dev_ref_held;
> + struct net_device *dev = dev_ref_held ? skb->dev : NULL;
> cb->finish(cb->net, NULL, skb);
> + if (dev_ref_held)
> + dev_put(dev);
> }
>
> Does this sound like a reasonable direction for a v2?
Please send the actual patch for review. It is hard to
guess from such snippets if that's the correct way to
go.
Thanks!
^ permalink raw reply
* [PATCH RESEND net v2 1/1] net/sched: sch_netem: fix out-of-bounds access in packet corruption
From: Yucheng Lu @ 2026-03-31 8:00 UTC (permalink / raw)
To: security, stephen, netdev
Cc: jhs, jiri, davem, Jason, kees, yifanwucs, tomapufckgml, tanyuan98,
bird, z1652074432, Yucheng Lu
In-Reply-To: <cover.1773323637.git.kanolyc@gmail.com>
In netem_enqueue(), the packet corruption logic uses
get_random_u32_below(skb_headlen(skb)) to select an index for
modifying skb->data. When an AF_PACKET TX_RING sends fully non-linear
packets over an IPIP tunnel, skb_headlen(skb) evaluates to 0.
Passing 0 to get_random_u32_below() takes the variable-ceil slow path
which returns an unconstrained 32-bit random integer. Using this
unconstrained value as an offset into skb->data results in an
out-of-bounds memory access.
Fix this by verifying skb_headlen(skb) is non-zero before attempting
to corrupt the linear data area. Fully non-linear packets will silently
bypass the corruption logic.
Fixes: c865e5d99e25 ("[PKT_SCHED] netem: packet corruption option")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Signed-off-by: Yuan Tan <tanyuan98@outlook.com>
Signed-off-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Yuhang Zheng <z1652074432@gmail.com>
Signed-off-by: Yucheng Lu <kanolyc@gmail.com>
---
This email was not CCed to the public mailing list previously, so I am
resending it with the mailing list included. Sorry for the inconvenience.
net/sched/sch_netem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_netem.c b/net/sched/sch_netem.c
index 5de1c932944a..da9e2f60160c 100644
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -519,8 +519,9 @@ static int netem_enqueue(struct sk_buff *skb, struct Qdisc *sch,
goto finish_segs;
}
- skb->data[get_random_u32_below(skb_headlen(skb))] ^=
- 1<<get_random_u32_below(8);
+ if (skb_headlen(skb))
+ skb->data[get_random_u32_below(skb_headlen(skb))] ^=
+ 1 << get_random_u32_below(8);
}
if (unlikely(q->t_len >= sch->limit)) {
--
2.47.3
^ permalink raw reply related
* RE: [net-next PATCH v2 00/13] net: renesas: rswitch: R-Car S4 add VLAN aware switching
From: Michael Dege @ 2026-03-31 8:04 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Yoshihiro Shimoda, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, netdev@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260327103650.7d483c03@kernel.org>
Hello Jakub,
> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Friday, March 27, 2026 6:37 PM
> To: Michael Dege <michael.dege@renesas.com>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Andrew Lunn <andrew+netdev@lunn.ch>; David
> S. Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Paolo Abeni <pabeni@redhat.com>;
> netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [net-next PATCH v2 00/13] net: renesas: rswitch: R-Car S4 add VLAN aware switching
>
> On Fri, 27 Mar 2026 09:27:30 +0100 Michael Dege wrote:
> > Hello!
> >
> > The current R-Car S4 rswitch driver only supports basic HW offloading
> > for L2 switching/bridgeing. This patchset extends the driver with
> > support for VLAN aware switching.
> >
> > 1. For every port mode change from configuration to operation and
> > vice-versa you need to change to disabled mode first. The
> > functions rswitch_<port>_change_mode now take care of this.
> >
> > 2. In upcomming changes for adding vlan support struct net_device
> > will not be available in all cases, therefore use struct device
> > instead.
> >
> > 3. Fix typo in register define macro and remove duplicate macro.
> >
> > 4. Add register definitions needed fo vlan support.
> >
> > 5. Add exception path for packets with unknown destitination MAC
> > addresses.
> >
> > 6. Make the helper functions rswitch_reg_wait(),
> > rswitch_etha_change_mode() and rswitch_etha_change_mode()
> > available to the whole driver.
> >
> > 7. Add basic start-up time initialization needed to support VLANs.
> >
> > 8. Update ETHA and GWCA port HW initializations.
> >
> > 9. Clean up is_rdev() rswitch_device checking.
> >
> > 10. Provide struct rswitch_private to notifiers.
> >
> > 11. Add handler for FDB notifications to configure bridge MAC address
> > to GWCA registers and update static MAC table entry.
> >
> > 12. Add vlan support to L2 HW bridge.
>
> coccicheck reports:
>
> drivers/net/ethernet/renesas/rswitch_main.c:1590:11-66: duplicated argument to & or | @@ -182,0 +184,3
> @@
> drivers/net/ethernet/renesas/rswitch_l2.c:350:5-8: WARNING: Unsigned expression compared with zero:
> err < 0
> drivers/net/ethernet/renesas/rswitch_l2.c:380:5-8: WARNING: Unsigned expression compared with zero:
> err < 0
> drivers/net/ethernet/renesas/rswitch_l2.c:465:5-8: WARNING: Unsigned expression compared with zero:
> err < 0
Thank you very much for pointing these out to me.
Best regards,
Michael
>
> reminder: please do not post a new version of patches on netdev earlier than a full 24h after previous
> posting.
^ permalink raw reply
* [syzbot] Monthly hams report (Mar 2026)
From: syzbot @ 2026-03-31 8:06 UTC (permalink / raw)
To: linux-hams, linux-kernel, netdev, syzkaller-bugs
Hello hams maintainers/developers,
This is a 31-day syzbot report for the hams subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/hams
During the period, 1 new issues were detected and 1 were fixed.
In total, 16 issues are still open and 47 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 15241 Yes possible deadlock in nr_rt_device_down (3)
https://syzkaller.appspot.com/bug?extid=ccdfb85a561b973219c7
<2> 7582 Yes possible deadlock in nr_rt_ioctl (2)
https://syzkaller.appspot.com/bug?extid=14afda08dc3484d5db82
<3> 3507 Yes WARNING: ODEBUG bug in handle_softirqs
https://syzkaller.appspot.com/bug?extid=60db000b8468baeddbb1
<4> 1053 Yes possible deadlock in nr_remove_neigh (2)
https://syzkaller.appspot.com/bug?extid=8863ad36d31449b4dc17
<5> 672 Yes WARNING: ODEBUG bug in __run_timers (3)
https://syzkaller.appspot.com/bug?extid=7287222a6d88bdb559a7
<6> 169 Yes possible deadlock in nr_del_node (2)
https://syzkaller.appspot.com/bug?extid=6eb7834837cf6a8db75b
<7> 25 Yes WARNING: refcount bug in ax25_setsockopt
https://syzkaller.appspot.com/bug?extid=0ee4da32f91ae2a3f015
<8> 24 Yes KASAN: slab-use-after-free Read in nr_rt_ioctl
https://syzkaller.appspot.com/bug?extid=df52f4216bf7b4d768e7
<9> 16 No KASAN: slab-use-after-free Read in rose_t0timer_expiry
https://syzkaller.appspot.com/bug?extid=44cccec2c6a4501f6a45
<10> 12 Yes KASAN: slab-use-after-free Read in ax25_find_cb
https://syzkaller.appspot.com/bug?extid=caa052a0958a9146870d
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* [syzbot] Monthly netfilter report (Mar 2026)
From: syzbot @ 2026-03-31 8:07 UTC (permalink / raw)
To: fw, linux-kernel, netdev, netfilter-devel, pablo, syzkaller-bugs
Hello netfilter maintainers/developers,
This is a 31-day syzbot report for the netfilter subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/netfilter
During the period, 2 new issues were detected and 2 were fixed.
In total, 13 issues are still open and 196 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 4918 Yes INFO: rcu detected stall in worker_thread (9)
https://syzkaller.appspot.com/bug?extid=225bfad78b079744fd5e
<2> 692 Yes INFO: rcu detected stall in addrconf_rs_timer (6)
https://syzkaller.appspot.com/bug?extid=fecf8bd19c1f78edb255
<3> 325 Yes INFO: rcu detected stall in gc_worker (3)
https://syzkaller.appspot.com/bug?extid=eec403943a2a2455adaa
<4> 68 No INFO: task hung in nfnetlink_rcv_msg (5)
https://syzkaller.appspot.com/bug?extid=c4b20b80ee6a7a2f5012
<5> 11 Yes KMSAN: uninit-value in ip6table_mangle_hook (3)
https://syzkaller.appspot.com/bug?extid=6023ea32e206eef7920a
<6> 6 Yes WARNING in nf_ct_bridge_post
https://syzkaller.appspot.com/bug?extid=a8ba738fe2db6b4bb27f
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* [syzbot] Monthly wpan report (Mar 2026)
From: syzbot @ 2026-03-31 8:07 UTC (permalink / raw)
To: alex.aring, linux-kernel, linux-wpan, miquel.raynal, netdev,
stefan, syzkaller-bugs
Hello wpan maintainers/developers,
This is a 31-day syzbot report for the wpan subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/wpan
During the period, 0 new issues were detected and 0 were fixed.
In total, 5 issues are still open and 26 have already been fixed.
Some of the still happening issues:
Ref Crashes Repro Title
<1> 436 Yes KMSAN: uninit-value in ieee802154_hdr_push (2)
https://syzkaller.appspot.com/bug?extid=60a66d44892b66b56545
<2> 350 Yes WARNING in lowpan_xmit (2)
https://syzkaller.appspot.com/bug?extid=5b74e0e96f12e3728ec8
<3> 46 Yes KMSAN: kernel-infoleak in move_addr_to_user (7)
https://syzkaller.appspot.com/bug?extid=346474e3bf0b26bd3090
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
To disable reminders for individual bugs, reply with the following command:
#syz set <Ref> no-reminders
To change bug's subsystems, reply with:
#syz set <Ref> subsystems: new-subsystem
You may send multiple commands in a single email message.
^ permalink raw reply
* Re: [PATCH net-next] pppoe: update Kconfig URLs
From: Jaco Kroon @ 2026-03-31 8:08 UTC (permalink / raw)
To: Qingfang Deng
Cc: linux-ppp, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Eric Biggers, netdev, linux-kernel,
Paul Mackerras, Dianne Skoll, James Carlson
In-Reply-To: <20260331075438.290119-1-dqfext@gmail.com>
Hi,
On 2026/03/31 09:54, Qingfang Deng wrote:
> Hi,
>
> On Tue, 31 Mar 2026 08:21:40 +0200, Jaco Kroon wrote:
>> On 2026/03/31 05:33, Qingfang Deng wrote:
>>> --- a/drivers/net/ppp/Kconfig
>>> +++ b/drivers/net/ppp/Kconfig
>>> @@ -122,11 +122,10 @@ config PPPOE
>>> help
>>> Support for PPP over Ethernet.
>>>
>>> - This driver requires the latest version of pppd from the CVS
>>> - repository at cvs.samba.org. Alternatively, see the
>>> - RoaringPenguin package (<http://www.roaringpenguin.com/pppoe>)
>>> - which contains instruction on how to use this driver (under
>>> - the heading "Kernel mode PPPoE").
>>> + This driver requires the latest version of pppd at
>>> + <https://ppp.samba.org>.
>>> + Alternatively, see the out-of-tree RP-PPPoE plugin at
>>> + <https://dianne.skoll.ca/projects/rp-pppoe/>.
>> ppp now exclusively has the plugin code (originally from roaring penguin
>> I believe). Latest version is no longer relevant, that plugin has been
>> available since at least a few versions back already (at least a decade,
>> probably closer to two).
>>
>> That same code has recently been dropped from rp-pppoe, which now
>> primarily focusses on pppoe-server, and relies on the plugin now part of
>> ppp package itself. rp-pppoe is only required if you're running a
>> pppoe-server, and I don't think rp-pppoe at this stage will function
>> without ppp.
>>
>> Most people will never need rp-pppoe.
> Thanks for the information.
>
> I just checked pppd's changelog: version 2.4.2 or later has the PPPoE
> plugin.
>
> I can update the help message accordingly:
>
> To work in client mode, pppd version 2.4.2 or later is
> required. To work in server mode, the pppoe-server command
> from the RP-PPPoE package is also required, available at
> <https://dianne.skoll.ca/projects/rp-pppoe/>.
I like this. You have however dropped the ppp.samba.org link, just
re-add that I reckon.
Signed-off-by: Jaco Kroon <jaco@uls.co.za>
For what my sign-off is worth in this case :).
Kind regards,
Jaco
^ permalink raw reply
* Re: [PATCH net-next v2 13/13] net: renesas: rswitch: add vlan aware switching
From: Nicolai Buchwitz @ 2026-03-31 8:11 UTC (permalink / raw)
To: Michael Dege
Cc: kernel test robot, Yoshihiro Shimoda, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
oe-kbuild-all, netdev, linux-renesas-soc, linux-kernel
In-Reply-To: <TY4PR01MB142828994B921A75367AEC5368253A@TY4PR01MB14282.jpnprd01.prod.outlook.com>
On 31.3.2026 08:10, Michael Dege wrote:
> Hello,
>
> Who can kindly help me with this?
>
>> -----Original Message-----
>> From: kernel test robot <lkp@intel.com>
>> Sent: Sunday, March 29, 2026 10:37 PM
>> To: Michael Dege <michael.dege@renesas.com>; Yoshihiro Shimoda
>> <yoshihiro.shimoda.uh@renesas.com>;
>> Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller
>> <davem@davemloft.net>; Eric Dumazet
>> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
>> <pabeni@redhat.com>
>> Cc: oe-kbuild-all@lists.linux.dev; netdev@vger.kernel.org;
>> linux-renesas-soc@vger.kernel.org; linux-
>> kernel@vger.kernel.org; Michael Dege <michael.dege@renesas.com>
>> Subject: Re: [PATCH net-next v2 13/13] net: renesas: rswitch: add vlan
>> aware switching
>>
>> Hi Michael,
>>
>> kernel test robot noticed the following build errors:
>>
>> [auto build test ERROR on 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681]
>>
>> url: https://github.com/intel-lab-
>> lkp%2Flinux%2Fcommits%2FMichael-Dege%2Fnet-renesas-rswitch-improve-port-change-mode-
>> functions%2F20260329-
>> 154812&data=05%7C02%7Cmichael.dege%40renesas.com%7C27cab84d6f7640e15b4f08de8dd3108a%7C53d82571da1947e4
>> 9cb4625a166a4a2a%7C0%7C0%7C639104134822998103%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
>> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uP5U8NPFi2wo7VJDRGZ%2B
>> ubwH50bZDvNuapBP0t76lL0%3D&reserved=0
>> base: 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681
>> patch link:
>> https://lore.kernel.org/r/20260327-
>> rswitch_add_vlans-v2-13-
>> d7f4358ca57a%2540renesas.com&data=05%7C02%7Cmichael.dege%40renesas.com%7C27cab84d6f7640e15b4f08de8dd31
>> 08a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C639104134823016624%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
>> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=
>> 2QTz%2BFk8tDeHuE2Ac5ddl8tJ2mFSrm9l9mGnnLDsdW4%3D&reserved=0
>> patch subject: [PATCH net-next v2 13/13] net: renesas: rswitch: add
>> vlan aware switching
>> config: arm64-defconfig
>> (https://download.01.org/0day-
>> ci%2Farchive%2F20260330%2F202603300436.ryIgiB0z-
>> lkp%40intel.com%2Fconfig&data=05%7C02%7Cmichael.dege%40renesas.com%7C27cab84d6f7640e15b4f08de8dd3108a%
>> 7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C639104134823028947%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
>> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vhwu
>> KaGAF4bhfSTb1VhDnII4SXsKbZ0zEPRt8ma49aM%3D&reserved=0)
>> compiler: aarch64-linux-gcc (GCC) 15.2.0 reproduce (this is a W=1
>> build):
>> (https://download.01.org/0day-
>> ci%2Farchive%2F20260330%2F202603300436.ryIgiB0z-
>> lkp%40intel.com%2Freproduce&data=05%7C02%7Cmichael.dege%40renesas.com%7C27cab84d6f7640e15b4f08de8dd310
>> 8a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C639104134823040554%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1
>> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Y
>> TddyGPjtxfccjUPlLwizqOqUHOuiRxPxMqoNaHWW%2Bk%3D&reserved=0)
>>
>> If you fix the issue in a separate patch/commit (i.e. not just a new
>> version of the same
>> patch/commit), kindly add following tags
>> | Reported-by: kernel test robot <lkp@intel.com>
>> | Closes:
>> | https://lore/
>> |
>> .kernel.org%2Foe-kbuild-all%2F202603300436.ryIgiB0z-lkp%40intel.com%2F
>> |
>> &data=05%7C02%7Cmichael.dege%40renesas.com%7C27cab84d6f7640e15b4f08de8
>> |
>> dd3108a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C63910413482305219
>> |
>> 2%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIs
>> |
>> IlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4B
>> | 1hVOdPuyjze1HZCUi2v3gamNPgyeYcmx5NNzrDFjw%3D&reserved=0
>>
>> All errors (new ones prefixed by >>):
>>
>> aarch64-linux-ld: Unexpected GOT/PLT entries detected!
>> aarch64-linux-ld: Unexpected run-time procedure linkages detected!
>> aarch64-linux-ld: drivers/net/ethernet/renesas/rswitch_l2.o: in
>> function
>> `rswitch_port_obj_do_add_gwca':
>> >> drivers/net/ethernet/renesas/rswitch_l2.c:443:(.text+0x11e0): undefined reference to
>> `br_vlan_enabled'
>> aarch64-linux-ld: drivers/net/ethernet/renesas/rswitch_l2.o: in
>> function `rswitch_port_obj_do_add':
>> drivers/net/ethernet/renesas/rswitch_l2.c:412:(.text+0x135c):
>> undefined reference to
>> `br_vlan_enabled'
>> >> aarch64-linux-ld: drivers/net/ethernet/renesas/rswitch_l2.c:423:(.text+0x13bc): undefined reference
>> to `br_vlan_enabled'
>>
>>
>> vim +443 drivers/net/ethernet/renesas/rswitch_l2.c
>>
>> 402
>> 403 static int rswitch_port_obj_do_add(struct net_device
>> *ndev,
>> 404 struct
>> switchdev_obj_port_vlan *p_vlan)
>> 405 {
>> 406 struct rswitch_device *rdev = netdev_priv(ndev);
>> 407 struct rswitch_private *priv = rdev->priv;
>> 408 struct rswitch_etha *etha = rdev->etha;
>> 409 int err;
>> 410
>> 411 /* Set Rswitch VLAN mode */
>> 412 iowrite32(br_vlan_enabled(rdev->brdev) ?
>> FIELD_PREP(FWGC_SVM, C_TAG) : 0,
>> 413 priv->addr + FWGC);
>> 414
>> 415 err = rswitch_write_vlan_table(priv,
>> p_vlan->vid, etha->index);
>> 416 if (err < 0)
>> 417 return err;
>> 418
>> 419 /* If the default vlan for this port has been
>> set, don't overwrite it. */
>> 420 if (ioread32(etha->addr + EAVCC))
>> 421 return NOTIFY_DONE;
>> 422
>> > 423 if (br_vlan_enabled(rdev->brdev))
>> 424 rswitch_modify(priv->addr,
>> FWPC0(etha->index), 0, FWPC0_VLANSA |
>> FWPC0_VLANRU);
>> 425
>> 426 rswitch_modify(priv->addr,
>> FWPC2(AGENT_INDEX_GWCA),
>> 427 FIELD_PREP(FWPC2_LTWFW,
>> BIT(etha->index)),
>> 428 0);
>> 429
>> 430 return rswitch_port_set_vlan_tag(etha, p_vlan,
>> false);
>> 431 }
>> 432
>> 433 static int rswitch_port_obj_do_add_gwca(struct
>> net_device *ndev,
>> 434 struct
>> rswitch_private *priv,
>> 435 struct
>> switchdev_obj_port_vlan *p_vlan)
>> 436 {
>> 437 int err;
>> 438
>> 439 if (!(p_vlan->flags & BRIDGE_VLAN_INFO_BRENTRY))
>> 440 return NOTIFY_DONE;
>> 441
>> 442 /* Set Rswitch VLAN mode */
>> > 443 iowrite32(br_vlan_enabled(ndev) ?
>> FIELD_PREP(FWGC_SVM, C_TAG) : 0, priv->addr +
>> FWGC);
>> 444
>> 445 err = rswitch_write_vlan_table(priv,
>> p_vlan->vid, AGENT_INDEX_GWCA);
>> 446 if (err < 0)
>> 447 return err;
>> 448
>> 449 /* If the default vlan for this port has been
>> set, don't overwrite it. */
>> 450 if (ioread32(priv->addr + GWVCC))
>> 451 return NOTIFY_DONE;
>> 452
>> 453 return rswitch_gwca_set_vlan_tag(priv, p_vlan,
>> false);
>> 454 }
>> 455
>>
>
> The function br_vlan_enabled() is exported from br_vlan.c and the
> header file is if_bridge.h. Can anyone
> give me a hint what might be wrong?
Looking at the other switchdev drivers, I'd suspect that
`RENESAS_ETHER_SWITCH` is missing `depends on BRIDGE || BRIDGE=n`, which
guards br_vlan_enabled().
Nicolai
>
> Thank you and best regards,
>
> Michael
>
>> --
>> 0-DAY CI Kernel Test Service
>> https://github.com/intel/lkp-
>> tests%2Fwiki&data=05%7C02%7Cmichael.dege%40renesas.com%7C27cab84d6f7640e15b4f08de8dd3108a%7C53d82571da
>> 1947e49cb4625a166a4a2a%7C0%7C0%7C639104134823063970%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl
>> YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wG2VKo2Ln60Ld4KV
>> 8wHTcxRyskg0hzu0dZSVMg4v73g%3D&reserved=0
^ permalink raw reply
* Re: [RESEND PATCH] ice: access @pp through netmem_desc instead of page
From: Byungchul Park @ 2026-03-31 8:11 UTC (permalink / raw)
To: Tony Nguyen
Cc: netdev, kuba, linux-kernel, kernel_team, harry.yoo, david, willy,
toke, asml.silence, almasrymina, przemyslaw.kitszel,
andrew+netdev, davem, edumazet, pabeni, intel-wired-lan
In-Reply-To: <af90b7e6-de47-485d-9e1b-31612456ef9c@intel.com>
On Thu, Feb 26, 2026 at 10:13:14AM -0800, Tony Nguyen wrote:
> On 2/25/2026 5:08 PM, Byungchul Park wrote:
> > On Tue, Feb 24, 2026 at 02:35:46PM +0900, Byungchul Park wrote:
> > > To eliminate the use of struct page in page pool, the page pool users
> > > should use netmem descriptor and APIs instead.
> > >
> > > Make ice driver access @pp through netmem_desc instead of page.
> >
> > Hi Tony and Przemek,
> >
> > Is there something that I'm missing or something wrong with this? Your
> > feedback would be appreciated. Thanks!
>
> Hi Byungchul,
>
> Nothing wrong. I plan to apply it today.
Hi Tony,
Sorry bothering you but could you tell me where I can see the patch
ready in a tree, maybe yours? I failed to locate it.
This patch is very important for the project removing pp fields from
struct page to go ahead. Thanks in advance.
Byungchul
> Thanks,
> Tony
>
> > Byungchul
> >
> > > Signed-off-by: Byungchul Park <byungchul@sk.com>
> > > ---
> > > drivers/net/ethernet/intel/ice/ice_ethtool.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > > index c6bc29cfb8e6..c16e54dbe75b 100644
> > > --- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > > +++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
> > > @@ -1251,7 +1251,7 @@ static int ice_lbtest_receive_frames(struct ice_rx_ring *rx_ring)
> > > rx_buf = &rx_ring->rx_fqes[i];
> > > page = __netmem_to_page(rx_buf->netmem);
> > > received_buf = page_address(page) + rx_buf->offset +
> > > - page->pp->p.offset;
> > > + pp_page_to_nmdesc(page)->pp->p.offset;
> > >
> > > if (ice_lbtest_check_frame(received_buf))
> > > valid_frames++;
> > > --
> > > 2.17.1
^ permalink raw reply
* RE: [PATCH net-next v4 3/3] r8152: add helper functions for PHY OCP registers
From: Hayes Wang @ 2026-03-31 8:24 UTC (permalink / raw)
To: Chih Kai Hsu, Jakub Kicinski
Cc: davem@davemloft.net, netdev@vger.kernel.org, nic_swsd,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
edumazet@google.com, bjorn@mork.no, pabeni@redhat.com
In-Reply-To: <0fb2fd8f26334b578c299ee71958202c@realtek.com>
> -----Original Message-----
> From: Chih Kai Hsu <hsu.chih.kai@realtek.com>
> Sent: Tuesday, March 31, 2026 1:46 PM
> To: Jakub Kicinski <kuba@kernel.org>
> Cc: davem@davemloft.net; netdev@vger.kernel.org; nic_swsd
> <nic_swsd@realtek.com>; linux-kernel@vger.kernel.org;
> linux-usb@vger.kernel.org; edumazet@google.com; bjorn@mork.no;
> pabeni@redhat.com
> Subject: RE: [PATCH net-next v4 3/3] r8152: add helper functions for PHY OCP
> registers
>
> On 31/03/26 10:02 am, Jakub Kicinski wrote:
> >
> > > diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index
> > > 32a4e8d423115..8747c55e0a484 100644
> > > --- a/drivers/net/usb/r8152.c
> > > +++ b/drivers/net/usb/r8152.c
> > [ ... ]
> > > +static void sram_write_w0w1(struct r8152 *tp, u16 addr, u16 clear,
> > > +u16 set) {
> > > + u16 data;
> > > +
> > > + data = sram_read(tp, addr);
> > > + data = (data & ~clear) | set;
> > > + ocp_reg_write(tp, OCP_SRAM_DATA, data);
> >
> > AI flags:
> >
> > Does writing directly to OCP_SRAM_DATA here actually write to the
> > intended
> > address?
> Yes, this actually writes to the intended address.
>
> >
> > Because hardware indirect SRAM access ports typically auto-increment
> their
> > internal address pointer upon access, the sram_read() call will advance
> the
> > pointer. By writing directly to OCP_SRAM_DATA instead of using
> > sram_write(tp, addr, data) to re-establish the address, the updated value
> > would be written to the next address (addr + 1) rather than the original
> addr.
> >
> > Could this corrupt the PHY configuration memory across the
> > initialization paths
> > that now use sram_clr_bits() and sram_set_bits()?
> >
> > Can you confirm if this is legit? Not sure whether this device /
> > register auto-increments or where AI got it from.
> The address pointer, OCP_SRAM_ADDR, is not auto-incremented after
> sram_read(tp, addr).
> However, the address pointer is incremented automatically after
> ocp_reg_write(tp, OCP_SRAM_DATA, data).
That's strange - I didn't receive the previous email from Jakub Kicinski.
Also, the answer above is correct.
Best Regards,
Hayes
^ permalink raw reply
* RE: [PATCH net-next v2 13/13] net: renesas: rswitch: add vlan aware switching
From: Michael Dege @ 2026-03-31 8:32 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: kernel test robot, Yoshihiro Shimoda, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
oe-kbuild-all@lists.linux.dev, netdev@vger.kernel.org,
linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <b52623fe930b5c398f21d97f7069274a@tipi-net.de>
Hello Nicolai,
> -----Original Message-----
> From: Nicolai Buchwitz <nb@tipi-net.de>
> Sent: Tuesday, March 31, 2026 10:11 AM
> To: Michael Dege <michael.dege@renesas.com>
> Cc: kernel test robot <lkp@intel.com>; Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>; Andrew
> Lunn <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; oe-kbuild-
> all@lists.linux.dev; netdev@vger.kernel.org; linux-renesas-soc@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [PATCH net-next v2 13/13] net: renesas: rswitch: add vlan aware switching
>
> [You don't often get email from nb@tipi-net.de. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
>
> On 31.3.2026 08:10, Michael Dege wrote:
> > Hello,
> >
> > Who can kindly help me with this?
> >
> >> -----Original Message-----
> >> From: kernel test robot <lkp@intel.com>
> >> Sent: Sunday, March 29, 2026 10:37 PM
> >> To: Michael Dege <michael.dege@renesas.com>; Yoshihiro Shimoda
> >> <yoshihiro.shimoda.uh@renesas.com>;
> >> Andrew Lunn <andrew+netdev@lunn.ch>; David S. Miller
> >> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> >> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>
> >> Cc: oe-kbuild-all@lists.linux.dev; netdev@vger.kernel.org;
> >> linux-renesas-soc@vger.kernel.org; linux- kernel@vger.kernel.org;
> >> Michael Dege <michael.dege@renesas.com>
> >> Subject: Re: [PATCH net-next v2 13/13] net: renesas: rswitch: add
> >> vlan aware switching
> >>
> >> Hi Michael,
> >>
> >> kernel test robot noticed the following build errors:
> >>
> >> [auto build test ERROR on 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681]
> >>
> >> url: https://github.com/intel-lab-
> &data=05%7C02%7Cmichael.dege%40renesas.com%7Cfd3cfc20b42f44b7452608de8efd1ba2%7C53d82571da1947e49cb462
> 5a166a4a2a%7C0%7C0%7C639105414993315978%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD
> AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=WF5AVcAPSM1aIXYlaRwHrpyy8ES2
> 6RVDjv5bs20HHbc%3D&reserved=0
> >> lkp%2Flinux%2Fcommits%2FMichael-Dege%2Fnet-renesas-rswitch-improve-po
> >> rt-change-mode-
> >> functions%2F20260329-
> >> 154812&data=05%7C02%7Cmichael.dege%40renesas.com%7C27cab84d6f7640e15b
> >> 4f08de8dd3108a%7C53d82571da1947e4
> >> 9cb4625a166a4a2a%7C0%7C0%7C639104134822998103%7CUnknown%7CTWFpbGZsb3d
> >> 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIw
> >> LjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7
> >> C%7C&sdata=uP5U8NPFi2wo7VJDRGZ%2B
> >> ubwH50bZDvNuapBP0t76lL0%3D&reserved=0
> >> base: 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681
> >> patch link:
> >> https://lor/
> >> e.kernel.org%2Fr%2F20260327-&data=05%7C02%7Cmichael.dege%40renesas.co
> >> m%7Cfd3cfc20b42f44b7452608de8efd1ba2%7C53d82571da1947e49cb4625a166a4a
> >> 2a%7C0%7C0%7C639105414993365890%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hc
> >> GkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj
> >> oyfQ%3D%3D%7C0%7C%7C%7C&sdata=pJlcsWcDiTvQNvNLB5FDg7JntAXrA3FXqXLGUGa
> >> 7igU%3D&reserved=0
> >> rswitch_add_vlans-v2-13-
> >> d7f4358ca57a%2540renesas.com&data=05%7C02%7Cmichael.dege%40renesas.co
> >> m%7C27cab84d6f7640e15b4f08de8dd31
> >> 08a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C639104134823016624%7
> >> CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU
> >> 1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> >> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=
> >> 2QTz%2BFk8tDeHuE2Ac5ddl8tJ2mFSrm9l9mGnnLDsdW4%3D&reserved=0
> >> patch subject: [PATCH net-next v2 13/13] net: renesas: rswitch: add
> >> vlan aware switching
> >> config: arm64-defconfig
> >> (https://do/
> >> wnload.01.org%2F0day-&data=05%7C02%7Cmichael.dege%40renesas.com%7Cfd3
> >> cfc20b42f44b7452608de8efd1ba2%7C53d82571da1947e49cb4625a166a4a2a%7C0%
> >> 7C0%7C639105414993392563%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> >> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
> >> %3D%7C0%7C%7C%7C&sdata=%2Fy7UsHBCbBPCJ41ZF2vP9GN72sLQ9EPi4LqDqo%2BTY%
> >> 2B8%3D&reserved=0
> >> ci%2Farchive%2F20260330%2F202603300436.ryIgiB0z-
> >> lkp%40intel.com%2Fconfig&data=05%7C02%7Cmichael.dege%40renesas.com%7C
> >> 27cab84d6f7640e15b4f08de8dd3108a%
> >> 7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C639104134823028947%7CUnk
> >> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcG
> >> kiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo
> >> yfQ%3D%3D%7C0%7C%7C%7C&sdata=vhwu
> >> KaGAF4bhfSTb1VhDnII4SXsKbZ0zEPRt8ma49aM%3D&reserved=0)
> >> compiler: aarch64-linux-gcc (GCC) 15.2.0 reproduce (this is a W=1
> >> build):
> >> (https://do/
> >> wnload.01.org%2F0day-&data=05%7C02%7Cmichael.dege%40renesas.com%7Cfd3
> >> cfc20b42f44b7452608de8efd1ba2%7C53d82571da1947e49cb4625a166a4a2a%7C0%
> >> 7C0%7C639105414993417213%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> >> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D
> >> %3D%7C0%7C%7C%7C&sdata=Zl1LMDlreP06%2B7A3qL6tVNFStkTVmyTXO465fM76wlI%
> >> 3D&reserved=0
> >> ci%2Farchive%2F20260330%2F202603300436.ryIgiB0z-
> >> lkp%40intel.com%2Freproduce&data=05%7C02%7Cmichael.dege%40renesas.com
> >> %7C27cab84d6f7640e15b4f08de8dd310
> >> 8a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C639104134823040554%7C
> >> Unknown%7CTWFpbGZsb3d8eyJFbXB0eU1
> >> hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldU
> >> IjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Y
> >> TddyGPjtxfccjUPlLwizqOqUHOuiRxPxMqoNaHWW%2Bk%3D&reserved=0)
> >>
> >> If you fix the issue in a separate patch/commit (i.e. not just a new
> >> version of the same patch/commit), kindly add following tags
> >> | Reported-by: kernel test robot <lkp@intel.com>
> >> | Closes:
> >> | https://lore/
> >> |
> >> .kernel.org%2Foe-kbuild-all%2F202603300436.ryIgiB0z-lkp%40intel.com%2
> >> F
> >> |
> >> &data=05%7C02%7Cmichael.dege%40renesas.com%7C27cab84d6f7640e15b4f08de
> >> 8
> >> |
> >> dd3108a%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C6391041348230521
> >> 9
> >> |
> >> 2%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCI
> >> s
> >> |
> >> IlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=4
> >> B
> >> | 1hVOdPuyjze1HZCUi2v3gamNPgyeYcmx5NNzrDFjw%3D&reserved=0
> >>
> >> All errors (new ones prefixed by >>):
> >>
> >> aarch64-linux-ld: Unexpected GOT/PLT entries detected!
> >> aarch64-linux-ld: Unexpected run-time procedure linkages detected!
> >> aarch64-linux-ld: drivers/net/ethernet/renesas/rswitch_l2.o: in
> >> function
> >> `rswitch_port_obj_do_add_gwca':
> >> >> drivers/net/ethernet/renesas/rswitch_l2.c:443:(.text+0x11e0):
> >> >> undefined reference to
> >> `br_vlan_enabled'
> >> aarch64-linux-ld: drivers/net/ethernet/renesas/rswitch_l2.o: in
> >> function `rswitch_port_obj_do_add':
> >> drivers/net/ethernet/renesas/rswitch_l2.c:412:(.text+0x135c):
> >> undefined reference to
> >> `br_vlan_enabled'
> >> >> aarch64-linux-ld:
> >> >> drivers/net/ethernet/renesas/rswitch_l2.c:423:(.text+0x13bc):
> >> >> undefined reference
> >> to `br_vlan_enabled'
> >>
> >>
> >> vim +443 drivers/net/ethernet/renesas/rswitch_l2.c
> >>
> >> 402
> >> 403 static int rswitch_port_obj_do_add(struct net_device
> >> *ndev,
> >> 404 struct
> >> switchdev_obj_port_vlan *p_vlan)
> >> 405 {
> >> 406 struct rswitch_device *rdev = netdev_priv(ndev);
> >> 407 struct rswitch_private *priv = rdev->priv;
> >> 408 struct rswitch_etha *etha = rdev->etha;
> >> 409 int err;
> >> 410
> >> 411 /* Set Rswitch VLAN mode */
> >> 412 iowrite32(br_vlan_enabled(rdev->brdev) ?
> >> FIELD_PREP(FWGC_SVM, C_TAG) : 0,
> >> 413 priv->addr + FWGC);
> >> 414
> >> 415 err = rswitch_write_vlan_table(priv,
> >> p_vlan->vid, etha->index);
> >> 416 if (err < 0)
> >> 417 return err;
> >> 418
> >> 419 /* If the default vlan for this port has been
> >> set, don't overwrite it. */
> >> 420 if (ioread32(etha->addr + EAVCC))
> >> 421 return NOTIFY_DONE;
> >> 422
> >> > 423 if (br_vlan_enabled(rdev->brdev))
> >> 424 rswitch_modify(priv->addr,
> >> FWPC0(etha->index), 0, FWPC0_VLANSA | FWPC0_VLANRU);
> >> 425
> >> 426 rswitch_modify(priv->addr,
> >> FWPC2(AGENT_INDEX_GWCA),
> >> 427 FIELD_PREP(FWPC2_LTWFW,
> >> BIT(etha->index)),
> >> 428 0);
> >> 429
> >> 430 return rswitch_port_set_vlan_tag(etha, p_vlan,
> >> false);
> >> 431 }
> >> 432
> >> 433 static int rswitch_port_obj_do_add_gwca(struct
> >> net_device *ndev,
> >> 434 struct
> >> rswitch_private *priv,
> >> 435 struct
> >> switchdev_obj_port_vlan *p_vlan)
> >> 436 {
> >> 437 int err;
> >> 438
> >> 439 if (!(p_vlan->flags & BRIDGE_VLAN_INFO_BRENTRY))
> >> 440 return NOTIFY_DONE;
> >> 441
> >> 442 /* Set Rswitch VLAN mode */
> >> > 443 iowrite32(br_vlan_enabled(ndev) ?
> >> FIELD_PREP(FWGC_SVM, C_TAG) : 0, priv->addr + FWGC);
> >> 444
> >> 445 err = rswitch_write_vlan_table(priv,
> >> p_vlan->vid, AGENT_INDEX_GWCA);
> >> 446 if (err < 0)
> >> 447 return err;
> >> 448
> >> 449 /* If the default vlan for this port has been
> >> set, don't overwrite it. */
> >> 450 if (ioread32(priv->addr + GWVCC))
> >> 451 return NOTIFY_DONE;
> >> 452
> >> 453 return rswitch_gwca_set_vlan_tag(priv, p_vlan,
> >> false);
> >> 454 }
> >> 455
> >>
> >
> > The function br_vlan_enabled() is exported from br_vlan.c and the
> > header file is if_bridge.h. Can anyone give me a hint what might be
> > wrong?
>
> Looking at the other switchdev drivers, I'd suspect that `RENESAS_ETHER_SWITCH` is missing `depends on
> BRIDGE || BRIDGE=n`, which guards br_vlan_enabled().
>
> Nicolai
>
Thank you! That totally make sense.
Best regards,
Michael
> >
> > Thank you and best regards,
> >
> > Michael
> >
> >> --
> >> 0-DAY CI Kernel Test Service
> >> https://git/
> >> hub.com%2Fintel%2Flkp-&data=05%7C02%7Cmichael.dege%40renesas.com%7Cfd
> >> 3cfc20b42f44b7452608de8efd1ba2%7C53d82571da1947e49cb4625a166a4a2a%7C0
> >> %7C0%7C639105414993443101%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR
> >> ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3
> >> D%3D%7C0%7C%7C%7C&sdata=cUW%2B21BNNUlQA2fJLTBIDnQqyEMOztUdkUoC2bkmIvQ
> >> %3D&reserved=0
> >> tests%2Fwiki&data=05%7C02%7Cmichael.dege%40renesas.com%7C27cab84d6f76
> >> 40e15b4f08de8dd3108a%7C53d82571da
> >> 1947e49cb4625a166a4a2a%7C0%7C0%7C639104134823063970%7CUnknown%7CTWFpb
> >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl
> >> YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C
> >> 0%7C%7C%7C&sdata=wG2VKo2Ln60Ld4KV
> >> 8wHTcxRyskg0hzu0dZSVMg4v73g%3D&reserved=0
^ permalink raw reply
* [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown
From: Ren Wei @ 2026-03-31 8:33 UTC (permalink / raw)
To: security, netdev
Cc: davem, dsahern, edumazet, kuba, pabeni, horms, afaerber, mani,
yoshfuji, yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z,
zcliangcn, n05ec
In-Reply-To: <cover.1774855883.git.zcliangcn@gmail.com>
From: Zhengchuan Liang <zcliangcn@gmail.com>
`ip6fl_seq_show()` walks the global flowlabel hash under the seq-file
RCU read-side lock and prints `fl->opt->opt_nflen` when an option block
is present.
Exclusive flowlabels currently free `fl->opt` as soon as `fl->users`
drops to zero in `fl_release()`. However, the surrounding
`struct ip6_flowlabel` remains visible in the global hash table until
later garbage collection removes it and `fl_free_rcu()` finally tears it
down.
A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that
early `kfree()` and dereference freed option state, triggering a crash
in `ip6fl_seq_show()`.
Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches
the lifetime already required for the enclosing flowlabel while readers
can still reach it under RCU.
Fixes: d3aedd5ebd4b ("ipv6 flowlabel: Convert hash list to RCU.")
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: Ren Wei <enjou1224z@gmail.com>
Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
net/ipv6/ip6_flowlabel.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 7c12bf75beedf..c92f98c6f6ecc 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -133,11 +133,6 @@ static void fl_release(struct ip6_flowlabel *fl)
if (time_after(ttd, fl->expires))
fl->expires = ttd;
ttd = fl->expires;
- if (fl->opt && fl->share == IPV6_FL_S_EXCL) {
- struct ipv6_txoptions *opt = fl->opt;
- fl->opt = NULL;
- kfree(opt);
- }
if (!timer_pending(&ip6_fl_gc_timer) ||
time_after(ip6_fl_gc_timer.expires, ttd))
mod_timer(&ip6_fl_gc_timer, ttd);
--
2.43.0
^ permalink raw reply related
* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Leon Romanovsky @ 2026-03-31 8:37 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: <acW2BwQKaUbS3eL9@kbusch-mbp>
On Thu, Mar 26, 2026 at 04:41:11PM -0600, Keith Busch wrote:
> On Wed, Mar 25, 2026 at 10:25:34AM +0200, Leon Romanovsky wrote:
> > On Tue, Mar 24, 2026 at 04:46:02PM -0700, Zhiping Zhang wrote:
> > > struct vfio_device_feature_dma_buf {
> > > __u32 region_index;
> > > __u32 open_flags;
> > > - __u32 flags;
> > > - __u32 nr_ranges;
> > > + __u32 flags;
> > > +#define VFIO_DMABUF_FL_TPH (1U << 0) /* TPH info is present */
> > > +#define VFIO_DMABUF_TPH_PH_SHIFT 1 /* bits 1-2: PH (2-bit) */
> > > +#define VFIO_DMABUF_TPH_PH_MASK 0x6U
> > > +#define VFIO_DMABUF_TPH_ST_SHIFT 16 /* bits 16-31: steering tag */
> > > +#define VFIO_DMABUF_TPH_ST_MASK 0xffff0000U
> >
> > This extension of flags is basically kills future extension of this
> > struct for anything that includes TPH.
> >
> > Add new
> > enum vfio_device_feature_dma_buf_flags {
> > VFIO_DMABUF_FL_TPH = 1 << 0
> > }
> >
> > > + __u32 nr_ranges;
> >
> > add your "__u16 steering_tag" and "__u8 ph" fields here.
>
> You're suggesting that Ziping append the new fields to the end of this
> struct? I don't think we can modify the layout of a uapi.
He needs to add before flex array. This struct is submitted by the user
and kernel can easily calculate the position of that array.
Something like this:
diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
index b1d658b8f7b51..d78d915992232 100644
--- a/drivers/vfio/pci/vfio_pci_dmabuf.c
+++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
@@ -237,7 +237,11 @@ int vfio_pci_core_feature_dma_buf(struct vfio_pci_core_device *vdev, u32 flags,
if (get_dma_buf.region_index >= VFIO_PCI_ROM_REGION_INDEX)
return -ENODEV;
- dma_ranges = memdup_array_user(&arg->dma_ranges, get_dma_buf.nr_ranges,
+ if (!tph_supplied)
+ dma_ranges = memdup_array_user(old_dma_ranges_pos, get_dma_buf.nr_ranges,
+ sizeof(*dma_ranges));
+ else
+ dma_ranges = memdup_array_user(&arg->dma_ranges, get_dma_buf.nr_ranges,
sizeof(*dma_ranges));
if (IS_ERR(dma_ranges))
return PTR_ERR(dma_ranges);
~
Thanks
>
> If we can't carve the space for this out of the existing unused flags
> field, I think we'd have to introduce a new vfio device feature that
> basically copies VFIO_DEVICE_FEATURE_DMA_BUF with the extra hints
> fields.
>
> > > struct vfio_region_dma_range dma_ranges[] __counted_by(nr_ranges);
> > > };
^ permalink raw reply related
* Re: [RFC v2 1/2] vfio: add callback to get tph info for dmabuf
From: Leon Romanovsky @ 2026-03-31 8:39 UTC (permalink / raw)
To: Zhiping Zhang
Cc: Keith Busch, Jason Gunthorpe, Bjorn Helgaas, linux-rdma,
linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas,
Bjorn Helgaas
In-Reply-To: <CAH3zFs1nbAKpYxwzMcwpC_Sdy+3tE0n0wUzxJ411gV-q1O++qQ@mail.gmail.com>
On Thu, Mar 26, 2026 at 03:55:44PM -0700, Zhiping Zhang wrote:
> On Thu, Mar 26, 2026 at 3:41 PM Keith Busch <kbusch@kernel.org> wrote:
> >
> > >
> > On Wed, Mar 25, 2026 at 10:25:34AM +0200, Leon Romanovsky wrote:
> > > On Tue, Mar 24, 2026 at 04:46:02PM -0700, Zhiping Zhang wrote:
> > > > struct vfio_device_feature_dma_buf {
> > > > __u32 region_index;
> > > > __u32 open_flags;
> > > > - __u32 flags;
> > > > - __u32 nr_ranges;
> > > > + __u32 flags;
> > > > +#define VFIO_DMABUF_FL_TPH (1U << 0) /* TPH info is present */
> > > > +#define VFIO_DMABUF_TPH_PH_SHIFT 1 /* bits 1-2: PH (2-bit) */
> > > > +#define VFIO_DMABUF_TPH_PH_MASK 0x6U
> > > > +#define VFIO_DMABUF_TPH_ST_SHIFT 16 /* bits 16-31: steering tag */
> > > > +#define VFIO_DMABUF_TPH_ST_MASK 0xffff0000U
> > >
> > > This extension of flags is basically kills future extension of this
> > > struct for anything that includes TPH.
> > >
> > > Add new
> > > enum vfio_device_feature_dma_buf_flags {
> > > VFIO_DMABUF_FL_TPH = 1 << 0
> > > }
>
> yes we can do that.
>
> > >
> > > > + __u32 nr_ranges;
> > >
> > > add your "__u16 steering_tag" and "__u8 ph" fields here.
> >
> That is what I did in V1, Leon.
Not really, you did only half of the work. You didn't introduce new flag
and didn't calculate "old dma range" position.
Thanks
^ permalink raw reply
* Re: [PATCH net-next] pppoe: update Kconfig URLs
From: Qingfang Deng @ 2026-03-31 8:49 UTC (permalink / raw)
To: Jaco Kroon
Cc: linux-ppp, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Eric Biggers, netdev, linux-kernel,
Paul Mackerras, Dianne Skoll, James Carlson
In-Reply-To: <f37fca7f-710c-4f7a-a7c5-9d8cc129bf21@uls.co.za>
Hi,
On Tue, 31 Mar 2026 10:08:46 +0200, Jaco Kroon wrote:
>
> I like this. You have however dropped the ppp.samba.org link, just
> re-add that I reckon.
I think this link belongs in the PPP section:
diff --git a/drivers/net/ppp/Kconfig b/drivers/net/ppp/Kconfig
index f57fba84fe55..cf927bdc288f 100644
--- a/drivers/net/ppp/Kconfig
+++ b/drivers/net/ppp/Kconfig
@@ -13,10 +13,9 @@ config PPP
otherwise you can't use it; most Internet access providers these
days support PPP rather than SLIP.
- To use PPP, you need an additional program called pppd as described
- in the PPP-HOWTO, available at
- <http://www.tldp.org/docs.html#howto>. Make sure that you have
- the version of pppd recommended in <file:Documentation/Changes>.
+ To use PPP, you need an additional program called pppd, available at
+ <https://ppp.samba.org>. Make sure that you have the version of pppd
+ recommended in <file:Documentation/Changes>.
The PPP option enlarges your kernel by about 16 KB.
There are actually two versions of PPP: the traditional PPP for
Your thoughts?
^ permalink raw reply related
* Re: [PATCH net-next v4 0/3] r8152: add helper functions for PLA/USB/PHY OCP registers
From: patchwork-bot+netdevbpf @ 2026-03-31 8:50 UTC (permalink / raw)
To: Chih Kai Hsu
Cc: kuba, davem, netdev, nic_swsd, linux-kernel, linux-usb, edumazet,
bjorn, pabeni
In-Reply-To: <20260326073925.32976-453-nic_swsd@realtek.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 26 Mar 2026 15:39:22 +0800 you wrote:
> v4:
> - Add a new patch for original #1. We need to fix a typo first before
> original #1 patch.
>
> - For patch #2, replace redundant ocp_word_set_bits() with ocp_word_w0w1().
>
> v3:
> - For patch #1, fix the issue identified by the AI review.
> In v2, ocp_byte_set_bits() was used to update the USB_LPM_CTRL register.
> However, since its function only perform a bitwise OR operaion, it fails
> to clear the old bits when updating a multi-bit field like LPM_TIMER.
> Therefore, use ocp_write_byte() to maintain the original direct-write
> semantics.
>
> [...]
Here is the summary with links:
- [net-next,v4,1/3] r8152: fix incorrect register write to USB_UPHY_XTAL
https://git.kernel.org/netdev/net-next/c/48afd5124fd6
- [net-next,v4,2/3] r8152: add helper functions for PLA/USB OCP registers
https://git.kernel.org/netdev/net-next/c/d16133f177fe
- [net-next,v4,3/3] r8152: add helper functions for PHY OCP registers
https://git.kernel.org/netdev/net-next/c/7db154aa58e1
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH RESEND nf 1/1] net/sched: cls_flower: avoid stale mask references after delete
From: Yang Yang @ 2026-03-31 8:51 UTC (permalink / raw)
To: jhs
Cc: xiyou.wangcong, jiri, davem, edumazet, kuba, tanyuan98,
z1652074432, kanolyc, n05ec, pabeni, horms, sbrivio, vladbu,
netdev, yifanwucs, tomapufckgml, bird
In-Reply-To: <cover.1773559972.git.z1652074432@gmail.com>
From: Yuhang Zheng <z1652074432@gmail.com>
cls_flower keeps filter and mask state separately. After a filter is
removed or replaced, some paths can still need the mask data associated
with that filter.
Cache the mask key and dissector in struct cls_fl_filter when the mask
is assigned, and use the cached copies in dump and offload paths. This
avoids depending on the external mask object's lifetime after delete or
replace.
Fixes: 061775583e35 ("net: sched: flower: introduce reference counting for filters")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Signed-off-by: Yuan Tan <tanyuan98@outlook.com>
Signed-off-by: Xin Liu <bird@lzu.edu.cn>
Signed-off-by: Yucheng Lu <kanolyc@gmail.com>
Signed-off-by: Yuhang Zheng <z1652074432@gmail.com>
---
This email was not CCed to the public mailing list previously, so I am
resending it with the mailing list included. Sorry for the inconvenience.
net/sched/cls_flower.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 099ff6a3e1f5..c1f10b4ec748 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -124,8 +124,10 @@ struct cls_fl_head {
struct cls_fl_filter {
struct fl_flow_mask *mask;
+ struct flow_dissector mask_dissector;
struct rhash_head ht_node;
struct fl_flow_key mkey;
+ struct fl_flow_key mask_key;
struct tcf_exts exts;
struct tcf_result res;
struct fl_flow_key key;
@@ -445,6 +447,12 @@ static void fl_destroy_filter_work(struct work_struct *work)
__fl_destroy_filter(f);
}
+static void fl_filter_copy_mask(struct cls_fl_filter *f)
+{
+ f->mask_key = f->mask->key;
+ f->mask_dissector = f->mask->dissector;
+}
+
static void fl_hw_destroy_filter(struct tcf_proto *tp, struct cls_fl_filter *f,
bool rtnl_held, struct netlink_ext_ack *extack)
{
@@ -476,8 +484,8 @@ static int fl_hw_replace_filter(struct tcf_proto *tp,
tc_cls_common_offload_init(&cls_flower.common, tp, f->flags, extack);
cls_flower.command = FLOW_CLS_REPLACE;
cls_flower.cookie = (unsigned long) f;
- cls_flower.rule->match.dissector = &f->mask->dissector;
- cls_flower.rule->match.mask = &f->mask->key;
+ cls_flower.rule->match.dissector = &f->mask_dissector;
+ cls_flower.rule->match.mask = &f->mask_key;
cls_flower.rule->match.key = &f->mkey;
cls_flower.classid = f->res.classid;
@@ -2489,6 +2497,7 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
err = fl_check_assign_mask(head, fnew, fold, mask);
if (err)
goto unbind_filter;
+ fl_filter_copy_mask(fnew);
err = fl_ht_insert_unique(fnew, fold, &in_ht);
if (err)
@@ -2705,8 +2714,8 @@ static int fl_reoffload(struct tcf_proto *tp, bool add, flow_setup_cb_t *cb,
cls_flower.command = add ?
FLOW_CLS_REPLACE : FLOW_CLS_DESTROY;
cls_flower.cookie = (unsigned long)f;
- cls_flower.rule->match.dissector = &f->mask->dissector;
- cls_flower.rule->match.mask = &f->mask->key;
+ cls_flower.rule->match.dissector = &f->mask_dissector;
+ cls_flower.rule->match.mask = &f->mask_key;
cls_flower.rule->match.key = &f->mkey;
err = tc_setup_offload_action(&cls_flower.rule->action, &f->exts,
@@ -3709,7 +3718,7 @@ static int fl_dump(struct net *net, struct tcf_proto *tp, void *fh,
goto nla_put_failure_locked;
key = &f->key;
- mask = &f->mask->key;
+ mask = &f->mask_key;
skip_hw = tc_skip_hw(f->flags);
if (fl_dump_key(skb, net, key, mask))
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown
From: Eric Dumazet @ 2026-03-31 8:52 UTC (permalink / raw)
To: Ren Wei
Cc: security, netdev, davem, dsahern, kuba, pabeni, horms, afaerber,
mani, yoshfuji, yifanwucs, tomapufckgml, yuantan098, bird,
enjou1224z, zcliangcn
In-Reply-To: <07351f0ec47bcee289576f39f9354f4a64add6e4.1774855883.git.zcliangcn@gmail.com>
On Tue, Mar 31, 2026 at 1:34 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
>
> From: Zhengchuan Liang <zcliangcn@gmail.com>
>
> `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file
> RCU read-side lock and prints `fl->opt->opt_nflen` when an option block
> is present.
Some points :
Please do not CC security@ if you submit a public patch, there is
absolutely no reason for it.
Please do not resend the same version within 24 hours; this creates noise.
Your patch wasn't lost; we have many patch reviews and similar bugs to address.
Thank you.
^ permalink raw reply
* Re: [PATCH net v3] net: bonding: fix use-after-free in bond_xmit_broadcast()
From: Paolo Abeni @ 2026-03-31 8:53 UTC (permalink / raw)
To: Xiang Mei, security
Cc: netdev, jv, andrew+netdev, davem, edumazet, kuba, bestswngs
In-Reply-To: <20260326075553.3960562-1-xmei5@asu.edu>
On 3/26/26 8:55 AM, Xiang Mei wrote:
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 33f414d03ab91..a5484d11553d1 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -5326,7 +5326,7 @@ static netdev_tx_t bond_xmit_broadcast(struct sk_buff *skb,
> if (!(bond_slave_is_up(slave) && slave->link == BOND_LINK_UP))
> continue;
>
> - if (bond_is_last_slave(bond, slave)) {
> + if (i + 1 == slaves_count) {
> skb2 = skb;
> skb_used = true;
> } else {
The above removes the last usage of the bond_is_last_slave() helper,
which in turn could/should be removed, too. To avoid delaying this patch
too much I'm applying it as is, but please follow-up on net-next
removing the stray helper after this patch will land there (i.e. after
Thursday).
Thanks,
Paolo
^ permalink raw reply
* Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown
From: Eric Dumazet @ 2026-03-31 8:56 UTC (permalink / raw)
To: Ren Wei
Cc: security, davem, dsahern, kuba, pabeni, horms, afaerber, mani,
yoshfuji, yifanwucs, tomapufckgml, yuantan098, bird, enjou1224z,
zcliangcn, netdev, linux-arm-kernel, linux-actions, linux-kernel
In-Reply-To: <07351f0ec47bcee289576f39f9354f4a64add6e4.1774855883.git.zcliangcn@gmail.com>
On Mon, Mar 30, 2026 at 1:52 AM Ren Wei <n05ec@lzu.edu.cn> wrote:
>
> From: Zhengchuan Liang <zcliangcn@gmail.com>
>
> `ip6fl_seq_show()` walks the global flowlabel hash under the seq-file
> RCU read-side lock and prints `fl->opt->opt_nflen` when an option block
> is present.
>
> Exclusive flowlabels currently free `fl->opt` as soon as `fl->users`
> drops to zero in `fl_release()`. However, the surrounding
> `struct ip6_flowlabel` remains visible in the global hash table until
> later garbage collection removes it and `fl_free_rcu()` finally tears it
> down.
>
> A concurrent `/proc/net/ip6_flowlabel` reader can therefore race that
> early `kfree()` and dereference freed option state, triggering a crash
> in `ip6fl_seq_show()`.
>
> Fix this by keeping `fl->opt` alive until `fl_free_rcu()`. That matches
> the lifetime already required for the enclosing flowlabel while readers
> can still reach it under RCU.
>
> Fixes: d3aedd5ebd4b ("ipv6 flowlabel: Convert hash list to RCU.")
> 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: Ren Wei <enjou1224z@gmail.com>
> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com>
> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
Quite a long and confusing list of tags, and a long CC list ...
Please trim this next time you submit a networking patch.
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net v3] net: bonding: fix use-after-free in bond_xmit_broadcast()
From: patchwork-bot+netdevbpf @ 2026-03-31 9:00 UTC (permalink / raw)
To: Xiang Mei
Cc: security, netdev, pabeni, jv, andrew+netdev, davem, edumazet,
kuba, bestswngs
In-Reply-To: <20260326075553.3960562-1-xmei5@asu.edu>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 26 Mar 2026 00:55:53 -0700 you wrote:
> bond_xmit_broadcast() reuses the original skb for the last slave
> (determined by bond_is_last_slave()) and clones it for others.
> Concurrent slave enslave/release can mutate the slave list during
> RCU-protected iteration, changing which slave is "last" mid-loop.
> This causes the original skb to be double-consumed (double-freed).
>
> Replace the racy bond_is_last_slave() check with a simple index
> comparison (i + 1 == slaves_count) against the pre-snapshot slave
> count taken via READ_ONCE() before the loop. This preserves the
> zero-copy optimization for the last slave while making the "last"
> determination stable against concurrent list mutations.
>
> [...]
Here is the summary with links:
- [net,v3] net: bonding: fix use-after-free in bond_xmit_broadcast()
https://git.kernel.org/netdev/net/c/2884bf72fb8f
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next] net: reduce RFS/ARFS flow updates by checking LLC affinity
From: Eric Dumazet @ 2026-03-31 9:03 UTC (permalink / raw)
To: chuang
Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Stanislav Fomichev, Kuniyuki Iwashima, Samiullah Khawaja,
Hangbin Liu, netdev, linux-kernel
In-Reply-To: <CACueBy5bNuKQ27F0FYTsKePq_92unuEAaMqgyGK_3ovSrO6rWA@mail.gmail.com>
On Tue, Mar 31, 2026 at 12:42 AM chuang <nashuiliang@gmail.com> wrote:
>
> Hi,
>
> Any thoughts or suggestions on the patch "reduce RFS/ARFS flow updates
> by checking LLC affinity"? It’s been a while since the last update.
Please do not top-post on netdev@
Did I miss a V2 of your patch?
Include actual performance numbers in your submission to catch our
attention, or ask people using aRFS setups
to test your patch.
^ permalink raw reply
* Re: [PATCH net v2] NFC: pn533: bound the UART receive buffer
From: patchwork-bot+netdevbpf @ 2026-03-31 9:10 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: netdev, linux-kernel, tglx, mingo, kees, pabeni
In-Reply-To: <20260326142033.82297-1-pengpeng@iscas.ac.cn>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Thu, 26 Mar 2026 22:20:33 +0800 you wrote:
> pn532_receive_buf() appends every incoming byte to dev->recv_skb and
> only resets the buffer after pn532_uart_rx_is_frame() recognizes a
> complete frame. A continuous stream of bytes without a valid PN532 frame
> header therefore keeps growing the skb until skb_put_u8() hits the tail
> limit.
>
> Drop the accumulated partial frame once the fixed receive buffer is full
> so malformed UART traffic cannot grow the skb past
> PN532_UART_SKB_BUFF_LEN.
>
> [...]
Here is the summary with links:
- [net,v2] NFC: pn533: bound the UART receive buffer
https://git.kernel.org/netdev/net/c/30fe3f5f6494
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net,v5] virtio_net: clamp rss_max_key_size to NETDEV_RSS_KEY_LEN
From: Paolo Abeni @ 2026-03-31 9:20 UTC (permalink / raw)
To: Srujana Challa, netdev, virtualization
Cc: mst, jasowang, xuanzhuo, eperezma, davem, edumazet, kuba,
ndabilpuram, kshankar, stable
In-Reply-To: <20260326142344.1171317-1-schalla@marvell.com>
On 3/26/26 3:23 PM, Srujana Challa wrote:
> rss_max_key_size in the virtio spec is the maximum key size supported by
> the device, not a mandatory size the driver must use. Also the value 40
> is a spec minimum, not a spec maximum.
>
> The current code rejects RSS and can fail probe when the device reports a
> larger rss_max_key_size than the driver buffer limit. Instead, clamp the
> effective key length to min(device rss_max_key_size, NETDEV_RSS_KEY_LEN)
> and keep RSS enabled.
>
> This keeps probe working on devices that advertise larger maximum key sizes
> while respecting the netdev RSS key buffer size limit.
>
> Fixes: 3f7d9c1964fc ("virtio_net: Add hash_key_length check")
> Cc: stable@vger.kernel.org
> Signed-off-by: Srujana Challa <schalla@marvell.com>
> ---
> v3:
> - Moved RSS key validation checks to virtnet_validate.
> - Add fixes: tag and CC -stable
> v4:
> - Use NETDEV_RSS_KEY_LEN instead of type_max for the maximum rss key size.
> v5:
> - Interpret rss_max_key_size as a maximum and clamp it to NETDEV_RSS_KEY_LEN.
> - Do not disable RSS/HASH_REPORT when device rss_max_key_size exceeds NETDEV_RSS_KEY_LEN.
> - Drop the separate patch that replaced the runtime check with BUILD_BUG_ON.
>
> drivers/net/virtio_net.c | 20 +++++++++-----------
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 022f60728721..b241c8dbb4e1 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -373,8 +373,6 @@ struct receive_queue {
> struct xdp_buff **xsk_buffs;
> };
>
> -#define VIRTIO_NET_RSS_MAX_KEY_SIZE 40
> -
> /* Control VQ buffers: protected by the rtnl lock */
> struct control_buf {
> struct virtio_net_ctrl_hdr hdr;
> @@ -478,7 +476,7 @@ struct virtnet_info {
>
> /* Must be last as it ends in a flexible-array member. */
> TRAILING_OVERLAP(struct virtio_net_rss_config_trailer, rss_trailer, hash_key_data,
> - u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];
> + u8 rss_hash_key_data[NETDEV_RSS_KEY_LEN];
> );
> };
> static_assert(offsetof(struct virtnet_info, rss_trailer.hash_key_data) ==
> @@ -6717,6 +6715,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> struct virtnet_info *vi;
> u16 max_queue_pairs;
> int mtu = 0;
> + u16 key_sz;
>
> /* Find if host supports multiqueue/rss virtio_net device */
> max_queue_pairs = 1;
> @@ -6851,14 +6850,13 @@ static int virtnet_probe(struct virtio_device *vdev)
> }
>
> if (vi->has_rss || vi->has_rss_hash_report) {
> - vi->rss_key_size =
> - virtio_cread8(vdev, offsetof(struct virtio_net_config, rss_max_key_size));
> - if (vi->rss_key_size > VIRTIO_NET_RSS_MAX_KEY_SIZE) {
> - dev_err(&vdev->dev, "rss_max_key_size=%u exceeds the limit %u.\n",
> - vi->rss_key_size, VIRTIO_NET_RSS_MAX_KEY_SIZE);
> - err = -EINVAL;
> - goto free;
> - }
> + key_sz = virtio_cread8(vdev, offsetof(struct virtio_net_config, rss_max_key_size));
> +
> + vi->rss_key_size = min_t(u16, key_sz, NETDEV_RSS_KEY_LEN);
> + if (key_sz > vi->rss_key_size)
> + dev_warn(&vdev->dev,
> + "rss_max_key_size=%u exceeds driver limit %u, clamping\n",
> + key_sz, vi->rss_key_size);
NETDEV_RSS_KEY_LEN is 256 and virtio_cread8() returns a u8. The check is
not needed, and the warning will never be printed. I think that the
BUILD_BUG_ON() you used in v4 would be better than the above chunk.
/P
^ permalink raw reply
* [PATCH v2] xfrm: delay dev_put in xfrm_input to after transport reinject
From: Qi Tang @ 2026-03-31 9:27 UTC (permalink / raw)
To: Steffen Klassert, Herbert Xu
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, David Ahern, netdev, Qi Tang, stable
xfrm_trans_queue() queues transport-mode packets for async reinject
via xfrm_trans_reinject() workqueue. After async crypto completes,
xfrm_input_resume() re-enters xfrm_input() with encap_type == -1,
which immediately calls dev_put(skb->dev) before the skb reaches
transport_finish and the reinject queue. The device can be freed
before the workqueue callback runs, causing a use-after-free when
xfrm_trans_reinject dereferences skb->dev.
Remove the dev_put from the async resumption entry and let the
reference survive through the transport reinject path. Introduce
async variants of the NF_HOOK okfn callbacks that queue the skb
with dev_held=true and drop the reference on error. The reinject
worker checks this flag and puts the reference after the callback
completes.
For the synchronous crypto path, the existing dev_hold/dev_put
around x->type->input() is unchanged — the reference is balanced
within the same softirq context before the skb reaches the queue.
If the loop re-enters async crypto (multi-SPI with a second
-EINPROGRESS), drop the extra reference from the earlier async
resume so exactly one reference accompanies the skb.
Fixes: acf568ee859f ("xfrm: Reinject transport-mode packets through tasklet")
Cc: stable@vger.kernel.org
Signed-off-by: Qi Tang <tpluszz77@gmail.com>
---
Changes in v2:
- Do not add extra dev_hold/dev_put pair (reviewer feedback:
"expensive operation, we just drop it too early")
- Reuse existing dev_hold from xfrm_input, delay dev_put to
reinject completion
- Add async okfn variants for IPv4/IPv6 transport_finish so
the reinject queue knows whether a dev ref is held
- Drop the cb->dev field from v1; use bool dev_held flag instead
Link: https://lore.kernel.org/all/20260320073023.21873-1-tpluszz77@gmail.com/
---
include/net/xfrm.h | 3 ++-
net/ipv4/esp4.c | 3 ++-
net/ipv4/xfrm4_input.c | 25 ++++++++++++++++++++++++-
net/ipv6/esp6.c | 3 ++-
net/ipv6/xfrm6_input.c | 16 +++++++++++++++-
net/xfrm/xfrm_input.c | 35 ++++++++++++++++++++++++++---------
6 files changed, 71 insertions(+), 14 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 10d3edde6b2f..1dd8b3b36649 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -1779,7 +1779,8 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type);
int xfrm_input_resume(struct sk_buff *skb, int nexthdr);
int xfrm_trans_queue_net(struct net *net, struct sk_buff *skb,
int (*finish)(struct net *, struct sock *,
- struct sk_buff *));
+ struct sk_buff *),
+ bool dev_held);
int xfrm_trans_queue(struct sk_buff *skb,
int (*finish)(struct net *, struct sock *,
struct sk_buff *));
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 6dfc0bcdef65..0114c92b10d4 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -187,7 +187,8 @@ static int esp_output_tail_tcp(struct xfrm_state *x, struct sk_buff *skb)
int err;
local_bh_disable();
- err = xfrm_trans_queue_net(xs_net(x), skb, esp_output_tcp_encap_cb);
+ err = xfrm_trans_queue_net(xs_net(x), skb, esp_output_tcp_encap_cb,
+ false);
local_bh_enable();
/* EINPROGRESS just happens to do the right thing. It
diff --git a/net/ipv4/xfrm4_input.c b/net/ipv4/xfrm4_input.c
index f28cfd88eaf5..9765fdc63ffc 100644
--- a/net/ipv4/xfrm4_input.c
+++ b/net/ipv4/xfrm4_input.c
@@ -46,6 +46,28 @@ static inline int xfrm4_rcv_encap_finish(struct net *net, struct sock *sk,
return NET_RX_DROP;
}
+static int xfrm4_rcv_encap_finish_async(struct net *net, struct sock *sk,
+ struct sk_buff *skb)
+{
+ if (!skb_dst(skb)) {
+ const struct iphdr *iph = ip_hdr(skb);
+
+ if (ip_route_input_noref(skb, iph->daddr, iph->saddr,
+ ip4h_dscp(iph), skb->dev))
+ goto drop;
+ }
+
+ if (xfrm_trans_queue_net(dev_net(skb->dev), skb,
+ xfrm4_rcv_encap_finish2, true))
+ goto drop;
+
+ return 0;
+drop:
+ dev_put(skb->dev);
+ kfree_skb(skb);
+ return NET_RX_DROP;
+}
+
int xfrm4_transport_finish(struct sk_buff *skb, int async)
{
struct xfrm_offload *xo = xfrm_offload(skb);
@@ -74,7 +96,8 @@ int xfrm4_transport_finish(struct sk_buff *skb, int async)
NF_HOOK(NFPROTO_IPV4, NF_INET_PRE_ROUTING,
dev_net(skb->dev), NULL, skb, skb->dev, NULL,
- xfrm4_rcv_encap_finish);
+ async ? xfrm4_rcv_encap_finish_async :
+ xfrm4_rcv_encap_finish);
return 0;
}
diff --git a/net/ipv6/esp6.c b/net/ipv6/esp6.c
index 9f75313734f8..8a0a44d7d010 100644
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -204,7 +204,8 @@ static int esp_output_tail_tcp(struct xfrm_state *x, struct sk_buff *skb)
int err;
local_bh_disable();
- err = xfrm_trans_queue_net(xs_net(x), skb, esp_output_tcp_encap_cb);
+ err = xfrm_trans_queue_net(xs_net(x), skb, esp_output_tcp_encap_cb,
+ false);
local_bh_enable();
/* EINPROGRESS just happens to do the right thing. It
diff --git a/net/ipv6/xfrm6_input.c b/net/ipv6/xfrm6_input.c
index 9005fc156a20..d4eede5315ac 100644
--- a/net/ipv6/xfrm6_input.c
+++ b/net/ipv6/xfrm6_input.c
@@ -40,6 +40,19 @@ static int xfrm6_transport_finish2(struct net *net, struct sock *sk,
return 0;
}
+static int xfrm6_transport_finish2_async(struct net *net, struct sock *sk,
+ struct sk_buff *skb)
+{
+ if (xfrm_trans_queue_net(dev_net(skb->dev), skb, ip6_rcv_finish,
+ true)) {
+ dev_put(skb->dev);
+ kfree_skb(skb);
+ return NET_RX_DROP;
+ }
+
+ return 0;
+}
+
int xfrm6_transport_finish(struct sk_buff *skb, int async)
{
struct xfrm_offload *xo = xfrm_offload(skb);
@@ -69,7 +82,8 @@ int xfrm6_transport_finish(struct sk_buff *skb, int async)
NF_HOOK(NFPROTO_IPV6, NF_INET_PRE_ROUTING,
dev_net(skb->dev), NULL, skb, skb->dev, NULL,
- xfrm6_transport_finish2);
+ async ? xfrm6_transport_finish2_async :
+ xfrm6_transport_finish2);
return 0;
}
diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index dc1312ed5a09..2d75f984532a 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -40,6 +40,7 @@ struct xfrm_trans_cb {
} header;
int (*finish)(struct net *net, struct sock *sk, struct sk_buff *skb);
struct net *net;
+ bool dev_held;
};
#define XFRM_TRANS_SKB_CB(__skb) ((struct xfrm_trans_cb *)&((__skb)->cb[0]))
@@ -506,7 +507,6 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
/* An encap_type of -1 indicates async resumption. */
if (encap_type == -1) {
async = 1;
- dev_put(skb->dev);
seq = XFRM_SKB_CB(skb)->seq.input.low;
spin_lock(&x->lock);
goto resume;
@@ -659,8 +659,11 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
dev_hold(skb->dev);
nexthdr = x->type->input(x, skb);
- if (nexthdr == -EINPROGRESS)
+ if (nexthdr == -EINPROGRESS) {
+ if (async)
+ dev_put(skb->dev);
return 0;
+ }
dev_put(skb->dev);
spin_lock(&x->lock);
@@ -695,9 +698,11 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
XFRM_MODE_SKB_CB(skb)->protocol = nexthdr;
err = xfrm_inner_mode_input(x, skb);
- if (err == -EINPROGRESS)
+ if (err == -EINPROGRESS) {
+ if (async)
+ dev_put(skb->dev);
return 0;
- else if (err) {
+ } else if (err) {
XFRM_INC_STATS(net, LINUX_MIB_XFRMINSTATEMODEERROR);
goto drop;
}
@@ -734,6 +739,8 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
sp->olen = 0;
if (skb_valid_dst(skb))
skb_dst_drop(skb);
+ if (async)
+ dev_put(skb->dev);
gro_cells_receive(&gro_cells, skb);
return 0;
} else {
@@ -753,6 +760,8 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
sp->olen = 0;
if (skb_valid_dst(skb))
skb_dst_drop(skb);
+ if (async)
+ dev_put(skb->dev);
gro_cells_receive(&gro_cells, skb);
return err;
}
@@ -763,6 +772,8 @@ int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
drop_unlock:
spin_unlock(&x->lock);
drop:
+ if (async)
+ dev_put(skb->dev);
xfrm_rcv_cb(skb, family, x && x->type ? x->type->proto : nexthdr, -1);
kfree_skb(skb);
return 0;
@@ -787,15 +798,20 @@ static void xfrm_trans_reinject(struct work_struct *work)
spin_unlock_bh(&trans->queue_lock);
local_bh_disable();
- while ((skb = __skb_dequeue(&queue)))
- XFRM_TRANS_SKB_CB(skb)->finish(XFRM_TRANS_SKB_CB(skb)->net,
- NULL, skb);
+ while ((skb = __skb_dequeue(&queue))) {
+ struct xfrm_trans_cb *cb = XFRM_TRANS_SKB_CB(skb);
+ struct net_device *dev = cb->dev_held ? skb->dev : NULL;
+
+ cb->finish(cb->net, NULL, skb);
+ dev_put(dev);
+ }
local_bh_enable();
}
int xfrm_trans_queue_net(struct net *net, struct sk_buff *skb,
int (*finish)(struct net *, struct sock *,
- struct sk_buff *))
+ struct sk_buff *),
+ bool dev_held)
{
struct xfrm_trans_tasklet *trans;
@@ -808,6 +824,7 @@ int xfrm_trans_queue_net(struct net *net, struct sk_buff *skb,
XFRM_TRANS_SKB_CB(skb)->finish = finish;
XFRM_TRANS_SKB_CB(skb)->net = net;
+ XFRM_TRANS_SKB_CB(skb)->dev_held = dev_held;
spin_lock_bh(&trans->queue_lock);
__skb_queue_tail(&trans->queue, skb);
spin_unlock_bh(&trans->queue_lock);
@@ -820,7 +837,7 @@ int xfrm_trans_queue(struct sk_buff *skb,
int (*finish)(struct net *, struct sock *,
struct sk_buff *))
{
- return xfrm_trans_queue_net(dev_net(skb->dev), skb, finish);
+ return xfrm_trans_queue_net(dev_net(skb->dev), skb, finish, false);
}
EXPORT_SYMBOL(xfrm_trans_queue);
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox