* Re: [PATCH net-next 1/3] net: Do not unconditionally turn on carrier when clearing protodown
From: Jakub Kicinski @ 2026-05-05 0:55 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, pabeni, edumazet, andrew+netdev, horms, petrm
In-Reply-To: <20260503180803.GA269092@shredder>
On Sun, 3 May 2026 21:08:03 +0300 Ido Schimmel wrote:
> There are drivers that only implement ndo_get_iflink(), but don't
> implement get_link_net(), so it's unclear in which netns we need to look
> up the device using the ifindex we got from ndo_get_iflink(). Netdevsim
> is one example. There are also some drivers that only implement
> get_link_net() such as vxlan.
>
> The popular drivers such as vlan, macvlan and veth obviously implement
> both.
It's probably unintentional omission for the less popular devices.
Easy to forget to add an NDO (which is also the basis for my initial
comments).
> I added a helper [1] that resolves the linked device if these operations
> are present and otherwise returns the device itself. Similar to
> dev_get_iflink() which only gives us the ifindex.
The linked diff LGTM, thanks!
> Another option is to add a new NDO that gives us a pointer to the linked
> device.
^ permalink raw reply
* Re: [PATCH net-next 2/3] macvlan: Do not transfer operational state when protodown is enabled
From: Jakub Kicinski @ 2026-05-05 0:57 UTC (permalink / raw)
To: Ido Schimmel; +Cc: netdev, davem, pabeni, edumazet, andrew+netdev, horms, petrm
In-Reply-To: <20260503181934.GB269092@shredder>
On Sun, 3 May 2026 21:19:34 +0300 Ido Schimmel wrote:
> On Fri, May 01, 2026 at 06:09:48PM -0700, Jakub Kicinski wrote:
> > On Wed, 29 Apr 2026 15:46:23 +0300 Ido Schimmel wrote:
> > > - list_for_each_entry(vlan, &port->vlans, list)
> > > + list_for_each_entry(vlan, &port->vlans, list) {
> > > + if (vlan->dev->proto_down)
> > > + continue;
> > > netif_stacked_transfer_operstate(vlan->lowerdev,
> > > vlan->dev);
> >
> > Doesn't feel particularly macvlan-specific?
> > Other simple upper devs don't support protodown
> > but when they do presumably they'll have to add
> > this exact condition, too, so why not add it in
> > netif_stacked_transfer_operstate()?
>
> It seemed more consistent with patch #1 that invokes
> netif_stacked_transfer_operstate() from the driver. I can move it to the
> core in v2 [1] assuming we go for a solution that doesn't involve the
> driver at all.
>
> [1] https://github.com/idosch/linux/commit/1d86acbf0affc9004fad79820bbb2172aeb305a4.patch
👍
^ permalink raw reply
* Re: [RFC PATCH net-next 1/2] net: napi: Fix interrupts permanently disabled during busy poll
From: Jakub Kicinski @ 2026-05-05 1:00 UTC (permalink / raw)
To: Dragos Tatulea
Cc: Björn Töpel, David S. Miller, Eric Dumazet, Paolo Abeni,
Simon Horman, Daniel Borkmann, Martin Karsten, Gal Pressman,
Tariq Toukan, Joe Damato, Frederik Deweerdt, netdev, linux-kernel
In-Reply-To: <4onzzvtgdyj5k4himhtv4dsga4dnunk4ppjyqgam6us44biear@7vvozjz2ywrr>
On Mon, 4 May 2026 11:30:47 +0000 Dragos Tatulea wrote:
> > > That would also follow the scheme in napi_schedule_done(). (Note that
> > > swapping arm/clear does mean that we can get a wasted-timer outcome.)
> > >
> > If it is wasted is fine. I figured that this could end up with a timer
> > scheduled after the napi deletion:
> >
> > 1. busy_poll_stop(): clears SCHED bit.
> > 2. napi_disable() runs past SCHED wait, cancels timer and caller
> > deletes napi mem.
> > 3. busy_poll_stop(): napi->timer is armed but napi is freed memory
> > by now.
> >
> > What am I missing here?
> >
> Gentle ping. Once I understand how/why the above is incorrect I can
> update the patch and send it.
Eh, I didn't respond cause I got depressed. Look around for the pattern
you are calling incorrect in existing code and you'll figure out why...
^ permalink raw reply
* Re: [PATCH iproute2-next] tc: qdisc: provide tcm_handle and tcm_parent to kernel dump requests
From: patchwork-bot+netdevbpf @ 2026-05-05 1:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: dsahern, stephen, davem, kuba, pabeni, netdev, eric.dumazet, jhs
In-Reply-To: <20260503115138.2467123-1-edumazet@google.com>
Hello:
This patch was applied to iproute2/iproute2-next.git (main)
by David Ahern <dsahern@kernel.org>:
On Sun, 3 May 2026 11:51:37 +0000 you wrote:
> linux-7.2 can filter "tc qdisc show ..." on tcm_handle / tcm_parent and
> reduce dump costs.
>
> Old kernels ignore these values.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
>
> [...]
Here is the summary with links:
- [iproute2-next] tc: qdisc: provide tcm_handle and tcm_parent to kernel dump requests
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=0fbce40d480f
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 2/4] tools: ynl-gen-c: optionally emit structs and helpers
From: Jakub Kicinski @ 2026-05-05 1:02 UTC (permalink / raw)
To: Christoph Böhmwalder
Cc: Jens Axboe, drbd-dev, linux-kernel, Lars Ellenberg,
Philipp Reisner, linux-block, Donald Hunter, Eric Dumazet, netdev
In-Reply-To: <afhgQgySpoxXFCn1@localhost.localdomain>
On Mon, 4 May 2026 11:05:55 +0200 Christoph Böhmwalder wrote:
> On Tue, Apr 14, 2026 at 08:35:48AM -0700, Jakub Kicinski wrote:
> >On Tue, 14 Apr 2026 14:08:58 +0200 Christoph Böhmwalder wrote:
> >> But we still need to support the current family via a compat path, and
> >> I would much rather have two YNL-based families than one genl_magic and
> >> one YNL-based. Carrying both sounds like a nightmare.
> >>
> >> So the spec proposed in this series would never actually be used to
> >> generate a userspace client, if that's what you're asking. We would
> >> continue to use the current libgenl-based approach, with some userspace
> >> compat shims to make it work with YNL. Then, when "drbd2" comes along,
> >> we could "do things properly".
> >
> >Let's jump to the drbd2 work.
>
> We have a bit of a chicken-egg situation there.
>
> The drbd2 work depends on the DRBD 9 upstreaming series, since the drbd2
> netlink family will use the new DRBD 9 semantics.
> However, the DRBD 9 series depends on the current DRBD module already
> using YNL (or rather, *not* using genl_magic anymore).
>
> Our plan is to convert the current family to YNL in-place first, then
> incrementally add the new modern drbd2 family with DRBD 9 semantics in
> another series.
>
> How would you prefer to handle the YNL switch? If it makes it easier for
> you, just committing the YNL-generated code without the generator is
> fine for me. The old family is effectively frozen, so that would work.
That could work. Please float a series and CC netdev, we'll review.
^ permalink raw reply
* Re: [PATCH net-next] e1000e: ethtool: add get_channels support
From: Jakub Kicinski @ 2026-05-05 1:06 UTC (permalink / raw)
To: Jon Kohler
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <6F0C5872-0388-47AF-8CD9-1D116EA13224@nutanix.com>
On Tue, 5 May 2026 00:59:40 +0000 Jon Kohler wrote:
> > On May 4, 2026, at 7:49 PM, Jakub Kicinski <kuba@kernel.org> wrote:
> >> e1000e hardware supports a single RX/TX queue pair, add basic support
> >> for ethtool -l (i.e. get_channels), so that callers indeed see a single
> >> queue.
> >
> > Why? Isn't EOPNOTSUP from ethtool -l implicitly saying that there's
> > only one queue?
>
> Perhaps, but I’m not sure that is a guarantee. A good relevant example
> is when I added get_channels support to enic, which supports all sorts
> of channels, so I don’t think EOPNOTSUP can be 100% consider reliable
> in that case. Meaning, if it just so happens that the original author(s)
> didn't put in get_channels, that doesn’t necessarily mean there is only
> one queue.
>
> And in this case, there is an "other" queue as as well too, as far as
> I can tell, so the output is at least semi-interesting.
Sorry I wasn't clear enough - if you have an actual, real life use case
why you need queue count of 1 to be explicitly reported - please explain
it and put it in the commit message.
If you don't - please don't send patches for the sake of it.
^ permalink raw reply
* Re: [PATCH net-next] net/mlx5: Add MLX5_VXLAN config option
From: Jakub Kicinski @ 2026-05-05 1:10 UTC (permalink / raw)
To: Marc Harvey
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Mark Bloch,
Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni, netdev,
linux-rdma, linux-kernel, Kuniyuki Iwashima
In-Reply-To: <CANkEMg=Xc9jN8McZmLerK_ffOwRFfX+yO=4Ha6+umVogbkBj3A@mail.gmail.com>
On Mon, 4 May 2026 15:44:26 -0700 Marc Harvey wrote:
> > Are you aware of NETIF_F_RX_UDP_TUNNEL_PORT ?
> > I haven't checked it does exactly what we need, but I recall there was
> > a ethtool feature for this..
>
> Thanks, I didn't know about that feature and mlx5 uses it. However,
> mlx5 unconditionally sets the `UDP_TUNNEL_NIC_INFO_STATIC_IANA_VXLAN`
> flag, which excludes port 4789 from the entire UDP tunnel core offload
> management (see `__udp_tunnel_nic_add_port()`).
>
> So using ethtool to disable `NETIF_F_RX_UDP_TUNNEL_PORT` will not
> disable vxlan offload for port 4789.
>
> I think a better approach would be to just remove this static
> automatic offloading for port 4789, mlx5 is the only driver using
> `UDP_TUNNEL_NIC_INFO_STATIC_IANA_VXLAN` anyway. However, there might
> be a reason for this, such as some supported hardware offloading vxlan
> on port 4789 by default even without commands from the driver.
>
> If mlx5 continues to use the `UDP_TUNNEL_NIC_INFO_STATIC_IANA_VXLAN`
> flag, then some change is required to fully disable vxlan offloading.
Sorry, I don't know mlx5 very well. Sounds like you have to talk
to nVidia or/and run some experiments. The current patch is a no-go.
^ permalink raw reply
* Re: [PATCH net-next] e1000e: ethtool: add get_channels support
From: Jon Kohler @ 2026-05-05 1:12 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260504180656.62539d96@kernel.org>
> On May 4, 2026, at 9:06 PM, Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Tue, 5 May 2026 00:59:40 +0000 Jon Kohler wrote:
>>> On May 4, 2026, at 7:49 PM, Jakub Kicinski <kuba@kernel.org> wrote:
>>>> e1000e hardware supports a single RX/TX queue pair, add basic support
>>>> for ethtool -l (i.e. get_channels), so that callers indeed see a single
>>>> queue.
>>>
>>> Why? Isn't EOPNOTSUP from ethtool -l implicitly saying that there's
>>> only one queue?
>>
>> Perhaps, but I’m not sure that is a guarantee. A good relevant example
>> is when I added get_channels support to enic, which supports all sorts
>> of channels, so I don’t think EOPNOTSUP can be 100% consider reliable
>> in that case. Meaning, if it just so happens that the original author(s)
>> didn't put in get_channels, that doesn’t necessarily mean there is only
>> one queue.
>>
>> And in this case, there is an "other" queue as as well too, as far as
>> I can tell, so the output is at least semi-interesting.
>
> Sorry I wasn't clear enough - if you have an actual, real life use case
> why you need queue count of 1 to be explicitly reported - please explain
> it and put it in the commit message.
>
> If you don't - please don't send patches for the sake of it.
Ah, ok, sorry I misread your message, this isn’t a patch for the sake of
a patch. Long story short, we’ve got a user space part of our control plane
that reads in the output of ethtool -l as part of some broader queue
management code. On systems with an e1000e device present, this specific
component goes into a crash loop as it expects all NIC(s) to at least
give it some sort of output.
That crash loop is easy enough to fix to ignore unsupported outputs;
however, my thought here is a simply defense in depth fixup, especially
since the kernel patch is quite trivial.
^ permalink raw reply
* Re: [PATCH net-next] e1000e: ethtool: add get_channels support
From: Jon Kohler @ 2026-05-05 0:59 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260504164901.7b3a737b@kernel.org>
> On May 4, 2026, at 7:49 PM, Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 4 May 2026 08:48:23 -0700 Jon Kohler wrote:
>> e1000e hardware supports a single RX/TX queue pair, add basic support
>> for ethtool -l (i.e. get_channels), so that callers indeed see a single
>> queue.
>
> Why? Isn't EOPNOTSUP from ethtool -l implicitly saying that there's
> only one queue?
Perhaps, but I’m not sure that is a guarantee. A good relevant example
is when I added get_channels support to enic, which supports all sorts
of channels, so I don’t think EOPNOTSUP can be 100% consider reliable
in that case. Meaning, if it just so happens that the original author(s)
didn't put in get_channels, that doesn’t necessarily mean there is only
one queue.
And in this case, there is an "other" queue as as well too, as far as
I can tell, so the output is at least semi-interesting.
Jon
^ permalink raw reply
* Re: [PATCH net-next V2 7/7] net/mlx5: Add profile to auto-enable switchdev mode at device init
From: Jakub Kicinski @ 2026-05-05 1:21 UTC (permalink / raw)
To: Mark Bloch
Cc: Tariq Toukan, Eric Dumazet, Paolo Abeni, Andrew Lunn,
David S. Miller, Leon Romanovsky, Jason Gunthorpe, Saeed Mahameed,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Gerd Bayer, Moshe Shemesh, Kees Cook,
Patrisious Haddad, Parav Pandit, Carolina Jubran, Cosmin Ratiu,
linux-rdma, linux-kernel, netdev, Gal Pressman, Dragos Tatulea
In-Reply-To: <cc01cca2-0e5d-4db2-81e4-7ea9fe525320@nvidia.com>
On Sun, 3 May 2026 10:51:06 +0300 Mark Bloch wrote:
> On 03/05/2026 4:41, Jakub Kicinski wrote:
> > On Sat, 2 May 2026 23:08:43 +0300 Mark Bloch wrote:
> >> Before I respin for the unrelated MR_CACHE cleanup, I’d like to confirm
> >> whether the opt-in profile approach is acceptable at all. Regardless
> >> of this last patch, the first 6 patches fix real representor/LAG locking
> >> issues and are needed independently, so I’d like to keep those moving toward
> >> acceptance as soon as possible.
> >
> > For probe-time config module param is probably our only option.
> > I'd obviously prefer to have a devlink-level knob for this, instead
> > of a mlx5 specific one. Can we come up with some format that'd apply
> > more broadly? devlink=[$bfd:]flag1 ? so devlink=[$bdf:]switchdev-mode ?
>
> I’m not convinced this is really a generic devlink knob problem.
I'm surprised you say that. Anyone using switchdev mode could benefit.
Having the probe in one mode and switch adds to boot time. Whether it's
a DPU or not is quite secondary.
Unless there's another deeper reason which makes the DPU incapable of
running in the non-switchdev mode. But not sure that squares with the
code you posted AFAICT.
> A device should probe in its selected/default configuration. For DPU
> deployments switchdev is the expected operating mode. mlx5 just made the
> wrong default choice historically, and this profile is a way to move away
> from that without forcing it on everyone at once. I expect/hope to move
> quickly from this flag to simply making switchdev the driver default for
> all DPU configs.
>
> A generic cmdline format also gets complicated quickly: vendor-specific
> flags, ordering/dependencies between flags, hotplug timing, and whether a
> BDF rule should apply when a device is passed into a VM after boot.
> Userspace scripts are probably better for that kind of policy because
> they can carry real site specific logic.
>
> I’ll drop this last patch from the series for now so the representor/LAG
> locking fixes can move independently and we can continue the default
> switchdev discussion separately. I can always submit that as a standalone
> patch later in the cycle if needed.
SG
^ permalink raw reply
* Re: [PATCH v2 0/7] seg6: add SRv6 Mobile User Plane (RFC 9433) behaviors
From: Yuya Kusakabe @ 2026-05-05 1:22 UTC (permalink / raw)
To: Jakub Kicinski
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Andrea Mayer, Shuah Khan, Jonathan Corbet, Shuah Khan,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <20260504163915.4a8b028e@kernel.org>
2026年5月5日火曜日 Jakub Kicinski <kuba@kernel.org>:
> Could you switch to posting this as an RFC until you gather some review
> tags? Our CI require manual intervention to add the necessary iproute2
> patches, I suspect there may be some uAPI changes therefore requiring
> iproute2 changes here.
Will do. Yes, this series adds new SEG6_LOCAL_* / SEG6_LOCAL_MOBILE_*
uAPI in include/uapi/linux/seg6_local.h; the matching iproute2-next
series is posted separately:
https://lore.kernel.org/netdev/20260505-seg6-mobile-v2-0-93291b7b0134@gmail.com/
Just to confirm the workflow you'd prefer: should I repost the
current series immediately as [PATCH RFC net-next v3 ...], or wait
for technical review on v2 to land and fold it into a v3 RFC?
Thanks,
Yuya
^ permalink raw reply
* Re: [PATCH net-next] e1000e: ethtool: add get_channels support
From: Jakub Kicinski @ 2026-05-05 1:26 UTC (permalink / raw)
To: Jon Kohler
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <D670011F-AA11-4AFF-A70B-4DFF03C5F049@nutanix.com>
On Tue, 5 May 2026 01:12:29 +0000 Jon Kohler wrote:
> > On May 4, 2026, at 9:06 PM, Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Tue, 5 May 2026 00:59:40 +0000 Jon Kohler wrote:
> [...]
> [...]
> [...]
> >>
> >> Perhaps, but I’m not sure that is a guarantee. A good relevant example
> >> is when I added get_channels support to enic, which supports all sorts
> >> of channels, so I don’t think EOPNOTSUP can be 100% consider reliable
> >> in that case. Meaning, if it just so happens that the original author(s)
> >> didn't put in get_channels, that doesn’t necessarily mean there is only
> >> one queue.
> >>
> >> And in this case, there is an "other" queue as as well too, as far as
> >> I can tell, so the output is at least semi-interesting.
> >
> > Sorry I wasn't clear enough - if you have an actual, real life use case
> > why you need queue count of 1 to be explicitly reported - please explain
> > it and put it in the commit message.
> >
> > If you don't - please don't send patches for the sake of it.
>
> Ah, ok, sorry I misread your message, this isn’t a patch for the sake of
> a patch. Long story short, we’ve got a user space part of our control plane
> that reads in the output of ethtool -l as part of some broader queue
> management code. On systems with an e1000e device present, this specific
> component goes into a crash loop as it expects all NIC(s) to at least
> give it some sort of output.
>
> That crash loop is easy enough to fix to ignore unsupported outputs;
> however, my thought here is a simply defense in depth fixup, especially
> since the kernel patch is quite trivial.
Got it, thanks for explaining.
My concern is that if we are expected to always report channel counts
we're signing up for a major whack-a-mole with the existing drivers.
Most drivers don't implement it. The networking stack does report
the number of queues the device asked for via rtnetlink:
ip -j -d li show dev $ifc | jq '.[].num_rx_queues'
but in your case I'd personally lean towards user space fix.
^ permalink raw reply
* Re: [PATCH v2 0/7] seg6: add SRv6 Mobile User Plane (RFC 9433) behaviors
From: Jakub Kicinski @ 2026-05-05 1:28 UTC (permalink / raw)
To: Yuya Kusakabe
Cc: David S. Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Andrea Mayer, Shuah Khan, Jonathan Corbet, Shuah Khan,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org,
Justin Iurman
In-Reply-To: <CAGCJULP83NnaX6HAqwb3umDXsxN8LH48_gPpJ_3gG8_xA96QNQ@mail.gmail.com>
On Tue, 5 May 2026 10:22:58 +0900 Yuya Kusakabe wrote:
> Just to confirm the workflow you'd prefer: should I repost the
> current series immediately as [PATCH RFC net-next v3 ...], or wait
> for technical review on v2 to land and fold it into a v3 RFC?
Let's wait for reviews (adding Justin to CC as well FWIW)
^ permalink raw reply
* [PATCH net-next] net: usb: mcs7830: fix typo in module description and clarify it
From: Ethan Nelson-Moore @ 2026-05-05 1:34 UTC (permalink / raw)
To: linux-usb, netdev
Cc: Ethan Nelson-Moore, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Andy Shevchenko, Vadim Fedorenko
The mcs7830 driver's MODULE_DESCRIPTION has an errant parenthesis
and does not indicate that the device is an Ethernet adapter. Remove
the parenthesis and improve the description.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
drivers/net/usb/mcs7830.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
index d6698f30218d..161f021ed419 100644
--- a/drivers/net/usb/mcs7830.c
+++ b/drivers/net/usb/mcs7830.c
@@ -626,5 +626,5 @@ static struct usb_driver mcs7830_driver = {
module_usb_driver(mcs7830_driver);
-MODULE_DESCRIPTION("USB to network adapter MCS7830)");
+MODULE_DESCRIPTION("MCS7830 USB to Ethernet adapter driver");
MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH net v2] eth: fbnic: fix double-free of PCS on phylink creation failure
From: Bobby Eshleman @ 2026-05-05 1:42 UTC (permalink / raw)
To: Alexander Duyck, Jakub Kicinski, kernel-team, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Russell King
Cc: netdev, linux-kernel, Bobby Eshleman
From: Bobby Eshleman <bobbyeshleman@meta.com>
fbnic_phylink_create() stores the newly allocated PCS in fbn->pcs and
then calls phylink_create(). When phylink_create() fails, the error path
correctly destroys the PCS via xpcs_destroy_pcs(), but the caller,
fbnic_netdev_alloc(), responds by invoking fbnic_netdev_free() which
calls fbnic_phylink_destroy(). That function finds fbn->pcs non-NULL and
calls xpcs_destroy_pcs() a second time on the already-freed object,
triggering a refcount underflow use-after-free:
[ 1.934973] fbnic 0000:01:00.0: Failed to create Phylink interface, err: -22
[ 1.935103] ------------[ cut here ]------------
[ 1.935179] refcount_t: underflow; use-after-free.
[ 1.935252] WARNING: lib/refcount.c:28 at refcount_warn_saturate+0x59/0x90, CPU#0: swapper/0/1
[ 1.935389] Modules linked in:
[ 1.935484] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-virtme-04244-g1f5ffc672165-dirty #1 PREEMPT(lazy)
[ 1.935661] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
[ 1.935826] RIP: 0010:refcount_warn_saturate+0x59/0x90
[ 1.935931] Code: 44 48 8d 3d 49 f9 a7 01 67 48 0f b9 3a e9 bf 1e 96 00 48 8d 3d 48 f9 a7 01 67 48 0f b9 3a c3 cc cc cc cc 48 8d 3d 47 f9 a7 01 <67> 48 0f b9 3a c3 cc cc cc cc 48 8d 3d 46 f9 a7 01 67 48 0f b9 3a
[ 1.936274] RSP: 0000:ffffd0d440013c58 EFLAGS: 00010246
[ 1.936376] RAX: 0000000000000000 RBX: ffff8f39c188c278 RCX: 000000000000002b
[ 1.936524] RDX: ffff8f39c004f000 RSI: 0000000000000003 RDI: ffffffff96abab00
[ 1.936692] RBP: ffff8f39c188c240 R08: ffffffff96988e88 R09: 00000000ffffdfff
[ 1.936835] R10: ffffffff96878ea0 R11: 0000000000000187 R12: 0000000000000000
[ 1.936970] R13: ffff8f39c0cef0c8 R14: ffff8f39c1ac01c0 R15: 0000000000000000
[ 1.937114] FS: 0000000000000000(0000) GS:ffff8f3ba08b4000(0000) knlGS:0000000000000000
[ 1.937273] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.937382] CR2: ffff8f3b3ffff000 CR3: 0000000172642001 CR4: 0000000000372ef0
[ 1.937540] Call Trace:
[ 1.937619] <TASK>
[ 1.937698] xpcs_destroy_pcs+0x25/0x40
[ 1.937783] fbnic_netdev_alloc+0x1e5/0x200
[ 1.937859] fbnic_probe+0x230/0x370
[ 1.937939] local_pci_probe+0x3e/0x90
[ 1.938013] pci_device_probe+0xbb/0x1e0
[ 1.938091] ? sysfs_do_create_link_sd+0x6d/0xe0
[ 1.938188] really_probe+0xc1/0x2b0
[ 1.938282] __driver_probe_device+0x73/0x120
[ 1.938371] driver_probe_device+0x1e/0xe0
[ 1.938466] __driver_attach+0x8d/0x190
[ 1.938560] ? __pfx___driver_attach+0x10/0x10
[ 1.938663] bus_for_each_dev+0x7b/0xd0
[ 1.938758] bus_add_driver+0xe8/0x210
[ 1.938854] driver_register+0x60/0x120
[ 1.938929] ? __pfx_fbnic_init_module+0x10/0x10
[ 1.939026] fbnic_init_module+0x25/0x60
[ 1.939109] do_one_initcall+0x49/0x220
[ 1.939202] ? rdinit_setup+0x20/0x40
[ 1.939304] kernel_init_freeable+0x1b0/0x310
[ 1.939449] ? __pfx_kernel_init+0x10/0x10
[ 1.939560] kernel_init+0x1a/0x1c0
[ 1.939640] ret_from_fork+0x1ed/0x240
[ 1.939730] ? __pfx_kernel_init+0x10/0x10
[ 1.939805] ret_from_fork_asm+0x1a/0x30
[ 1.939886] </TASK>
[ 1.939927] ---[ end trace 0000000000000000 ]---
[ 1.940184] fbnic 0000:01:00.0: Netdev allocation failed
Instead of calling fbnic_phylink_destroy(), the prior initialization of
netdev should just be unrolled with free_netdev() and clearing
fbd->netdev.
Clearing fbd->netdev to NULL avoids UAF in init_failure_mode where
callers guard by checking !fbd->netdev, such as fbnic_mdio_read_pmd().
These callers remain active even after a failed probe, so fdb->netdev
still needs to be cleared.
Fixes: d0fe7104c795 ("fbnic: Replace use of internal PCS w/ Designware XPCS")
Signed-off-by: Bobby Eshleman <bobbyeshleman@meta.com>
---
Changes in v2:
- instead of just clearing fbn->pcs, avoid the UAF by only doing
teardown for netdev when phylink creation fails, avoid
fbnic_phylink_destroy
- clear fbn->netdev to avoid failures in post-probe init_failure_mode
- Link to v1: https://lore.kernel.org/r/20260416-fbnic-pcs-fix-v1-1-ac4b6badeac0@meta.com
---
drivers/net/ethernet/meta/fbnic/fbnic_netdev.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
index c406a3b56b37..4dea2bb58d2f 100644
--- a/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
+++ b/drivers/net/ethernet/meta/fbnic/fbnic_netdev.c
@@ -826,7 +826,8 @@ struct net_device *fbnic_netdev_alloc(struct fbnic_dev *fbd)
netif_tx_stop_all_queues(netdev);
if (fbnic_phylink_create(netdev)) {
- fbnic_netdev_free(fbd);
+ free_netdev(netdev);
+ fbd->netdev = NULL;
return NULL;
}
---
base-commit: bd3a4795d5744f59a1f485379f1303e5e606f377
change-id: 20260416-fbnic-pcs-fix-26dc23c7deae
Best regards,
--
Bobby Eshleman <bobbyeshleman@meta.com>
^ permalink raw reply related
* [PATCH net-next] net: usb: mcs7830: adjust incorrect comment implying a vulnerability
From: Ethan Nelson-Moore @ 2026-05-05 1:46 UTC (permalink / raw)
To: linux-usb, netdev
Cc: Ethan Nelson-Moore, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Andy Shevchenko, Peter Korsgaard
The mcs7830 driver contains a comment indicating that mcs7830_get_regs
leaks uninitialized memory to user space on some devices. If true, this
would indicate a security vulnerability. However, I investigated the
issue and found that it is not true because ethtool_get_regs (in
net/ethtool/ioctl.c) uses vzalloc to allocate its buffer, which zeroes
the memory. Update the comment to explain this behavior.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
drivers/net/usb/mcs7830.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/mcs7830.c b/drivers/net/usb/mcs7830.c
index d6698f30218d..dfdc7bd74166 100644
--- a/drivers/net/usb/mcs7830.c
+++ b/drivers/net/usb/mcs7830.c
@@ -22,7 +22,8 @@
* - implement get_eeprom/[set_eeprom]
* - switch PHY on/off on ifup/ifdown (perhaps in usbnet.c, via MII)
* - mcs7830_get_regs() handling is weird: for rev 2 we return 32 regs,
- * can access only ~ 24, remaining user buffer is uninitialized garbage
+ * can access only ~ 24; this is not a security vulnerability because
+ * ethtool_get_regs allocates a zeroed buffer
* - anything else?
*/
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-next v5 1/2] net: pse-pd: add devm_pse_poll_helper()
From: Jakub Kicinski @ 2026-05-05 1:57 UTC (permalink / raw)
To: github
Cc: Jakub Kicinski, o.rempel, kory.maincent, andrew+netdev, davem,
edumazet, pabeni, krzk, netdev, linux-kernel, linux-leds
In-Reply-To: <20260429213224.1747410-2-github@szelinsky.de>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: pse-pd: add devm_pse_poll_helper()
This patch extracts the common event handling loop from pse_isr() into a
shared function and adds a poll-based alternative for PSE controllers
that lack interrupt support.
> diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
> index 87aa4f4e9724..b7ffec0c942c 100644
> --- a/drivers/net/pse-pd/pse_core.c
> +++ b/drivers/net/pse-pd/pse_core.c
[ ... ]
> @@ -1118,6 +1125,8 @@ void pse_controller_unregister(struct pse_controller_dev *pcdev)
> pse_release_pis(pcdev);
> if (pcdev->irq)
> disable_irq(pcdev->irq);
> + if (pcdev->polling)
> + cancel_delayed_work_sync(&pcdev->poll_work);
Because pse_release_pis() executes kfree(pcdev->pi) before the delayed work
is cancelled, can pse_poll_worker() run concurrently and access the freed
pcdev->pi array inside pse_handle_events() before the cancellation completes?
[ ... ]
> @@ -1356,6 +1403,54 @@ int devm_pse_irq_helper(struct pse_controller_dev *pcdev, int irq,
> }
> EXPORT_SYMBOL_GPL(devm_pse_irq_helper);
>
> +/**
> + * devm_pse_poll_helper - Register poll-based PSE event notifier
> + * @pcdev: a pointer to the PSE controller device
> + * @d: PSE event description (uses same pse_irq_desc as IRQ path)
[ ... ]
> +int devm_pse_poll_helper(struct pse_controller_dev *pcdev,
> + const struct pse_irq_desc *d)
> +{
> + struct device *dev = pcdev->dev;
> +
> + if (!d || !d->map_event || !d->name)
> + return -EINVAL;
> +
> + pcdev->poll_desc = *d;
> + pcdev->poll_notifs = devm_kcalloc(dev, pcdev->nr_lines,
> + sizeof(*pcdev->poll_notifs),
> + GFP_KERNEL);
> + if (!pcdev->poll_notifs)
> + return -ENOMEM;
> +
> + pcdev->poll_notifs_mask = devm_bitmap_zalloc(dev, pcdev->nr_lines,
> + GFP_KERNEL);
> + if (!pcdev->poll_notifs_mask)
> + return -ENOMEM;
> +
> + if (!pcdev->poll_interval_ms)
> + pcdev->poll_interval_ms = PSE_DEFAULT_POLL_INTERVAL_MS;
> +
> + INIT_DELAYED_WORK(&pcdev->poll_work, pse_poll_worker);
> + pcdev->polling = true;
> +
> + queue_delayed_work(system_freezable_wq, &pcdev->poll_work,
> + msecs_to_jiffies(pcdev->poll_interval_ms));
Since memory is allocated with devm_ helpers but no devm cleanup action is
registered to cancel the delayed work, what happens if a driver's probe
function encounters an error after calling this helper? Will devres free the
pcdev structure while the system workqueue still has the delayed work armed,
leading to a use-after-free when the timer expires?
The commit message mentions that drivers typically set up the helper before
registering the controller. If queue_delayed_work() schedules the worker
to run before devm_pse_controller_register() completes, will
pse_poll_worker() attempt to acquire pcdev->lock and push events into
pcdev->ntf_fifo before they are initialized?
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(devm_pse_poll_helper);
^ permalink raw reply
* Re: [PATCH net-next v5 2/2] net: pse-pd: add LED trigger support via notification path
From: Jakub Kicinski @ 2026-05-05 1:57 UTC (permalink / raw)
To: github
Cc: Jakub Kicinski, o.rempel, kory.maincent, andrew+netdev, davem,
edumazet, pabeni, krzk, netdev, linux-kernel, linux-leds
In-Reply-To: <20260429213224.1747410-3-github@szelinsky.de>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: pse-pd: add LED trigger support via notification path
This commit adds per-PI LED triggers to the PSE core subsystem to reflect
delivering and enabled states. The LED state is updated during hardware
events and administrative state changes via ethtool.
Link: https://lore.kernel.org/oe-kbuild-all/202603251254.o5PqMBRU-lkp@intel.com/
Link: https://lore.kernel.org/oe-kbuild-all/202603251250.cuMCk5Yv-lkp@intel.com/
> diff --git a/drivers/net/pse-pd/pse_core.c b/drivers/net/pse-pd/pse_core.c
> index b7ffec0c942c..bff97211ae22 100644
> --- a/drivers/net/pse-pd/pse_core.c
> +++ b/drivers/net/pse-pd/pse_core.c
[ ... ]
> @@ -669,6 +670,168 @@ static int _pse_pi_delivery_power_sw_pw_ctrl(struct pse_controller_dev *pcdev,
> return 0;
> }
>
> +#if IS_ENABLED(CONFIG_LEDS_TRIGGERS)
[ ... ]
> +static int pse_led_triggers_register(struct pse_controller_dev *pcdev)
> +{
> + struct device *dev = pcdev->dev;
> + const char *dev_id;
> + int i, ret;
> +
> + dev_id = dev_name(dev);
> +
> + pcdev->pi_led_trigs = devm_kcalloc(dev, pcdev->nr_lines,
> + sizeof(*pcdev->pi_led_trigs),
> + GFP_KERNEL);
Since devm resources are released in strict LIFO order, and pi_led_trigs
is allocated here after the regulators are registered in
pse_controller_register(), will the pi_led_trigs array be freed before
the regulators are unregistered on driver unbind?
When the regulator core later unregisters the regulators and flushes
pending disables, could it invoke pse_pi_disable() and call pse_led_update(),
dereferencing the dangling pcdev->pi_led_trigs pointer?
> + if (!pcdev->pi_led_trigs)
> + return -ENOMEM;
> +
> + for (i = 0; i < pcdev->nr_lines; i++) {
> + struct pse_pi_led_triggers *trigs = &pcdev->pi_led_trigs[i];
> +
> + /* Skip PIs not described in device tree */
> + if (!pcdev->no_of_pse_pi && !pcdev->pi[i].np)
> + continue;
> +
> + trigs->delivering.name = devm_kasprintf(dev, GFP_KERNEL,
> + "pse-%s:port%d:delivering",
> + dev_id, i);
> + if (!trigs->delivering.name)
> + return -ENOMEM;
> + trigs->delivering.activate = pse_led_delivering_activate;
> +
> + ret = devm_led_trigger_register(dev, &trigs->delivering);
Regulators are exposed before this code runs in pse_controller_register().
What happens if a consumer calls regulator_enable() concurrently?
If a concurrent pse_pi_enable() calls pse_led_update() right after
trigs->delivering.name is set but before devm_led_trigger_register() executes:
pse_led_update() sees pcdev->pi_led_trigs and trigs->delivering.name are
both non-NULL, and proceeds to call led_trigger_event().
Since devm_led_trigger_register() hasn't initialized the trigger's internal
led_cdevs list head yet, will led_trigger_event() attempt to iterate a
zeroed memory list and cause a NULL pointer dereference?
> + if (ret) {
> + trigs->delivering.name = NULL;
> + return ret;
> + }
[ ... ]
> @@ -1107,6 +1273,31 @@ int pse_controller_register(struct pse_controller_dev *pcdev)
> if (ret)
> return ret;
>
> + ret = pse_led_triggers_register(pcdev);
> + if (ret) {
> + /* LED triggers are non-essential for power delivery; warn
> + * and continue. NULL out the array so pse_led_update()'s
> + * early-return guard short-circuits any later calls onto
> + * partially-registered triggers.
> + */
> + dev_warn(pcdev->dev, "Failed to register LED triggers: %d\n",
> + ret);
> + pcdev->pi_led_trigs = NULL;
> + }
If pse_led_triggers_register() fails halfway through, the device probe still
succeeds, which means devm cleanup will not run. Could the successfully
registered LED triggers from earlier loop iterations remain registered
indefinitely with the LED subsystem?
Since pcdev->pi_led_trigs is NULLed, pse_led_update() will short-circuit.
Does this leave these globally visible triggers permanently orphaned without
ever receiving state updates?
> +
> + /* Query initial LED state for all PIs so already-active ports
> + * are reflected immediately without waiting for a hardware event.
> + * Hold pcdev->lock: regulators are already exposed and a
> + * concurrent regulator_enable() would race on the hw callbacks
> + * and on last_delivering / last_enabled.
> + */
> + mutex_lock(&pcdev->lock);
[ ... ]
> @@ -1267,7 +1458,14 @@ static void pse_handle_events(struct pse_controller_dev *pcdev,
> struct pse_ntf ntf = {};
> int ret;
>
> - /* Do nothing PI not described */
> + /* Update LEDs for described PIs regardless of consumer state.
> + * LED triggers are registered at controller init, before any
> + * PHY claims a PSE control, so rdev may still be NULL here.
> + */
> + if (pcdev->no_of_pse_pi || pcdev->pi[i].np)
> + pse_led_update(pcdev, i);
The docstring for pse_led_update() requires it to be called with pcdev->lock
held. Does calling it here locklessly inside the event handler violate
that locking contract?
Could this lack of synchronization cause data races on the cached state
variables, or allow concurrent execution of the hardware callbacks
(pi_get_pw_status and pi_get_admin_state) if they are invoked at the same
time by other paths?
> +
> + /* Skip regulator/netlink path for PIs without consumers */
> if (!pcdev->pi[i].rdev)
> continue;
^ permalink raw reply
* Re: [PATCH net-next V2 7/7] net/mlx5: Add profile to auto-enable switchdev mode at device init
From: Mark Bloch @ 2026-05-05 2:00 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Tariq Toukan, Eric Dumazet, Paolo Abeni, Andrew Lunn,
David S. Miller, Leon Romanovsky, Jason Gunthorpe, Saeed Mahameed,
Shay Drory, Or Har-Toov, Edward Srouji, Maher Sanalla,
Simon Horman, Gerd Bayer, Moshe Shemesh, Kees Cook,
Patrisious Haddad, Parav Pandit, Carolina Jubran, Cosmin Ratiu,
linux-rdma, linux-kernel, netdev, Gal Pressman, Dragos Tatulea
In-Reply-To: <20260504182122.08efb41e@kernel.org>
On 05/05/2026 4:21, Jakub Kicinski wrote:
> On Sun, 3 May 2026 10:51:06 +0300 Mark Bloch wrote:
>> On 03/05/2026 4:41, Jakub Kicinski wrote:
>>> On Sat, 2 May 2026 23:08:43 +0300 Mark Bloch wrote:
>>>> Before I respin for the unrelated MR_CACHE cleanup, I’d like to confirm
>>>> whether the opt-in profile approach is acceptable at all. Regardless
>>>> of this last patch, the first 6 patches fix real representor/LAG locking
>>>> issues and are needed independently, so I’d like to keep those moving toward
>>>> acceptance as soon as possible.
>>>
>>> For probe-time config module param is probably our only option.
>>> I'd obviously prefer to have a devlink-level knob for this, instead
>>> of a mlx5 specific one. Can we come up with some format that'd apply
>>> more broadly? devlink=[$bfd:]flag1 ? so devlink=[$bdf:]switchdev-mode ?
>>
>> I’m not convinced this is really a generic devlink knob problem.
>
> I'm surprised you say that. Anyone using switchdev mode could benefit.
> Having the probe in one mode and switch adds to boot time. Whether it's
> a DPU or not is quite secondary.
>
> Unless there's another deeper reason which makes the DPU incapable of
> running in the non-switchdev mode. But not sure that squares with the
> code you posted AFAICT.
No, there is no deeper DPU limitation. The device can probe in
non switchdev mode, this is only about the desired default for those
deployments, and avoiding the extra boot-time cost of probing in one mode
and then switching to another.
What I meant is that I am wary of putting too much policy into the kernel
command line. A generic devlink level switchdev probe mode knob sounds
reasonable to me if we keep the scope narrow. More complex policy, such as
changing multiple defaults still seems better handled by userspace.
Would adding only switchdev/switchdev_inactive for now be acceptable?
I will try to keep the code generic enough so it can be extended later if
we want.
Let's continue with v3 as posted and please give me a few days to put
together an RFC for the devlink part.
Mark
>
>> A device should probe in its selected/default configuration. For DPU
>> deployments switchdev is the expected operating mode. mlx5 just made the
>> wrong default choice historically, and this profile is a way to move away
>> from that without forcing it on everyone at once. I expect/hope to move
>> quickly from this flag to simply making switchdev the driver default for
>> all DPU configs.
>>
>> A generic cmdline format also gets complicated quickly: vendor-specific
>> flags, ordering/dependencies between flags, hotplug timing, and whether a
>> BDF rule should apply when a device is passed into a VM after boot.
>> Userspace scripts are probably better for that kind of policy because
>> they can carry real site specific logic.
>>
>> I’ll drop this last patch from the series for now so the representor/LAG
>> locking fixes can move independently and we can continue the default
>> switchdev discussion separately. I can always submit that as a standalone
>> patch later in the cycle if needed.
>
> SG
^ permalink raw reply
* Re: [PATCH v1 net] af_unix: Set gc_in_progress to true in unix_gc().
From: patchwork-bot+netdevbpf @ 2026-05-05 2:00 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: davem, edumazet, kuba, pabeni, horms, kuni1840, netdev,
sysroot314
In-Reply-To: <20260501073945.1884564-1-kuniyu@google.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 1 May 2026 07:39:41 +0000 you wrote:
> Igor Ushakov reported that unix_gc() could run with gc_in_progress
> being false if the work is scheduled while running:
>
> Thread 1 Thread 2 Thread 3
> -------- -------- --------
> unix_schedule_gc() unix_schedule_gc()
> `- if (!gc_in_progress) `- if (!gc_in_progress)
> |- gc_in_progress = true |
> `- queue_work() |
> unix_gc() <----------------/ |
> | |- gc_in_progress = true
> ... `- queue_work()
> | |
> `- gc_in_progress = false |
> |
> unix_gc() <---------------------------------------------'
> |
> ... /* gc_in_progress == false */
> |
> `- gc_in_progress = false
>
> [...]
Here is the summary with links:
- [v1,net] af_unix: Set gc_in_progress to true in unix_gc().
https://git.kernel.org/netdev/net/c/d82ba05263c6
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] netpoll: pass buffer size to egress_dev() to avoid MAC truncation
From: patchwork-bot+netdevbpf @ 2026-05-05 2:00 UTC (permalink / raw)
To: Breno Leitao
Cc: davem, edumazet, kuba, pabeni, horms, ushankar, netdev,
linux-kernel, clm, kernel-team, stable
In-Reply-To: <20260501-netpoll_snprintf_fix-v1-1-84b0566e6597@debian.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 01 May 2026 02:58:41 -0700 you wrote:
> egress_dev() formats np->dev_mac via snprintf() but receives buf as
> a bare char *, so it cannot derive the buffer size from the pointer. The
> size argument was hardcoded to MAC_ADDR_STR_LEN (3 * ETH_ALEN - 1 = 17),
> which is silly wrong in two ways:
>
> 1) misleading kernel log output on the MAC-selected target path
> (np->dev_name[0] == '\0'); for example "aa:bb:cc:dd:ee:ff doesn't
> exist, aborting" was logged as "aa:bb:cc:dd:ee:f doesn't exist,
> aborting".
>
> [...]
Here is the summary with links:
- [net] netpoll: pass buffer size to egress_dev() to avoid MAC truncation
https://git.kernel.org/netdev/net/c/76b93a810757
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/sched: taprio: prepare taprio_dump() for RTNL removal
From: patchwork-bot+netdevbpf @ 2026-05-05 2:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, kuba, pabeni, horms, jhs, jiri, netdev, eric.dumazet
In-Reply-To: <20260501064247.2027688-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 1 May 2026 06:42:47 +0000 you wrote:
> We soon will no longer hold RTNL in qdisc dumps.
>
> Add READ_ONCE()/WRITE_ONCE() annotations.
>
> Note: taprio already uses RCU to protect most of its fields.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
>
> [...]
Here is the summary with links:
- [net-next] net/sched: taprio: prepare taprio_dump() for RTNL removal
https://git.kernel.org/netdev/net-next/c/c4994aee0292
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v3 1/1] net: phy: realtek: Add support for PHY LEDs on RTL8221B
From: patchwork-bot+netdevbpf @ 2026-05-05 2:00 UTC (permalink / raw)
To: Chukun Pan
Cc: davem, andrew, pabeni, kuba, edumazet, linux, daniel, hkallweit1,
linux-kernel, netdev
In-Reply-To: <20260501100002.755672-1-amadeus@jmu.edu.cn>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 1 May 2026 18:00:02 +0800 you wrote:
> Realtek RTL8221B Ethernet PHY supports three LED pins which are used to
> indicate link status and activity. Add netdev trigger support for them.
>
> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> ---
> Changes in v3:
> - In led_hw_control_set, reset the LED polarity to default.
> - Link to v2: https://lore.kernel.org/all/20260420100800.2435204-1-amadeus@jmu.edu.cn/
> Changes in v2:
> - Invert the LED polarity in led_brightness_set to achieve LED_ON.
> - Link to v1: https://lore.kernel.org/all/20260401100010.3079700-1-amadeus@jmu.edu.cn/
>
> [...]
Here is the summary with links:
- [v3,1/1] net: phy: realtek: Add support for PHY LEDs on RTL8221B
https://git.kernel.org/netdev/net-next/c/d3aae4d954f9
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 v6 0/5] net: bridge: mcast: support exponential field encoding
From: Jakub Kicinski @ 2026-05-05 2:09 UTC (permalink / raw)
To: Ujjal Roy
Cc: David S . Miller, Eric Dumazet, Paolo Abeni, Simon Horman,
Nikolay Aleksandrov, Ido Schimmel, David Ahern, Shuah Khan,
Andy Roulin, Yong Wang, Petr Machata, Ujjal Roy, bridge, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260502131907.987-1-royujjal@gmail.com>
On Sat, 2 May 2026 13:19:01 +0000 Ujjal Roy wrote:
> - Added Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
You don't have to repost just to add tags.
Our tooling will pick them up when applying the series.
^ permalink raw reply
* Re: [RFC PATCH 0/1] Proposal for in-band firmware update over PLDM-MCTP
From: Jeremy Kerr @ 2026-05-05 2:15 UTC (permalink / raw)
To: Badal Nilawar, dri-devel, intel-xe, netdev, linux-kernel
Cc: rodrigo.vivi, wojciech.drewek, michael.brooks, heikki.krogerus,
michael.j.ruhl, thomas.hellstrom, michal.winiarski,
anshuman.gupta, jacob.e.keller, maarten.lankhorst, matthew.brost,
anthony.l.nguyen, przemyslaw.kitszel, mika.westerberg,
andriy.shevchenko, singaravelan.nallasellan, kelvin.gardiner,
matt, andrew+netdev, davem, edumazet, kuba, pabeni, james.ausmus
In-Reply-To: <20260504193420.1232842-3-badal.nilawar@intel.com>
Hi Badal,
Thanks for sending this RFC through! It's good to have some early input
on the structure here.
> Problem statement:
This is exceptionally verbose for "we would like to add a MCTP transport
driver". :)
> Option 1: MCTP Transport as Part of drivers/gpu/drm/xe Subsystem
This sounds like the best approach to me. The MCTP transport drivers in
drivers/net/mctp are intended to be fairly hardware-agnostic, and all
are spec compliant. I see no issue with having your own code do a
mctp_register_netdev() from elsewhere in the tree.
I'll also reply on 1/1 with some implementation comments.
> Note: This RFC is prepared with AI assistance (e.g. GitHub Copilot etc).
Then please ensure you have read
Documentation/process/coding-assistants.rst, as you are missing the
Attribution requirements from that.
Cheers,
Jeremy
^ 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