* Re: [PATCH net-next 02/12] net: pcs: pcs-xpcs: select operating mode for 10G-baseR capable PCS
From: Daniel Thompson @ 2026-05-05 15:58 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alex Elder, andrew+netdev, davem, edumazet, kuba, pabeni,
maxime.chevallier, rmk+kernel, andersson, konradybcio, robh,
krzk+dt, conor+dt, linusw, brgl, arnd, gregkh, mohd.anwar,
a0987203069, alexandre.torgue, ast, boon.khai.ng, chenchuangyu,
chenhuacai, daniel, hawk, hkallweit1, inochiama, john.fastabend,
julianbraha, livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <f9a581a2-02ea-4948-8c97-835cb7638b1d@lunn.ch>
On Fri, May 01, 2026 at 06:50:45PM +0200, Andrew Lunn wrote:
> > +static int xpcs_config_operating_mode(struct dw_xpcs *xpcs, int an_mode)
> > +{
> > + int mdio_stat2, ret;
> > +
> > + switch (an_mode) {
> > + case DW_AN_C37_SGMII:
> > + case DW_AN_C37_1000BASEX:
> > + case DW_2500BASEX:
> > + mdio_stat2 = xpcs_read(xpcs, MDIO_MMD_PCS, MDIO_STAT2);
> > + if (mdio_stat2 < 0)
> > + return mdio_stat2;
> > +
> > + /*
> > + * If this XPCS supports 10Gbase-R then it will be the default
> > + * which prevents 1000base-X and slower from working correctly.
>
> It would be interesting to know if Toshiba messed up the integration
> of the PCS, or there is an errata for the licensed IP.
I'm afraid I don't know, but it looks like the issue is not unique to
Toshiba!
This is a discovery which, rather to my chagrin, I only made after we
posted the patches (thanks to a hint from Sashiko): there is similar
code in txgbe_xpcs_switch_mode(). I cleary overlooked that when I
originally reviewed the existing XPCS code. I suspect I stopped
scanning that code path due to the PMA related conditional branch...
Regardless of how I missed it, txgbe_xpcs_switch_mode() implements
similar logic to this patch. I think it is using MDIO_PCS_CTRL2_10GBX as
the Reserved value but otherwise looks similar. There are comments that
imply 10Gbase-X isn't implemented by their XPCS which would make
MDIO_PCS_CTRL2_10GBX reserved (but are too vague to be 100% sure).
Right now it looks like xpcs_switch_interface_mode() and my
xpcs_config_operating_mode() are more closely related than I realized
so I plan to move my code into xpcs_switch_interface_mode().
I don't think I can unify the Wangxun and Toshiba code (the waits and
resets in the Wangxun code make that too high risk) but I'm not yet
ready to give up and just make the Toshiba changes into another vendor
quirk!
Daniel.
^ permalink raw reply
* Re: [PATCH net 2/5] net: dsa: mt7530: preserve VLAN tags on trapped link-local frames
From: Daniel Golle @ 2026-05-05 16:03 UTC (permalink / raw)
To: Chester A. Unal
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, DENG Qingfang, Florian Fainelli,
Arınç ÜNAL, Sean Wang, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <46071c08-d85f-4157-9d61-6a0feef56747@arinc9.com>
On Tue, May 05, 2026 at 03:37:29PM +0000, Chester A. Unal wrote:
> Hey Daniel.
>
> On 05/05/2026 15:16, Daniel Golle wrote:
> > The BPC, RGAC1 and RGAC2 registers control the handling of link-local
> > frames with reserved MAC DAs (01:80:C2:00:00:0x). These frames are
> > correctly trapped to the CPU port, but the egress VLAN tag attribute was
> > set to MT7530_VLAN_EG_UNTAGGED which causes the switch to strip any
> > VLAN tags from trapped frames before they reach the CPU.
> >
> > This causes VLAN-tagged link-local frames (STP BPDUs, LLDP, PTP Peer
> > Delay Requests) to arrive at the CPU without their VLAN tag, so they
> > are delivered to the base network interface instead of the VLAN
> > sub-interface. The DSA local_termination selftest confirms this: all
> > link-local protocol tests on VLAN upper interfaces fail.
> >
> > Set the EG_TAG attribute to MT7530_VLAN_EG_DISABLED (system default)
> > so that the switch does not modify VLAN tags in trapped frames. This
> > way VLAN-tagged frames retain their original tag and are delivered to
> > the correct VLAN sub-interface, matching the behavior of non-trapped
> > frames which pass through without VLAN tag modification.
> >
> > Fixes: 69ddba9d170b ("net: dsa: mt7530: fix handling of all link-local frames")
> > Signed-off-by: Daniel Golle <daniel@makrotopia.org>
>
> Thank you for this patch. Could you please confirm that it conforms to the
> findings documented on this patch log?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=e8bf353577f382c7066c661fed41b2adc0fc7c40
Yes. Combining VLAN CTAG and DSA tag into single "mess" tag is what the
MT7530 hardware does, and also what tag_mtk.c expects, and mtk_eth_soc
"special tag" feature handles well.
I've found, addressed and verified all the issues in the series using
the DSA selftests in tools/testing/selftest/drivers/net/dsa, ie. running
bridge_vlan_aware.sh, bridge_vlan_unaware.sh and local_termination.sh
in a loop, and random order, on BPi-R3 (MT7531) and BPi-R4 (MT7988).
With the series applied many of the previously failing tests are now
passing.
^ permalink raw reply
* Re: [PATCH 09/11] vfio: selftests: Add mlx5 driver - HW init and command interface
From: David Matlack @ 2026-05-05 16:03 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alex Williamson, kvm, Leon Romanovsky, linux-kselftest,
linux-rdma, Mark Bloch, netdev, Saeed Mahameed, Shuah Khan,
Tariq Toukan, patches
In-Reply-To: <afoQtL6gEN2wUba7@nvidia.com>
On Tue, May 5, 2026 at 8:46 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> On Mon, May 04, 2026 at 10:35:43PM +0000, David Matlack wrote:
> > On 2026-04-30 09:08 PM, Jason Gunthorpe wrote:
> >
> > > +/*
> > > + * Driver state — overlaid on device->driver.region.vaddr.
> > > + *
> > > + * Contains both software-only state and HW-visible DMA buffers. HW buffers need
> > > + * strict IOVA alignment.
> > > + */
> > > +struct mlx5st_device {
> >
> > Can we do s/mlx5st/mlx5/ on the series?
>
> No, I don't want to do this. Since it is in tree I want to reserve the
> mlx5_ prefix only for the main driver. The driver is huge, I do not
> want to harm or confuse grep - that team will get mad.
git-grep can be scoped to directories, but ok let's keep mlx5st to
avoid disrupting anyone's workflow.
^ permalink raw reply
* Re: [PATCH 07/11] vfio: selftests: Allow drivers to specify required region size
From: David Matlack @ 2026-05-05 16:05 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Alex Williamson, kvm, Leon Romanovsky, linux-kselftest,
linux-rdma, Mark Bloch, netdev, Saeed Mahameed, Shuah Khan,
Tariq Toukan, patches
In-Reply-To: <afoSQWreOWDIfVxZ@nvidia.com>
On Tue, May 5, 2026 at 8:52 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
>
> On Mon, May 04, 2026 at 08:55:58PM +0000, David Matlack wrote:
> > On 2026-04-30 09:08 PM, Jason Gunthorpe wrote:
> > > Add a region_size field to struct vfio_pci_driver_ops so drivers can
> > > declare how much DMA-mapped region they need. The mlx5 driver will
> > > need ~18MB for firmware pages. Existing drivers leave region_size as
> > > 0 and get the current default of SZ_2M.
> >
> > I would like to get rid of the magic SZ_2M to make it easier for other
> > tests to use the driver framework. Can you make this commit update all
> > the drivers to set region_size? They can all use the same approach:
> >
> > struct vfio_pci_driver_ops foo_driver = {
> > ...
> > .region_size = roundup_pow_of_two(sizeof(struct foo)),
> > ...
> > };
>
> Sure, lets put the roundup in the core code?
Sounds good.
^ permalink raw reply
* Re: [PATCH v1] gve: Use generic power management
From: Alexander Lobakin @ 2026-05-05 16:08 UTC (permalink / raw)
To: Vaibhav Gupta
Cc: Joshua Washington, Harshitha Ramamurthy, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Willem de Bruijn, Ankit Garg, Tim Hostetler, Alok Tiwari,
John Fraker, Matt Olson, Praveen Kaligineedi, netdev,
linux-kernel
In-Reply-To: <20260504182139.604925-1-vaibhavgupta40@gmail.com>
From: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Date: Mon, 4 May 2026 18:21:32 +0000
> Switch to the generic power management and remove the usage of legacy
> (pci_driver) hooks.
>
> Signed-off-by: Vaibhav Gupta <vaibhavgupta40@gmail.com>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
> drivers/net/ethernet/google/gve/gve_main.c | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH net v4 3/4] bonding: 3ad: fix mux port state on oper down
From: Louis Scalbert @ 2026-05-05 16:10 UTC (permalink / raw)
To: Jay Vosburgh
Cc: netdev, stephen, andrew+netdev, edumazet, kuba, pabeni, fbl, andy,
shemminger, maheshb
In-Reply-To: <1142168.1776974419@famine>
Hello Jay,
Sorry for the late reply. I’ve been busy with another project these
past few days.
Le jeu. 23 avr. 2026 à 22:00, Jay Vosburgh <jv@jvosburgh.net> a écrit :
>
> Louis Scalbert <louis.scalbert@6wind.com> wrote:
>
> >When the bonding interface has carrier down due to the absence of
> >usable slaves and a slave transitions from down to up, the bonding
> >interface briefly goes carrier up, then down again, and finally up
> >once LACP negotiates collecting and distributing on the port.
> >
> >When lacp_strict mode is on, the interface should not transition to
> >carrier up until LACP negotiation is complete.
> >
> >This happens because the actor and partner port states remain in
> >Collecting_Distributing when the port goes down. When the port
> >comes back up, it temporarily remains in this state until LACP
> >renegotiation occurs.
> >
> >Previously this was mostly cosmetic, but since the bonding carrier
> >state may depend on the LACP negotiation state, it causes the
> >interface to flap.
> >
> >Move an operationally down port to the Mux WAITING state and clear the
> >Synchronization, Collecting, and Distributing states, in accordance with
> >the 802.1AX Mux state machine diagram.
> >
> >Fixes: 655f8919d549 ("bonding: add min links parameter to 802.3ad")
> >Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
> >---
> > drivers/net/bonding/bond_3ad.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> >diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> >index 9cf064243d58..bc2964ea11f5 100644
> >--- a/drivers/net/bonding/bond_3ad.c
> >+++ b/drivers/net/bonding/bond_3ad.c
> >@@ -1053,6 +1053,8 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> >
> > if (port->sm_vars & AD_PORT_BEGIN) {
> > port->sm_mux_state = AD_MUX_DETACHED;
> >+ } else if (!port->is_enabled && port->sm_mux_state != AD_MUX_DETACHED) {
> >+ port->sm_mux_state = AD_MUX_WAITING;
>
> Technically, this is not exactly following the state machines.
>
> The mux machine should transition to WAITING from DETACHED when
> Selected == SELECTED or STANDBY, not for !is_enabled ("port_enabled" in
> the standard).
The MUX machine still transitions from DETACHED to WAITING; this
happens a few lines later and is unchanged.
The relevant code is:
} else if (!port->is_enabled && port->sm_mux_state != AD_MUX_DETACHED) {
port->sm_mux_state = AD_MUX_WAITING;
} else {
switch (port->sm_mux_state) {
case AD_MUX_DETACHED:
if ((port->sm_vars & AD_PORT_SELECTED)
|| (port->sm_vars & AD_PORT_STANDBY))
/* if SELECTED or STANDBY */
port->sm_mux_state = AD_MUX_WAITING;
break;
My change is for NOT is_enabled AND NOT AD_MUX_DETACHED.
> The check for !is_enabled happens in the receive
> machine, and it would transition to PORT_DISABLED state (which clears
> Synchronization).
I agree with that statement. However, clearing Synchronization is not
sufficient: the purpose of the fix is to clear Collecting and
Distributing.
I noticed that is_enabled is defined in the 802.3ad-2000 standard, while
Port_Operational is defined in 802.1AX-2020. I am not sure about
802.1AX-2014, as I do not have access to that version.
The 802.1AX-2020 standard uses a different MUX state diagram. Compared to
802.3ad, the ATTACHED state has been split into ATTACH and ATTACHED.
There is no longer a WAITING state; it has been replaced by
ATTACHED_WTR.
The new standard says that the MUX machine should transition to
ATTACHED_WTR when Port_Operational is FALSE and the current state is
not DETACHED.
So, in my opinion, the change is correct, at least with respect to
802.1AX-2020.
>
> I'm not sure if this is actually an issue or not; I need to read
> the relevant bits again to make sure I understand how it's supposed to
> work.
Please confirm what you want me to do: should I keep the fix as it is ?
best regards,
Louis Scalbert
>
> -J
>
> > } else {
> > switch (port->sm_mux_state) {
> > case AD_MUX_DETACHED:
> >@@ -1200,6 +1202,11 @@ static void ad_mux_machine(struct port *port, bool *update_slave_arr)
> > break;
> > case AD_MUX_WAITING:
> > port->sm_mux_timer_counter = __ad_timer_to_ticks(AD_WAIT_WHILE_TIMER, 0);
> >+ port->actor_oper_port_state &= ~LACP_STATE_SYNCHRONIZATION;
> >+ ad_disable_collecting_distributing(port,
> >+ update_slave_arr);
> >+ port->actor_oper_port_state &= ~LACP_STATE_COLLECTING;
> >+ port->actor_oper_port_state &= ~LACP_STATE_DISTRIBUTING;
> > break;
> > case AD_MUX_ATTACHED:
> > if (port->aggregator->is_active)
> >--
> >2.39.2
> >
>
> ---
> -Jay Vosburgh, jv@jvosburgh.net
^ permalink raw reply
* Re: [PATCH net] vsock/virtio: fix potential unbounded skb queue
From: Stefano Garzarella @ 2026-05-05 16:11 UTC (permalink / raw)
To: Eric Dumazet, Arseniy Krasnov, Bobby Eshleman, Stefan Hajnoczi,
Michael S. Tsirkin
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
netdev, eric.dumazet, Arseniy Krasnov, Stefan Hajnoczi,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
kvm, virtualization
In-Reply-To: <CANn89iLs8DOWJwDpf_ARoMrV+6b2tbhEJ=VVzeC8gCm5dRGaig@mail.gmail.com>
On Tue, May 05, 2026 at 07:14:36AM -0700, Eric Dumazet wrote:
>On Tue, May 5, 2026 at 6:52 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>>
>> On Thu, Apr 30, 2026 at 12:26:52PM +0000, Eric Dumazet wrote:
>> >virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
>> >
>> >virtio_transport_recv_enqueue() skips coalescing for packets
>> >with VIRTIO_VSOCK_SEQ_EOM.
>> >
>> >If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
>> >a very large number of packets can be queued
>> >because vvs->rx_bytes stays at 0.
>> >
>> >Fix this by estimating the skb metadata size:
>> >
>> > (Number of skbs in the queue) * SKB_TRUESIZE(0)
>> >
>> >Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
>> >Signed-off-by: Eric Dumazet <edumazet@google.com>
>> >Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>> >Cc: Stefan Hajnoczi <stefanha@redhat.com>
>> >Cc: Stefano Garzarella <sgarzare@redhat.com>
>> >Cc: "Michael S. Tsirkin" <mst@redhat.com>
>> >Cc: Jason Wang <jasowang@redhat.com>
>> >Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
>> >Cc: "Eugenio Pérez" <eperezma@redhat.com>
>> >Cc: kvm@vger.kernel.org
>> >Cc: virtualization@lists.linux.dev
>> >---
>> > net/vmw_vsock/virtio_transport_common.c | 4 +++-
>> > 1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> >diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
>> >index 416d533f493d7b07e9c77c43f741d28cfcd0953e..9b8014516f4fb1130ae184635fbba4dfee58bd64 100644
>> >--- a/net/vmw_vsock/virtio_transport_common.c
>> >+++ b/net/vmw_vsock/virtio_transport_common.c
>> >@@ -447,7 +447,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
>> > static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
>> > u32 len)
>> > {
>> >- if (vvs->buf_used + len > vvs->buf_alloc)
>> >+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
>> >+
>> >+ if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc)
>> > return false;
>>
>> I'm not sure about this fix, I mean that maybe this is incomplete.
>> In virtio-vsock, there is a credit mechanism between the two peers:
>> https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-4850003
>>
>> This takes only the payload into account, so it’s true that this problem
>> exists; however, perhaps we should also inform the other peer of a lower
>> credit balance, otherwise the other peer will believe it has much more
>> credit than it actually does, send a large payload, and then the packet
>> will be discarded and the data lost (there are no retransmissions,
>> etc.).
>
>I dunno, perhaps revert 077706165717 ("virtio/vsock: don't use skbuff
>state to account credit")
>and find a better fix then?
IIRC the same issue was there before the commit fixed by that one
(commit 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with
sk_buff")), so not sure about reverting it TBH.
CCing Arseniy and Bobby.
>
>There is always a discrepancy between skb->len and skb->truesize.
>You will not be able to announce a 1MB window, and accept one milliion
>skb of 1-byte each.
>
>This kind of contract is broken.
>
Yep, I agree, but before we start discarding data (and losing it), IMHO
we should at least inform the other peer that we're out of space.
@Stefan, @Michael, do you think we can do something in the spec to avoid
this issue and in some way take into account also the metadata in the
credit. I mean to avoid the 1-byte packets flooding.
Thanks,
Stefano
^ permalink raw reply
* Re: [PATCH net v7 1/2] ipv6: flowlabel: take ip6_fl_lock across mem_check and fl_intern
From: Willem de Bruijn @ 2026-05-05 16:11 UTC (permalink / raw)
To: Maoyi Xie, David S . Miller
Cc: Jakub Kicinski, Paolo Abeni, Eric Dumazet, David Ahern,
Alexey Kuznetsov, Willem de Bruijn, Willem de Bruijn, netdev,
linux-kernel, stable
In-Reply-To: <20260505072015.1672730-2-maoyi.xie@ntu.edu.sg>
Maoyi Xie wrote:
> mem_check() in net/ipv6/ip6_flowlabel.c reads fl_size without
> holding ip6_fl_lock. fl_intern() takes the lock immediately
> afterwards. The two checks therefore race against concurrent
> fl_intern, ip6_fl_gc and ip6_fl_purge writers, which makes the
> mem_check budget check approximate.
>
> Move spin_lock_bh(&ip6_fl_lock) and the matching unlock from
> fl_intern() into its only caller ipv6_flowlabel_get(). The
> mem_check() call now runs under the same critical section as the
> fl_intern() insert, so the budget check is exact.
>
> With all writers and the read of fl_size under ip6_fl_lock,
> convert fl_size from atomic_t to plain int. The four sites that
> update or read fl_size are fl_intern (insert path), ip6_fl_gc
> (garbage collector, the !sched check and the per-entry decrement),
> ip6_fl_purge (per-netns purge), and mem_check (budget check), and
> all four now run under ip6_fl_lock.
>
> This is a prerequisite for adding a per-netns budget alongside
> fl_size. The follow-up patch adds netns_ipv6::flowlabel_count and
> folds it into mem_check().
>
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Suggested-by: Willem de Bruijn <willemb@google.com>
> Signed-off-by: Maoyi Xie <maoyi.xie@ntu.edu.sg>
Please update either your git config name or Signed-off-by to make
sure that the two are the same. Not sure whether that requires a
respin.
With those asides
Reviewed-by: Willem de Bruijn <willemb@google.com>
Thanks for fixing this along with your main fix.
> ---
> net/ipv6/ip6_flowlabel.c | 33 ++++++++++++++++++++-------------
> 1 file changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
> index c92f98c6f..43b5e9ce9 100644
> --- a/net/ipv6/ip6_flowlabel.c
> +++ b/net/ipv6/ip6_flowlabel.c
> @@ -40,7 +40,7 @@
> #define FL_HASH_MASK 255
> #define FL_HASH(l) (ntohl(l)&FL_HASH_MASK)
>
> -static atomic_t fl_size = ATOMIC_INIT(0);
> +static int fl_size;
> static struct ip6_flowlabel __rcu *fl_ht[FL_HASH_MASK+1];
>
> static void ip6_fl_gc(struct timer_list *unused);
> @@ -163,7 +163,7 @@ static void ip6_fl_gc(struct timer_list *unused)
> if (time_after_eq(now, ttd)) {
> *flp = fl->next;
> fl_free(fl);
> - atomic_dec(&fl_size);
> + fl_size--;
> continue;
> }
> if (!sched || time_before(ttd, sched))
> @@ -172,7 +172,7 @@ static void ip6_fl_gc(struct timer_list *unused)
> flp = &fl->next;
> }
> }
> - if (!sched && atomic_read(&fl_size))
> + if (!sched && fl_size)
> sched = now + FL_MAX_LINGER;
> if (sched) {
> mod_timer(&ip6_fl_gc_timer, sched);
> @@ -196,7 +196,7 @@ static void __net_exit ip6_fl_purge(struct net *net)
> atomic_read(&fl->users) == 0) {
> *flp = fl->next;
> fl_free(fl);
> - atomic_dec(&fl_size);
> + fl_size--;
> continue;
> }
> flp = &fl->next;
> @@ -205,6 +205,7 @@ static void __net_exit ip6_fl_purge(struct net *net)
> spin_unlock_bh(&ip6_fl_lock);
> }
>
> +/* Caller must hold ip6_fl_lock. */
nit: lockdep_assert_held as used below is preferable over comments
> @@ -464,10 +459,14 @@ fl_create(struct net *net, struct sock *sk, struct in6_flowlabel_req *freq,
>
> static int mem_check(struct sock *sk)
> {
> - int room = FL_MAX_SIZE - atomic_read(&fl_size);
> + int room;
> struct ipv6_fl_socklist *sfl;
> int count = 0;
>
> + lockdep_assert_held(&ip6_fl_lock);
> +
> + room = FL_MAX_SIZE - fl_size;
> +
> if (room > FL_MAX_SIZE - FL_MAX_PER_SOCK)
> return 0;
>
^ permalink raw reply
* Re: [PATCH net 2/5] net: dsa: mt7530: preserve VLAN tags on trapped link-local frames
From: Chester A. Unal @ 2026-05-05 16:12 UTC (permalink / raw)
To: Daniel Golle
Cc: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Matthias Brugger,
AngeloGioacchino Del Regno, DENG Qingfang, Florian Fainelli,
Arınç ÜNAL, Sean Wang, netdev, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <afoUt46gGwAC33ZU@makrotopia.org>
On 05/05/2026 17:03, Daniel Golle wrote:
> On Tue, May 05, 2026 at 03:37:29PM +0000, Chester A. Unal wrote:
>> Hey Daniel.
>>
>> On 05/05/2026 15:16, Daniel Golle wrote:
>>> The BPC, RGAC1 and RGAC2 registers control the handling of link-local
>>> frames with reserved MAC DAs (01:80:C2:00:00:0x). These frames are
>>> correctly trapped to the CPU port, but the egress VLAN tag attribute was
>>> set to MT7530_VLAN_EG_UNTAGGED which causes the switch to strip any
>>> VLAN tags from trapped frames before they reach the CPU.
>>>
>>> This causes VLAN-tagged link-local frames (STP BPDUs, LLDP, PTP Peer
>>> Delay Requests) to arrive at the CPU without their VLAN tag, so they
>>> are delivered to the base network interface instead of the VLAN
>>> sub-interface. The DSA local_termination selftest confirms this: all
>>> link-local protocol tests on VLAN upper interfaces fail.
>>>
>>> Set the EG_TAG attribute to MT7530_VLAN_EG_DISABLED (system default)
>>> so that the switch does not modify VLAN tags in trapped frames. This
>>> way VLAN-tagged frames retain their original tag and are delivered to
>>> the correct VLAN sub-interface, matching the behavior of non-trapped
>>> frames which pass through without VLAN tag modification.
>>>
>>> Fixes: 69ddba9d170b ("net: dsa: mt7530: fix handling of all link-local frames")
>>> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
>>
>> Thank you for this patch. Could you please confirm that it conforms to the
>> findings documented on this patch log?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=e8bf353577f382c7066c661fed41b2adc0fc7c40
>
> Yes. Combining VLAN CTAG and DSA tag into single "mess" tag is what the
> MT7530 hardware does, and also what tag_mtk.c expects, and mtk_eth_soc
> "special tag" feature handles well.
>
> I've found, addressed and verified all the issues in the series using
> the DSA selftests in tools/testing/selftest/drivers/net/dsa, ie. running
> bridge_vlan_aware.sh, bridge_vlan_unaware.sh and local_termination.sh
> in a loop, and random order, on BPi-R3 (MT7531) and BPi-R4 (MT7988).
>
> With the series applied many of the previously failing tests are now
> passing.
Great to hear!
Acked-by: Chester A. Unal <chester.a.unal@arinc9.com>
Chester A.
^ permalink raw reply
* Re: [PATCH RFC net-next v3] hsr: Allow to send a specific port and with HSR header
From: Willem de Bruijn @ 2026-05-05 16:14 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, Willem de Bruijn
Cc: netdev, Andrew Lunn, Chintan Vankar, Danish Anwar, Daolin Qiu,
David S. Miller, Eric Dumazet, Felix Maurer, Jakub Kicinski,
Neelima Muralidharan, Paolo Abeni, Praneeth Bajjuri,
Pratheesh Gangadhar TK, Richard Cochran, Simon Horman,
Vignesh Raghavendra
In-Reply-To: <20260505095216.T02Z4R1T@linutronix.de>
Sebastian Andrzej Siewior wrote:
> On 2026-05-04 13:08:04 [-0400], Willem de Bruijn wrote:
> > > > > +#define HSR_INLINE_HDR 0xaf485352
> > > > > +struct hsr_inline_header {
> > > > > + uint8_t tx_port;
> > > > > + uint8_t hsr_hdr;
> > > > > + uint8_t __pad0[4];
> > > > > + uint32_t magic;
> > > > > + uint8_t __pad1[2];
> > > > > + uint16_t eth_type;
> > > > > +} __packed;
> > > > > +
> > > >
> > > > No specific need to make this header ethhdr like?
> > >
> > > What do you mean? eth_type is at the same spot or do you mean it should
> > > be named h_proto?
> >
> > I mean there is no reason your fake header needs to be 14B or
> > or otherwise resemble an Ethernet header.
> >
> > That ties into my last comment to use sizeof(struct hsr_inline_header)
> > where working with that header, rather than ETH_HLEN. It is an
> > independent header.
>
> But I can't expect that the header is always there. A random ping/ arp
> packet goes via the same flow. At the same time I don't want to make it
> mandatory for all AF_PACKET users by checking the skb's socket.
I thought skb->protocol is the unambiguous signal whether this custom
header is present?
> The skb starts always with the ethernet header. To avoid collisions with
> a regular packet that looks similar I use the ether-type of the ethernet
> frame and it has to match PTP. It makes no sense to send a PTP packet via
> HSR. Since ether-type is at the end, I can't make it smaller than 14b.
> So eth-type is safeguard #1 and the second is SRC-MAC with a multicast
> sender bit set which is usually not the case.
> > > > All use of this information happens in the context of this ndo_start_xmit?
> > >
> > > I receive it from af_packet in HSR's ndo_start_xmit, yes. Then
> > > hsr_xmit() is forwarding it to the slave device via dev_queue_xmit().
> > > Here the skb->cb information gets overwritten.
> > >
> > > I need this hint in the slave eth driver in case there is hsr-offloading
> > > available.
> >
> > This assumes that the slave device is somehow HSR aware. But standard
> > net_devices are not?
>
> Yes, standard devices are not hsr-aware. It is just your average
> ethernet device that sends everything as-is.
> But you can have devices with HSR-offload capabilities such as
> NETIF_F_HW_HSR_FWD, NETIF_F_HW_HSR_DUP, NETIF_F_HW_HSR_TAG_INS,
> NETIF_F_HW_HSR_TAG_RM.
>
> So if a device provides NETIF_F_HW_HSR_TAG_INS and it is enabled
> (via ethtool -K) then the HSR stack will pass regular skb and the device
> will prepend the HSR-header (and maintain the HSR-sequence number and so
> on) before putting it on the wire.
> Also, the HSR stack will send a skb on both slave interfaces which are
> regular ethernet devices. But with NETIF_F_HW_HSR_DUP enabled it will
> pass it only to the first slave and expect the underlying device to
> forward it also via the other slave interface.
>
> So I need to pass skb which is can be sent by a dumb device but at the
> same time a device which does offload needs to be able to know when it
> should not do it.
Interesting. I was not aware of those offloads.
>
> > Isn't it HSR's ndo_start_xmit that selects which slave to forward to,
> > based on the information in this header?
>
> Yes, this is correct. I needed to verify that the slave device with
> offload capabilities does not send the skb on both ports and add a
> HSR header while doing so. The non-offloading devices are not an issue,
> it sends packets as-is.
> I managed to rework it and it works without the skb-ext. I just track
> the HSR mode (HSR vs PRP) and then parse the packet for its type and
> decide what needs to be done.
> This works now. Once we settle on the header I can repost it.
Excellent.
^ permalink raw reply
* Re: [PATCH] net: dsa: mv88e6xxx: remove unused .port_max_speed_mode()
From: Alexander Lobakin @ 2026-05-05 16:15 UTC (permalink / raw)
To: Marek Behún
Cc: Andrew Lunn, Vladimir Oltean, Russell King (Oracle),
Vivien Didelot, Tobias Waldekranz, netdev
In-Reply-To: <20260504152653.1389394-1-kabel@kernel.org>
From: Marek Behún <kabel@kernel.org>
Date: Mon, 4 May 2026 17:26:53 +0200
> The .port_max_speed_mode() method is not used anymore since commit
> 40da0c32c3fc ("net: dsa: mv88e6xxx: remove handling for DSA and CPU ports").
> Drop it.
>
> Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
> drivers/net/dsa/mv88e6xxx/chip.c | 9 -------
> drivers/net/dsa/mv88e6xxx/chip.h | 4 ----
> drivers/net/dsa/mv88e6xxx/port.c | 40 --------------------------------
> drivers/net/dsa/mv88e6xxx/port.h | 9 -------
> 4 files changed, 62 deletions(-)
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH v5 net-next 3/3] selftests:net: Implement ptp4l sync test using netdevsim
From: Maciek Machnikowski @ 2026-05-05 16:22 UTC (permalink / raw)
To: Andrew Lunn
Cc: Jakub Kicinski, netdev, richardcochran, milena.olech,
willemdebruijn.kernel, vadim.fedorenko, horms
In-Reply-To: <9c7eecee-f0c2-4ee3-95cf-ae9965191902@lunn.ch>
On 05/05/2026 14:22, Andrew Lunn wrote:
> On Tue, May 05, 2026 at 09:36:30AM +0200, Maciek Machnikowski wrote:
>>
>>
>> On 04/05/2026 19:07, Jakub Kicinski wrote:
>>> On Sun, 3 May 2026 09:47:47 +0200 Maciek Machnikowski wrote:
>>>> Add PTP synchronization test using ptp4l and netdevsim.
>>>>
>>>> The test creates two netdevsim adapters, links them together
>>>> and runs the ptp4l leader and ptp4l follower on two ends
>>>> of the netdevsim link and waits for the follower to report the
>>>> synchronized state (s2) in its output log.
>>>>
>>>> This implementation runs the test runs over IPv4 link.
>>>
>>> Doesn't seem to pass on netdevsim for us:
>>>
>>> # 41.13 [+40.95] # ptp4l follower did not reach locked state (s2) within 40s
>>> # 41.13 [+0.00] # Follower log (last 10 lines): ptp4l[2179.605]: ioctl SIOCETHTOOL failed: Operation not supported | ptp4l[2179.607]: interface 'eth0' does not support requested timestamping mode | failed to create a clock
>>> # 41.15 [+0.02] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 173, in ptp_sync_test:
>>> # 41.15 [+0.01] # Check| _run_ptp4l_wait_sync(nsimsv.ifname, nsimcl.ifname, nssv.name, nscl.name)
>>> # 41.16 [+0.01] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 99, in _run_ptp4l_wait_sync:
>>> # 41.17 [+0.01] # Check| ksft_true(False, "PTP sync timeout")
>>> # 41.17 [+0.00] # Check failed False does not eval to True PTP sync timeout
>>> # 41.32 [+0.16] not ok 1 ptp.ptp_sync_test
>>> # 41.33 [+0.00] # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
>>>
>>> Anything we need to do?
>>
>> Can you share the config file you used? Seems the PTP clock was not
>> found which may lead to PTP_1588_CLOCK_MOCK not being enabled?
>
> Shouldn't the configuration file be part of the test?
>
> Andrew
I meant the kernel config. The PTP emulation requires PTP Mock to be
enabled, as that's the backbone for generating timestamps. If it's
disabled - netdevsim netdevs will report no timestamping support, as in
the example above.
- Maciek
^ permalink raw reply
* Re: [PATCH net-next 12/12] arm64: dts: qcom: qcs6490-rb3gen2: enable TC9564 with a single QCS8081 phy
From: Daniel Thompson @ 2026-05-05 16:25 UTC (permalink / raw)
To: Andrew Lunn
Cc: Alex Elder, andrew+netdev, davem, edumazet, kuba, pabeni,
maxime.chevallier, rmk+kernel, andersson, konradybcio, robh,
krzk+dt, conor+dt, linusw, brgl, arnd, gregkh, mohd.anwar,
a0987203069, alexandre.torgue, ast, boon.khai.ng, chenchuangyu,
chenhuacai, daniel, hawk, hkallweit1, inochiama, john.fastabend,
julianbraha, livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <d29621c3-07fc-4720-abff-d8901a0d791c@lunn.ch>
On Fri, May 01, 2026 at 11:09:42PM +0200, Andrew Lunn wrote:
> > + tc956x_emac1_phy: ethernet-phy@1c {
> > + compatible = "ethernet-phy-id004d.d101";
> > + reg = <0x1c>;
> > + reset-gpios = <&tc956x_emac0 1 GPIO_ACTIVE_LOW>;
> > + reset-assert-us = <20>;
> > + reset-deassert-us = <20>;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&qep_irq_pin>;
> > + interrupts-extended = <&tlmm 101 IRQ_TYPE_EDGE_FALLING>;
>
> What is probably wrong. PHY interrupts are level, not edge.
Thanks (and agree). Will fix.
Daniel.
^ permalink raw reply
* Re: [PATCH v8 phy-next 01/31] PCI: cadence: Preserve all error codes in cdns_plat_pcie_probe()
From: Bjorn Helgaas @ 2026-05-05 16:26 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, Bjorn Helgaas, Krzysztof Wilczyński,
Lorenzo Pieralisi, Manikandan K Pillai, Manivannan Sadhasivam,
Rob Herring, Tom Joseph
In-Reply-To: <20260505100523.1922388-2-vladimir.oltean@nxp.com>
[+cc Tom, author of bd22885aa188 in case there's something subtle here]
On Tue, May 05, 2026 at 01:04:53PM +0300, Vladimir Oltean wrote:
> The blamed commit functionally changed the error path of
> cdns_pcie_host_probe(), now cdns_plat_pcie_probe().
>
> When the old code path executed "goto err_get_sync", the PCIe controller
> probe function propagated the pm_runtime_get_sync() error code. The new
> code doesn't, and returns 0.
>
> Similarly for the "goto err_init" previously triggered by
> cdns_pcie_host_init() errors, and now triggered by
> cdns_pcie_host_setup() and cdns_pcie_ep_setup() errors. These are not
> propagated and will result in probing success, which is incorrect.
>
> Fixes: bd22885aa188 ("PCI: cadence: Refactor driver to use as a core library")
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Manikandan K Pillai <mpillai@cadence.com>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
I guess this driver is orphaned.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> v7->v8: patch is new, issue was flagged by Sashiko
> https://sashiko.dev/#/patchset/20260430110652.558622-1-vladimir.oltean@nxp.com
> ---
> drivers/pci/controller/cadence/pcie-cadence-plat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/cadence/pcie-cadence-plat.c b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> index b067a3296dd3..8b12a46b5601 100644
> --- a/drivers/pci/controller/cadence/pcie-cadence-plat.c
> +++ b/drivers/pci/controller/cadence/pcie-cadence-plat.c
> @@ -126,7 +126,7 @@ static int cdns_plat_pcie_probe(struct platform_device *pdev)
> while (phy_count--)
> device_link_del(cdns_plat_pcie->pcie->link[phy_count]);
>
> - return 0;
> + return ret;
This affects cases where pm_runtime_get_sync(),
cdns_pcie_host_setup(), or cdns_pcie_ep_setup() return failure.
Seems right to me to fail the probe when these fail.
Not all users of pm_runtime_get_sync() check for failure, but I think
all the other controller drivers that do check return failures from
the .probe().
> }
>
> static void cdns_plat_pcie_shutdown(struct platform_device *pdev)
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net v1] net/mlx5: Fix HWS L2-to-L3 tunnel reformat release
From: Alexander Lobakin @ 2026-05-05 16:26 UTC (permalink / raw)
To: Prathamesh Deshpande
Cc: Saeed Mahameed, Leon Romanovsky, Moshe Shemesh, Mark Bloch,
Tariq Toukan, Yevgeny Kliteynik, Jakub Kicinski, netdev,
linux-rdma, linux-kernel
In-Reply-To: <20260504221920.48685-1-prathameshdeshpande7@gmail.com>
From: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
Date: Mon, 4 May 2026 23:19:17 +0100
> mlx5_cmd_hws_packet_reformat_alloc() allocates
> MLX5_REFORMAT_TYPE_L2_TO_L3_TUNNEL objects from el2tol3tnl_pools with
> MLX5HWS_ACTION_TYP_REFORMAT_L2_TO_TNL_L3.
>
> The deallocation path uses el2tol2tnl_pools with
> MLX5HWS_ACTION_TYP_REFORMAT_L2_TO_TNL_L2 instead. This releases the
> packet-reformat entry through the wrong pool, corrupting pool accounting
> and potentially moving the bulk entry onto the wrong pool list.
>
> Use the matching L2-to-L3 tunnel pool and action type when releasing the
> object.
>
> Fixes: aecd9d1020e3 ("net/mlx5: fs, add HWS packet reformat API function")
> Signed-off-by: Prathamesh Deshpande <prathameshdeshpande7@gmail.com>
Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/steering/hws/fs_hws.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks,
Olek
^ permalink raw reply
* Re: [PATCH net, v3] net: mana: Fix crash from unvalidated SHM offset read from BAR0 during FLR
From: Dipayaan Roy @ 2026-05-05 16:28 UTC (permalink / raw)
To: Paolo Abeni
Cc: kys, haiyangz, wei.liu, decui, andrew+netdev, davem, edumazet,
kuba, leon, longli, kotaranov, horms, shradhagupta, ssengar,
ernis, shirazsaleem, linux-hyperv, netdev, linux-kernel,
linux-rdma, stephen, jacob.e.keller, dipayanroy, leitao, kees,
john.fastabend, hawk, bpf, daniel, ast, sdf, yury.norov
In-Reply-To: <30f588ad-cf80-432b-bde3-13b3c0d5a124@redhat.com>
On Tue, May 05, 2026 at 03:42:46PM +0200, Paolo Abeni wrote:
> On 5/1/26 4:47 AM, Dipayaan Roy wrote:
> > @@ -73,10 +74,28 @@ static int mana_gd_init_pf_regs(struct pci_dev *pdev)
> > gc->phys_db_page_base = gc->bar0_pa + gc->db_page_off;
> >
> > sriov_base_off = mana_gd_r64(gc, GDMA_SRIOV_REG_CFG_BASE_OFF);
> > + if (sriov_base_off >= gc->bar0_size ||
> > + gc->bar0_size - sriov_base_off <
> > + GDMA_PF_REG_SHM_OFF + sizeof(u64) ||
> > + !IS_ALIGNED(sriov_base_off, sizeof(u64))) {
> > + dev_err(gc->dev,
> > + "SRIOV base offset 0x%llx out of range or unaligned (BAR0 size 0x%llx)\n",
> > + sriov_base_off, (u64)gc->bar0_size);
> > + return -EPROTO;
> > + }
>
> I think that the additional fix suggested by sashiko is really worthy,
> but should go in a separate patch. @Dipayaan: please follow-up on that
> one, thanks!
>
> Paolo
>
Hi Paolo,
Thanks for reviewing, and I will cross check and send out a separate patch for
issue pointed out by Sashiko(un-related to the current issue).
Regards
Dipayaan Roy
^ permalink raw reply
* [PATCH] net: iphc: fix offset errors in multicast context compression
From: Quan Sun @ 2026-05-05 16:31 UTC (permalink / raw)
To: linux-wpan, netdev; +Cc: alex.aring, davem, edumazet, andrew, Quan Sun
The function lowpan_iphc_mcast_ctx_addr_compress() contains two offset
errors that break context-based multicast address compression
(LOWPAN_IPHC_DAM_00).
When compressing the multicast address, the compressed format expects
exactly 6 bytes:
- Bytes 0-1: Flags, scope, and reserved bits (from s6_addr[1..2])
- Bytes 2-5: The 4-byte Group ID (from s6_addr[12..15])
Currently, the memcpy() operations use incorrect offsets:
1. The destination offset for the Group ID is &data[1] instead of
&data[2]. This overwrites the previously copied scope byte.
2. The source offset for the Group ID is &ipaddr->s6_addr[11] instead
of &ipaddr->s6_addr[12].
This mismatch results in a corrupted compressed address being
transmitted. Consequently, the receiving side fails to reconstruct the
original IPv6 address via lowpan_uncompress_multicast_ctx_daddr() since
it expects the Group ID to start at data[2].
Fix the logic by correcting both the destination and source offsets
so that the 6-byte compressed representation is assembled correctly.
Signed-off-by: Quan Sun <2022090917019@std.uestc.edu.cn>
---
net/6lowpan/iphc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/6lowpan/iphc.c b/net/6lowpan/iphc.c
index e116d308a8df6..29ae68ca3ec15 100644
--- a/net/6lowpan/iphc.c
+++ b/net/6lowpan/iphc.c
@@ -1091,7 +1091,7 @@ static u8 lowpan_iphc_mcast_ctx_addr_compress(u8 **hc_ptr,
/* flags/scope, reserved (RIID) */
memcpy(data, &ipaddr->s6_addr[1], 2);
/* group ID */
- memcpy(&data[1], &ipaddr->s6_addr[11], 4);
+ memcpy(&data[2], &ipaddr->s6_addr[12], 4);
lowpan_push_hc_data(hc_ptr, data, 6);
return LOWPAN_IPHC_DAM_00;
base-commit: 95084f1883a760e0d4290698346759d58e2b944a
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net] vsock/virtio: fix potential unbounded skb queue
From: Bobby Eshleman @ 2026-05-05 16:37 UTC (permalink / raw)
To: Stefano Garzarella
Cc: Eric Dumazet, Arseniy Krasnov, Bobby Eshleman, Stefan Hajnoczi,
Michael S. Tsirkin, David S . Miller, Jakub Kicinski, Paolo Abeni,
Simon Horman, netdev, eric.dumazet, Arseniy Krasnov, Jason Wang,
Xuan Zhuo, Eugenio Pérez, kvm, virtualization
In-Reply-To: <afoF_cHfl6ygcupM@sgarzare-redhat>
On Tue, May 05, 2026 at 06:11:13PM +0200, Stefano Garzarella wrote:
> On Tue, May 05, 2026 at 07:14:36AM -0700, Eric Dumazet wrote:
> > On Tue, May 5, 2026 at 6:52 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
> > >
> > > On Thu, Apr 30, 2026 at 12:26:52PM +0000, Eric Dumazet wrote:
> > > >virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.
> > > >
> > > >virtio_transport_recv_enqueue() skips coalescing for packets
> > > >with VIRTIO_VSOCK_SEQ_EOM.
> > > >
> > > >If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM,
> > > >a very large number of packets can be queued
> > > >because vvs->rx_bytes stays at 0.
> > > >
> > > >Fix this by estimating the skb metadata size:
> > > >
> > > > (Number of skbs in the queue) * SKB_TRUESIZE(0)
> > > >
> > > >Fixes: 077706165717 ("virtio/vsock: don't use skbuff state to account credit")
> > > >Signed-off-by: Eric Dumazet <edumazet@google.com>
> > > >Cc: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
> > > >Cc: Stefan Hajnoczi <stefanha@redhat.com>
> > > >Cc: Stefano Garzarella <sgarzare@redhat.com>
> > > >Cc: "Michael S. Tsirkin" <mst@redhat.com>
> > > >Cc: Jason Wang <jasowang@redhat.com>
> > > >Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
> > > >Cc: "Eugenio Pérez" <eperezma@redhat.com>
> > > >Cc: kvm@vger.kernel.org
> > > >Cc: virtualization@lists.linux.dev
> > > >---
> > > > net/vmw_vsock/virtio_transport_common.c | 4 +++-
> > > > 1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > >diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> > > >index 416d533f493d7b07e9c77c43f741d28cfcd0953e..9b8014516f4fb1130ae184635fbba4dfee58bd64 100644
> > > >--- a/net/vmw_vsock/virtio_transport_common.c
> > > >+++ b/net/vmw_vsock/virtio_transport_common.c
> > > >@@ -447,7 +447,9 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
> > > > static bool virtio_transport_inc_rx_pkt(struct virtio_vsock_sock *vvs,
> > > > u32 len)
> > > > {
> > > >- if (vvs->buf_used + len > vvs->buf_alloc)
> > > >+ u64 skb_overhead = (skb_queue_len(&vvs->rx_queue) + 1) * SKB_TRUESIZE(0);
> > > >+
> > > >+ if (skb_overhead + vvs->buf_used + len > vvs->buf_alloc)
> > > > return false;
> > >
> > > I'm not sure about this fix, I mean that maybe this is incomplete.
> > > In virtio-vsock, there is a credit mechanism between the two peers:
> > > https://docs.oasis-open.org/virtio/virtio/v1.3/csd01/virtio-v1.3-csd01.html#x1-4850003
> > >
> > > This takes only the payload into account, so it’s true that this problem
> > > exists; however, perhaps we should also inform the other peer of a lower
> > > credit balance, otherwise the other peer will believe it has much more
> > > credit than it actually does, send a large payload, and then the packet
> > > will be discarded and the data lost (there are no retransmissions,
> > > etc.).
> >
> > I dunno, perhaps revert 077706165717 ("virtio/vsock: don't use skbuff
> > state to account credit")
> > and find a better fix then?
>
> IIRC the same issue was there before the commit fixed by that one (commit
> 71dc9ec9ac7d ("virtio/vsock: replace virtio_vsock_pkt with sk_buff")), so
> not sure about reverting it TBH.
>
> CCing Arseniy and Bobby.
>
> >
> > There is always a discrepancy between skb->len and skb->truesize.
> > You will not be able to announce a 1MB window, and accept one milliion
> > skb of 1-byte each.
> >
> > This kind of contract is broken.
> >
>
> Yep, I agree, but before we start discarding data (and losing it), IMHO we
> should at least inform the other peer that we're out of space.
>
> @Stefan, @Michael, do you think we can do something in the spec to avoid
> this issue and in some way take into account also the metadata in the
> credit. I mean to avoid the 1-byte packets flooding.
>
> Thanks,
> Stefano
>
>
Indeed the old pre-fix skb code would have the same issue.
I can't think of any way around this without extending the spec.
Best,
Bobby
^ permalink raw reply
* Re: [PATCH v5 net-next 3/3] selftests:net: Implement ptp4l sync test using netdevsim
From: Vadim Fedorenko @ 2026-05-05 16:38 UTC (permalink / raw)
To: Maciek Machnikowski, Andrew Lunn
Cc: Jakub Kicinski, netdev, richardcochran, milena.olech,
willemdebruijn.kernel, horms
In-Reply-To: <aa5798db-51b1-4d44-abec-c55b0560ec21@machnikowski.net>
On 05/05/2026 17:22, Maciek Machnikowski wrote:
>
>
> On 05/05/2026 14:22, Andrew Lunn wrote:
>> On Tue, May 05, 2026 at 09:36:30AM +0200, Maciek Machnikowski wrote:
>>>
>>>
>>> On 04/05/2026 19:07, Jakub Kicinski wrote:
>>>> On Sun, 3 May 2026 09:47:47 +0200 Maciek Machnikowski wrote:
>>>>> Add PTP synchronization test using ptp4l and netdevsim.
>>>>>
>>>>> The test creates two netdevsim adapters, links them together
>>>>> and runs the ptp4l leader and ptp4l follower on two ends
>>>>> of the netdevsim link and waits for the follower to report the
>>>>> synchronized state (s2) in its output log.
>>>>>
>>>>> This implementation runs the test runs over IPv4 link.
>>>>
>>>> Doesn't seem to pass on netdevsim for us:
>>>>
>>>> # 41.13 [+40.95] # ptp4l follower did not reach locked state (s2) within 40s
>>>> # 41.13 [+0.00] # Follower log (last 10 lines): ptp4l[2179.605]: ioctl SIOCETHTOOL failed: Operation not supported | ptp4l[2179.607]: interface 'eth0' does not support requested timestamping mode | failed to create a clock
>>>> # 41.15 [+0.02] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 173, in ptp_sync_test:
>>>> # 41.15 [+0.01] # Check| _run_ptp4l_wait_sync(nsimsv.ifname, nsimcl.ifname, nssv.name, nscl.name)
>>>> # 41.16 [+0.01] # Check| At /srv/vmksft/testing/wt-2/tools/testing/selftests/net/./ptp.py, line 99, in _run_ptp4l_wait_sync:
>>>> # 41.17 [+0.01] # Check| ksft_true(False, "PTP sync timeout")
>>>> # 41.17 [+0.00] # Check failed False does not eval to True PTP sync timeout
>>>> # 41.32 [+0.16] not ok 1 ptp.ptp_sync_test
>>>> # 41.33 [+0.00] # Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
>>>>
>>>> Anything we need to do?
>>>
>>> Can you share the config file you used? Seems the PTP clock was not
>>> found which may lead to PTP_1588_CLOCK_MOCK not being enabled?
>>
>> Shouldn't the configuration file be part of the test?
>>
>> Andrew
>
> I meant the kernel config. The PTP emulation requires PTP Mock to be
> enabled, as that's the backbone for generating timestamps. If it's
> disabled - netdevsim netdevs will report no timestamping support, as in
> the example above.
> - Maciek
tools/testing/selftests/drivers/net/netdevsim/config has
CONFIG_PTP_1588_CLOCK_MOCK=y
but maybe no CONFIG_PTP_1588_CLOCK ?
^ permalink raw reply
* Re: [PATCH net-next 10/12] net: stmmac: tc956x: add TC956x/QPS615 support
From: Mohd Ayaan Anwar @ 2026-05-05 16:38 UTC (permalink / raw)
To: Alex Elder
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, Daniel Thompson, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260501155421.3329862-11-elder@riscstar.com>
Hi Alex,
On Fri, May 01, 2026 at 10:54:18AM -0500, Alex Elder wrote:
> + /*
> + * TX956x has 8 TX queues but only #0 to #3 work for general IP traffic.
Minor typo in the comment: I think you meant TC956X instead of TX956X?
> +
> + for (i = 0; i < td->plat->rx_queues_to_use; i++) {
> + res->rx_irq[i] = irq_create_mapping(irq_domain, HWIRQ_RX0 + i);
> + if (!res->tx_irq[i])
Typo: res->rx_irq instead of res->tx_irq.
PS: I was able to successfully test this series out on a Rb3Gen2 board.
Ayaan
^ permalink raw reply
* Re: [PATCH net-next 12/12] arm64: dts: qcom: qcs6490-rb3gen2: enable TC9564 with a single QCS8081 phy
From: Mohd Ayaan Anwar @ 2026-05-05 16:42 UTC (permalink / raw)
To: Alex Elder
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, Daniel Thompson, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260501155421.3329862-13-elder@riscstar.com>
Hi Alex,
On Fri, May 01, 2026 at 10:54:20AM -0500, Alex Elder wrote:
> From: Daniel Thompson <daniel@riscstar.com>
>
> The QCS6490 RB3Gen2 includes a Toshiba TC9564 (a.k.a. Qualcomm QPS615).
> TC9564 is an twin Ethernet-AVB/TSN bridge with an integrated PCIe switch.
>
> There are multiple builds of RB3Gen2 with components included/excluded.
> That means whether or not there is a phy attached to eMAC0 depends on
> the exact board. However all versions include a TC9564 combined with a
> single QCS8081 attached to eMAC1.
>
> Add properties to the existing PCI nodes to describe how the TC9564 and
> QCS8081 are connected to each other (and to the host SoC).
>
> (Note: "pci1179,0220" is documented in the "net/toshiba,tc956x-dwmac.yaml"
> binding, but checkpatch.pl doesn't recognize that.)
>
> Co-developed-by: Alex Elder <elder@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
There's a minor typo in the PHY name - QCS8081 instead of QCA8081.
Ayaan
^ permalink raw reply
* Re: [PATCH net-next 10/12] net: stmmac: tc956x: add TC956x/QPS615 support
From: Alex Elder @ 2026-05-05 16:46 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, Daniel Thompson, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <afodG9uuopgfvSmu@oss.qualcomm.com>
On 5/5/26 11:38 AM, Mohd Ayaan Anwar wrote:
> Hi Alex,
> On Fri, May 01, 2026 at 10:54:18AM -0500, Alex Elder wrote:
>
>> + /*
>> + * TX956x has 8 TX queues but only #0 to #3 work for general IP traffic.
>
> Minor typo in the comment: I think you meant TC956X instead of TX956X?
Yes, I'll fix that.
>> + for (i = 0; i < td->plat->rx_queues_to_use; i++) {
>> + res->rx_irq[i] = irq_create_mapping(irq_domain, HWIRQ_RX0 + i);
>> + if (!res->tx_irq[i])
>
> Typo: res->rx_irq instead of res->tx_irq.
Wow, that's important... Fortunately we haven't been getting errors.
This will be fixed.
> PS: I was able to successfully test this series out on a Rb3Gen2 board.
Great! Thank you.
-Alex
> Ayaan
^ permalink raw reply
* Re: [PATCH net-next 12/12] arm64: dts: qcom: qcs6490-rb3gen2: enable TC9564 with a single QCS8081 phy
From: Alex Elder @ 2026-05-05 16:46 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, maxime.chevallier,
rmk+kernel, andersson, konradybcio, robh, krzk+dt, conor+dt,
linusw, brgl, arnd, gregkh, Daniel Thompson, a0987203069,
alexandre.torgue, ast, boon.khai.ng, chenchuangyu, chenhuacai,
daniel, hawk, hkallweit1, inochiama, john.fastabend, julianbraha,
livelycarpet87, matthew.gerlach, mcoquelin.stm32, me,
prabhakar.mahadev-lad.rj, richardcochran, rohan.g.thomas, sdf,
siyanteng, weishangjuan, wens, netdev, bpf, linux-arm-msm,
devicetree, linux-gpio, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <afod8ot7xb+g0wzN@oss.qualcomm.com>
On 5/5/26 11:42 AM, Mohd Ayaan Anwar wrote:
> Hi Alex,
> On Fri, May 01, 2026 at 10:54:20AM -0500, Alex Elder wrote:
>> From: Daniel Thompson <daniel@riscstar.com>
>>
>> The QCS6490 RB3Gen2 includes a Toshiba TC9564 (a.k.a. Qualcomm QPS615).
>> TC9564 is an twin Ethernet-AVB/TSN bridge with an integrated PCIe switch.
>>
>> There are multiple builds of RB3Gen2 with components included/excluded.
>> That means whether or not there is a phy attached to eMAC0 depends on
>> the exact board. However all versions include a TC9564 combined with a
>> single QCS8081 attached to eMAC1.
>>
>> Add properties to the existing PCI nodes to describe how the TC9564 and
>> QCS8081 are connected to each other (and to the host SoC).
>>
>> (Note: "pci1179,0220" is documented in the "net/toshiba,tc956x-dwmac.yaml"
>> binding, but checkpatch.pl doesn't recognize that.)
>>
>> Co-developed-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
>
> There's a minor typo in the PHY name - QCS8081 instead of QCA8081.
OK, I'll fix that too. Thanks a lot Ayaan.
-Alex
>
> Ayaan
^ permalink raw reply
* Re: [PATCH v5 net-next 3/3] selftests:net: Implement ptp4l sync test using netdevsim
From: Andrew Lunn @ 2026-05-05 16:53 UTC (permalink / raw)
To: Maciek Machnikowski
Cc: Jakub Kicinski, netdev, richardcochran, milena.olech,
willemdebruijn.kernel, vadim.fedorenko, horms
In-Reply-To: <aa5798db-51b1-4d44-abec-c55b0560ec21@machnikowski.net>
> >>> Anything we need to do?
> >>
> >> Can you share the config file you used? Seems the PTP clock was not
> >> found which may lead to PTP_1588_CLOCK_MOCK not being enabled?
> >
> > Shouldn't the configuration file be part of the test?
> >
> > Andrew
>
> I meant the kernel config.
Ah. O.K.
> The PTP emulation requires PTP Mock to be
> enabled, as that's the backbone for generating timestamps. If it's
> disabled - netdevsim netdevs will report no timestamping support, as in
> the example above.
Maybe a Kconfig selects or depends should be added to netdevsim to
ensure the needed parts are enabled?
Andrew
^ permalink raw reply
* Re: [PATCH net] ixgbe: fix X550 AQ PHY identification returning ixgbe_phy_unknown
From: Simon Horman @ 2026-05-05 16:53 UTC (permalink / raw)
To: Aleksandr Loktionov; +Cc: intel-wired-lan, anthony.l.nguyen, netdev
In-Reply-To: <20260430123154.132072-1-aleksandr.loktionov@intel.com>
On Thu, Apr 30, 2026 at 02:31:53PM +0200, Aleksandr Loktionov wrote:
> ixgbe_get_phy_id() reads the two MII_PHYSID registers and combines them
> into hw->phy.id with the lower 4 revision bits masked out by
> IXGBE_PHY_REVISION_MASK (0xFFFFFFF0).
>
> Commit 5f1c3589b0f0 ("ixgbe: Correct X550 phy ID") replaced
> X550_PHY_ID (0x01540220) with X550_PHY_ID2 (0x01540223) and
> X550_PHY_ID3 (0x01540221). These are the raw values read directly off
> hardware, but after revision-bit masking both reduce to 0x01540220.
> The switch cases in ixgbe_get_phy_type_from_id() therefore never match,
> and X550 AQ PHY devices always fall through to ixgbe_phy_unknown. A
> wrong PHY type means the wrong ops vector is selected, resulting in
> failed PHY initialization and no link.
>
> Restore X550_PHY_ID (0x01540220) as the match value -- the
> revision-stripped ID that the driver actually stores. Keep X550_PHY_ID2
> and X550_PHY_ID3 as documentation of the hardware-reported values.
>
> Fixes: 5f1c3589b0f0 ("ixgbe: Correct X550 phy ID")
> Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
^ 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