* [RFC PATCH 0/1] netlink: Netlink process event for cgroup migration
From: Prakash Sangappa @ 2026-04-07 17:23 UTC (permalink / raw)
To: linux-kernel, netdev, cgroups
Cc: davem, kuba, edumazet, tj, hannes, mkoutny, tom.hromatka,
kamalesh.babulal, prakash.sangappa
With cgroup based resource management, it becomes useful for
userspace to be notified when a task changes cgroup membership.
Unexpected migrations can lead to incorrect resource accounting
and enforcement resulting in undesirable behavior or failures.
Applications/userspace have to poll /proc to detect changes to
cgroup membership, which is inefficient when dealing with a large
number of tasks.
Add a new netlink proc connector event that gets generated when
a task migrates between cgroups. This allows applications/tools
to monitor cgroup membership changes without periodic polling.
The netlink proc event will include task's pid/tgid, initiator
process pid/tgid and the cgroup id.
Prakash Sangappa (1):
netlink: Add Netlink process event for cgroup migration
drivers/connector/cn_proc.c | 28 ++++++++++++++++++++++++++++
include/linux/cn_proc.h | 3 +++
include/uapi/linux/cn_proc.h | 14 ++++++++++++--
kernel/cgroup/cgroup-v1.c | 7 ++++++-
kernel/cgroup/cgroup.c | 5 ++++-
5 files changed, 53 insertions(+), 4 deletions(-)
--
2.43.7
^ permalink raw reply
* Re: [PATCH net-next v2 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings
From: Rob Herring @ 2026-04-07 17:18 UTC (permalink / raw)
To: Jens Emil Schulz Østergaard
Cc: UNGLinuxDriver, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Krzysztof Kozlowski, Conor Dooley, Woojung Huh, Russell King,
Steen Hegelund, Daniel Machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260324-dsa_lan9645x_switch_driver_base-v2-2-f7504e3b0681@microchip.com>
On Tue, Mar 24, 2026 at 11:46:45AM +0100, Jens Emil Schulz Østergaard wrote:
> Add bindings for LAN9645X switch. We use a fallback compatible for the
> smallest SKU microchip,lan96455s-switch.
>
> Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com>
> Signed-off-by: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> ---
> Changes in v2:
> - rename file to microchip,lan96455s-switch.yaml
> - remove led vendor property
> - add {rx,tx}-internal-delay-ps for rgmii delay
> - remove labels from example
> - remove container node from example
> ---
> .../net/dsa/microchip,lan96455s-switch.yaml | 119 +++++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 120 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> new file mode 100644
> index 000000000000..0282e25c05d4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> @@ -0,0 +1,119 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/dsa/microchip,lan96455s-switch.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip LAN9645x Ethernet switch
> +
> +maintainers:
> + - Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> +
> +description: |
Don't need '|'
> + The LAN9645x switch is a multi-port Gigabit AVB/TSN Ethernet switch with
> + five integrated 10/100/1000Base-T PHYs. In addition to the integrated PHYs,
> + it supports up to 2 RGMII/RMII, up to 2 BASE-X/SERDES/2.5GBASE-X and one
> + Quad-SGMII interfaces.
> +
> +properties:
> + compatible:
> + oneOf:
> + - enum:
> + - microchip,lan96455s-switch
> + - items:
> + - enum:
> + - microchip,lan96455f-switch
> + - microchip,lan96457f-switch
> + - microchip,lan96459f-switch
> + - microchip,lan96457s-switch
> + - microchip,lan96459s-switch
> + - const: microchip,lan96455s-switch
> +
> + reg:
> + maxItems: 1
> +
> +$ref: dsa.yaml#
Since you don't have any custom properties (just constraints), this ref
should be "dsa.yaml#/$defs/ethernet-ports".
> +
> +patternProperties:
> + "^(ethernet-)?ports$":
For a new binding, use the preferred name which is ethernet-ports. ports
and port collide with the graph binding.
> + type: object
> + additionalProperties: true
> + patternProperties:
> + "^(ethernet-)?port@[0-8]$":
And 'ethernet-port'
> + type: object
> + description: Ethernet switch ports
> +
> + $ref: dsa-port.yaml#
> +
> + properties:
> + rx-internal-delay-ps:
> + const: 2000
> +
> + tx-internal-delay-ps:
> + const: 2000
> +
> + unevaluatedProperties: false
Place this after the $ref.
> +
> +oneOf:
> + - required:
> + - ports
> + - required:
> + - ethernet-ports
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + ethernet-switch@4000 {
> + compatible = "microchip,lan96459f-switch", "microchip,lan96455s-switch";
> + reg = <0x4000 0x244>;
> +
> + ethernet-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + phy-mode = "gmii";
> + phy-handle = <&cuphy0>;
> + };
> +
> + port@1 {
> + reg = <1>;
> + phy-mode = "gmii";
> + phy-handle = <&cuphy1>;
> + };
> +
> + port@2 {
> + reg = <2>;
> + phy-mode = "gmii";
> + phy-handle = <&cuphy2>;
> + };
> +
> + port@3 {
> + reg = <3>;
> + phy-mode = "gmii";
> + phy-handle = <&cuphy3>;
> + };
> +
> + port@7 {
> + reg = <7>;
> + phy-mode = "rgmii";
> + ethernet = <&cpu_host_port>;
> + rx-internal-delay-ps = <2000>;
> + tx-internal-delay-ps = <2000>;
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + pause;
> + };
> + };
> + };
> + };
> +...
> +
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7ae698067c41..8232da1b3951 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -17278,6 +17278,7 @@ M: Jens Emil Schulz Østergaard <jensemil.schulzostergaard@microchip.com>
> M: UNGLinuxDriver@microchip.com
> L: netdev@vger.kernel.org
> S: Maintained
> +F: Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> F: include/linux/dsa/lan9645x.h
> F: net/dsa/tag_lan9645x.c
>
>
> --
> 2.52.0
>
^ permalink raw reply
* [PATCH 3/3] net: rose: fix out-of-bounds read in rose_parse_ccitt()
From: Mashiro Chen @ 2026-04-07 17:16 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, gregkh, ben, linux-hams,
linux-kernel, stable, Mashiro Chen
In-Reply-To: <20260407171600.102988-1-mashiro.chen@mailbox.org>
rose_parse_ccitt() handles 0xC0-class facilities by reading l = p[1]
and validating 10 <= l <= 20, but never checks whether the remaining
buffer actually contains l + 2 bytes before accessing p + 7 and
p + 12 via memcpy().
An attacker can send a ROSE_CALL_REQUEST frame with a crafted CCITT
facility whose declared length fits the 10-20 range but whose actual
data is truncated. This causes the kernel to read up to l + 2 bytes
beyond the end of the facilities field, leaking adjacent skb data.
By contrast, rose_parse_national() already performs the equivalent
check (if (len < 2 + l) return -1) for all its 0xC0-class cases.
Add the same check to rose_parse_ccitt() before any data access.
Fixes: e0bccd315db0 ("rose: Add length checks to CALL_REQUEST parsing")
Cc: stable@vger.kernel.org
Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org>
---
net/rose/rose_subr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/rose/rose_subr.c b/net/rose/rose_subr.c
index 4dbc437a9e229..a902ddeddc5bd 100644
--- a/net/rose/rose_subr.c
+++ b/net/rose/rose_subr.c
@@ -370,6 +370,9 @@ static int rose_parse_ccitt(unsigned char *p, struct rose_facilities_struct *fac
if (l < 10 || l > 20)
return -1;
+ if (len < 2 + l)
+ return -1;
+
if (*p == FAC_CCITT_DEST_NSAP) {
memcpy(&facilities->source_addr, p + 7, ROSE_ADDR_LEN);
memcpy(callsign, p + 12, l - 10);
--
2.53.0
^ permalink raw reply related
* [PATCH 2/3] net: netrom: validate source address in nr_find_socket()
From: Mashiro Chen @ 2026-04-07 17:15 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, gregkh, ben, linux-hams,
linux-kernel, stable, Mashiro Chen
In-Reply-To: <20260407171600.102988-1-mashiro.chen@mailbox.org>
nr_find_socket() dispatches incoming NR_INFO frames into a connected
socket by matching the frame's circuit index/id pair (bytes[15-16])
against the socket's my_index/my_id. It performs no validation of
the frame's source callsign against the socket's dest_addr.
This means any node on the network can craft an NR_INFO frame with
a guessed or brute-forced circuit index/id pair and have it accepted
into an arbitrary STATE_3 connection as if it came from the legitimate
peer. Circuit IDs are assigned sequentially starting at (1,1), making
them predictable in practice.
This is exploited in concert with CVE-XXXX-XXXXX (nr_queue_rx_frame
fraglen overflow): an attacker can inject NR_INFO | NR_MORE_FLAG frames
into an existing connection without owning a connection themselves,
driving the victim socket's fraglen to wrap and triggering the heap
overflow entirely unauthenticated (CVSS PR:N).
Fix by adding a source address parameter to nr_find_socket() and
requiring it to match the socket's recorded dest_addr for all
frame-dispatch lookups. The internal nr_find_next_circuit() caller,
which only checks for circuit ID availability, passes NULL to skip
the source check.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org>
---
net/netrom/af_netrom.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/netrom/af_netrom.c b/net/netrom/af_netrom.c
index b605891bf86e4..73742cc9e9e42 100644
--- a/net/netrom/af_netrom.c
+++ b/net/netrom/af_netrom.c
@@ -162,7 +162,8 @@ static struct sock *nr_find_listener(ax25_address *addr)
/*
* Find a connected NET/ROM socket given my circuit IDs.
*/
-static struct sock *nr_find_socket(unsigned char index, unsigned char id)
+static struct sock *nr_find_socket(unsigned char index, unsigned char id,
+ const ax25_address *src)
{
struct sock *s;
@@ -170,7 +171,8 @@ static struct sock *nr_find_socket(unsigned char index, unsigned char id)
sk_for_each(s, &nr_list) {
struct nr_sock *nr = nr_sk(s);
- if (nr->my_index == index && nr->my_id == id) {
+ if (nr->my_index == index && nr->my_id == id &&
+ (!src || !ax25cmp(&nr->dest_addr, src))) {
sock_hold(s);
goto found;
}
@@ -219,7 +221,8 @@ static unsigned short nr_find_next_circuit(void)
j = id % 256;
if (i != 0 && j != 0) {
- if ((sk=nr_find_socket(i, j)) == NULL)
+ sk = nr_find_socket(i, j, NULL);
+ if (!sk)
break;
sock_put(sk);
}
@@ -926,7 +929,7 @@ int nr_rx_frame(struct sk_buff *skb, struct net_device *dev)
if (frametype == NR_CONNREQ)
sk = nr_find_peer(circuit_index, circuit_id, src);
else
- sk = nr_find_socket(circuit_index, circuit_id);
+ sk = nr_find_socket(circuit_index, circuit_id, src);
}
if (sk != NULL) {
--
2.53.0
^ permalink raw reply related
* [PATCH 1/3] net: netrom: fix integer overflow in nr_queue_rx_frame()
From: Mashiro Chen @ 2026-04-07 17:15 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, gregkh, ben, linux-hams,
linux-kernel, stable, Mashiro Chen
In-Reply-To: <20260407171600.102988-1-mashiro.chen@mailbox.org>
nr_sock.fraglen is declared as unsigned short, so accumulating
received fragment lengths via
nr->fraglen += skb->len;
can silently wrap around to a small value once the total exceeds
65535 bytes. When the final fragment arrives (NR_MORE_FLAG clear),
the wrapped fraglen is passed to alloc_skb(), which allocates an
undersized buffer. The subsequent skb_put() and skb_copy_from_linear_data()
loop then writes the actual full data into it, resulting in a heap
buffer overflow.
An attacker with NR_STATE_3 access (i.e. after completing a NET/ROM
connection handshake, which open BBS/node services allow to any
callsign) can trigger this by sending a stream of NR_INFO frames
with the MORE flag set until fraglen wraps, followed by a final
NR_INFO frame.
Fix by checking whether adding the incoming skb's length to the
accumulated fraglen would exceed USHRT_MAX before each accumulation.
If so, purge the fragment queue, reset fraglen, and return an error
to signal receive-busy to the caller.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org>
---
net/netrom/nr_in.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/netrom/nr_in.c b/net/netrom/nr_in.c
index 97944db6b5ac6..0b7cdb99ae501 100644
--- a/net/netrom/nr_in.c
+++ b/net/netrom/nr_in.c
@@ -36,12 +36,22 @@ static int nr_queue_rx_frame(struct sock *sk, struct sk_buff *skb, int more)
nr_start_idletimer(sk);
if (more) {
+ if ((unsigned int)nr->fraglen + skb->len > USHRT_MAX) {
+ skb_queue_purge(&nr->frag_queue);
+ nr->fraglen = 0;
+ return 1;
+ }
nr->fraglen += skb->len;
skb_queue_tail(&nr->frag_queue, skb);
return 0;
}
if (!more && nr->fraglen > 0) { /* End of fragment */
+ if ((unsigned int)nr->fraglen + skb->len > USHRT_MAX) {
+ skb_queue_purge(&nr->frag_queue);
+ nr->fraglen = 0;
+ return 1;
+ }
nr->fraglen += skb->len;
skb_queue_tail(&nr->frag_queue, skb);
--
2.53.0
^ permalink raw reply related
* [PATCH 0/3] net: fix three security bugs in NET/ROM and ROSE stacks
From: Mashiro Chen @ 2026-04-07 17:15 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, gregkh, ben, linux-hams,
linux-kernel, stable, Mashiro Chen
This series fixes three bugs in the Linux kernel AX.25 protocol stack,
submitted on top of Greg Kroah-Hartman's frame-size validation series
(https://lore.kernel.org/r/2026040730-untagged-groin-bbb7@gregkh).
Patch 1 fixes an integer overflow in nr_queue_rx_frame(): nr_sock.fraglen
is declared as unsigned short and accumulates received fragment lengths
without overflow protection. When total received data exceeds 65535 bytes,
fraglen wraps to a small value, causing alloc_skb() to allocate a tiny
buffer followed by a full-length copy -- a heap out-of-bounds write.
Patch 2 fixes nr_find_socket() dispatching incoming NR_INFO frames by
matching only the circuit index/id bytes without validating the source
callsign against the socket's dest_addr. Any node can inject frames into
an existing STATE_3 connection by guessing the circuit ID (the value space
is only 65025 non-zero pairs and IDs are assigned sequentially). Combined
with the fraglen overflow in patch 1, this gives an unauthenticated
attacker a complete heap corruption primitive.
Patch 3 fixes an out-of-bounds read in rose_parse_ccitt(): the function
validates 10 <= l <= 20 but never checks that the remaining buffer is at
least l+2 bytes before calling memcpy(). rose_parse_national() already
performs the equivalent check; this patch adds the same guard.
Mashiro Chen (3):
net: netrom: fix integer overflow in nr_queue_rx_frame()
net: netrom: validate source address in nr_find_socket()
net: rose: fix out-of-bounds read in rose_parse_ccitt()
net/netrom/af_netrom.c | 11 +++++++----
net/netrom/nr_in.c | 10 ++++++++++
net/rose/rose_subr.c | 3 +++
3 files changed, 20 insertions(+), 4 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH net] net_sched: fix skb memory leak in deferred qdisc drops
From: Fernando Fernandez Mancera @ 2026-04-07 17:14 UTC (permalink / raw)
To: netdev; +Cc: horms, pabeni, kuba, edumazet, davem, Damilola Bello
In-Reply-To: <20260407170214.4157-2-fmancera@suse.de>
On 4/7/26 7:02 PM, Fernando Fernandez Mancera wrote:
> When the network stack cleans up the deferred list via qdisc_run_end(),
> it operates on the root qdisc. If the root qdisc do not implement the
> TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and
> gets stranded on the child's local to_free list.
>
> Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It
> fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If
> the flag is present, the packet is appended directly to the root's
> to_free list. Otherwise, drop it directly as it was done before the
> optimization was implemented.
>
> Fixes: a6efc273ab82 ("net_sched: use qdisc_dequeue_drop() in cake, codel, fq_codel")
> Reported-by: Damilola Bello <damilola@aterlo.com>
> Closes: https://lore.kernel.org/netdev/CAPgFtOLaedBMU0f_BxV2bXftTJSmJr018Q5uozOo5vVo6b9tjw@mail.gmail.com/
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> ---
> include/net/sch_generic.h | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
> index c3d657359a3d..61ba54e909f2 100644
> --- a/include/net/sch_generic.h
> +++ b/include/net/sch_generic.h
> @@ -1170,12 +1170,18 @@ static inline void tcf_kfree_skb_list(struct sk_buff *skb)
> static inline void qdisc_dequeue_drop(struct Qdisc *q, struct sk_buff *skb,
> enum skb_drop_reason reason)
> {
> + struct Qdisc *root = qdisc_root_sleeping(q);
> +
> DEBUG_NET_WARN_ON_ONCE(!(q->flags & TCQ_F_DEQUEUE_DROPS));
> DEBUG_NET_WARN_ON_ONCE(q->flags & TCQ_F_NOLOCK);
>
> - tcf_set_drop_reason(skb, reason);
> - skb->next = q->to_free;
> - q->to_free = skb;
> + if (root->flags & TCQ_F_DEQUEUE_DROPS) {
> + tcf_set_drop_reason(skb, reason);
> + skb->next = q->to_free;
> + q->to_free = skb;
> + } else {
> + kfree_skb_reason(skb, reason);
> + }
> }
>
*sigh* this is missing the following diff - tested it but forgot to
amend it. Anyway, Eric let me know what do you think, if you like this
solution I can send the v2 appending the skb to the root's to_free list
properly.
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index 61ba54e909f2..0e4166319c02 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -1177,8 +1177,8 @@ static inline void qdisc_dequeue_drop(struct Qdisc
*q, struct sk_buff *skb,
if (root->flags & TCQ_F_DEQUEUE_DROPS) {
tcf_set_drop_reason(skb, reason);
- skb->next = q->to_free;
- q->to_free = skb;
+ skb->next = root->to_free;
+ root->to_free = skb;
} else {
kfree_skb_reason(skb, reason);
}
^ permalink raw reply related
* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Jon Kohler @ 2026-04-07 17:12 UTC (permalink / raw)
To: Jim Mattson
Cc: Pawan Gupta, x86@kernel.org, Nikolay Borisov, H. Peter Anvin,
Josh Poimboeuf, David Kaplan, Sean Christopherson,
Borislav Petkov, Dave Hansen, Peter Zijlstra, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, KP Singh, Jiri Olsa,
David S. Miller, David Laight, Andy Lutomirski, Thomas Gleixner,
Ingo Molnar, David Ahern, Martin KaFai Lau, Eduard Zingerman,
Song Liu, Yonghong Song, John Fastabend, Stanislav Fomichev,
Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Asit Mallick,
Tao Zhang, bpf@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, chao.gao@intel.com
In-Reply-To: <CALMp9eTA3cXxuOT4dq=6y1hx52gPH1ywwTEmPQ5-fA-vz6r3VQ@mail.gmail.com>
> On Apr 7, 2026, at 11:46 AM, Jim Mattson <jmattson@google.com> wrote:
>
> On Tue, Apr 7, 2026 at 9:40 AM Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com> wrote:
>>
>> On Mon, Apr 06, 2026 at 07:23:25AM -0700, Jim Mattson wrote:
>>> Yes, but the guest needs a way to determine whether the hypervisor
>>> will do what's necessary to make the short sequence effective. And, in
>>> particular, no KVM hypervisor today is prepared to do that.
>>>
>>> When running under a hypervisor, without BHI_CTRL and without any
>>> evidence to the contrary, the guest must assume that the longer
>>> sequence is necessary. At the very least, we need a CPUID or MSR bit
>>> that says, "the short BHB clearing sequence is adequate for this
>>> vCPU."
>>
>> After discussing this internally, the consensus is that the best path
>> forward is to add virtual SPEC_CTRL support to KVM, which also aligns with
>> Intel's guidance. In the long term, virtual SPEC_CTRL can benefit future
>> mitigations as well. As with many other mitigations (e.g. microcode), the
>> guest would rely on the host to enforce the appropriate protections.
Would we have to wait for virtual SPEC_CTRL to get this optimization?
Or would that be a future enhancement to make this more prescriptive?
>
> I don't think it's reasonable for the guest to rely on a future
> implementation to enforce the appropriate protections.
>
> This is already a problem today. If a guest sees that BHI_CTRL is
> unavailable, it will deploy the short BHB clearing sequence and
> declare that the vulnerability is mitigated. That isn't true if the
> guest is running on Alder Lake or newer.
^ permalink raw reply
* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-04-07 17:11 UTC (permalink / raw)
To: Jim Mattson
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm, Asit Mallick,
Tao Zhang, bpf, netdev, linux-doc, chao.gao
In-Reply-To: <CALMp9eTA3cXxuOT4dq=6y1hx52gPH1ywwTEmPQ5-fA-vz6r3VQ@mail.gmail.com>
On Tue, Apr 07, 2026 at 09:46:07AM -0700, Jim Mattson wrote:
> On Tue, Apr 7, 2026 at 9:40 AM Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com> wrote:
> >
> > On Mon, Apr 06, 2026 at 07:23:25AM -0700, Jim Mattson wrote:
> > > Yes, but the guest needs a way to determine whether the hypervisor
> > > will do what's necessary to make the short sequence effective. And, in
> > > particular, no KVM hypervisor today is prepared to do that.
> > >
> > > When running under a hypervisor, without BHI_CTRL and without any
> > > evidence to the contrary, the guest must assume that the longer
> > > sequence is necessary. At the very least, we need a CPUID or MSR bit
> > > that says, "the short BHB clearing sequence is adequate for this
> > > vCPU."
> >
> > After discussing this internally, the consensus is that the best path
> > forward is to add virtual SPEC_CTRL support to KVM, which also aligns with
> > Intel's guidance. In the long term, virtual SPEC_CTRL can benefit future
> > mitigations as well. As with many other mitigations (e.g. microcode), the
> > guest would rely on the host to enforce the appropriate protections.
>
> I don't think it's reasonable for the guest to rely on a future
> implementation to enforce the appropriate protections.
>
> This is already a problem today. If a guest sees that BHI_CTRL is
> unavailable, it will deploy the short BHB clearing sequence and
> declare that the vulnerability is mitigated. That isn't true if the
> guest is running on Alder Lake or newer.
In any case, there is a change required in the kernel either for the guest
or the host, they both are future implementations. Why not implement the
one that is more future proof.
^ permalink raw reply
* [PATCH net] net_sched: fix skb memory leak in deferred qdisc drops
From: Fernando Fernandez Mancera @ 2026-04-07 17:02 UTC (permalink / raw)
To: netdev
Cc: horms, pabeni, kuba, edumazet, davem, Fernando Fernandez Mancera,
Damilola Bello
When the network stack cleans up the deferred list via qdisc_run_end(),
it operates on the root qdisc. If the root qdisc do not implement the
TCQ_F_DEQUEUE_DROPS flag the packets queue to free are never freed and
gets stranded on the child's local to_free list.
Fix this by making qdisc_dequeue_drop() aware of the root qdisc. It
fetches the root qdisc and check for the TCQ_F_DEQUEUE_DROPS flag. If
the flag is present, the packet is appended directly to the root's
to_free list. Otherwise, drop it directly as it was done before the
optimization was implemented.
Fixes: a6efc273ab82 ("net_sched: use qdisc_dequeue_drop() in cake, codel, fq_codel")
Reported-by: Damilola Bello <damilola@aterlo.com>
Closes: https://lore.kernel.org/netdev/CAPgFtOLaedBMU0f_BxV2bXftTJSmJr018Q5uozOo5vVo6b9tjw@mail.gmail.com/
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
include/net/sch_generic.h | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index c3d657359a3d..61ba54e909f2 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -1170,12 +1170,18 @@ static inline void tcf_kfree_skb_list(struct sk_buff *skb)
static inline void qdisc_dequeue_drop(struct Qdisc *q, struct sk_buff *skb,
enum skb_drop_reason reason)
{
+ struct Qdisc *root = qdisc_root_sleeping(q);
+
DEBUG_NET_WARN_ON_ONCE(!(q->flags & TCQ_F_DEQUEUE_DROPS));
DEBUG_NET_WARN_ON_ONCE(q->flags & TCQ_F_NOLOCK);
- tcf_set_drop_reason(skb, reason);
- skb->next = q->to_free;
- q->to_free = skb;
+ if (root->flags & TCQ_F_DEQUEUE_DROPS) {
+ tcf_set_drop_reason(skb, reason);
+ skb->next = q->to_free;
+ q->to_free = skb;
+ } else {
+ kfree_skb_reason(skb, reason);
+ }
}
/* Instead of calling kfree_skb() while root qdisc lock is held,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 net] af_unix: Give up GC if MSG_PEEK intervened.
From: Greg KH @ 2026-04-07 17:01 UTC (permalink / raw)
To: Lee Jones
Cc: Kuniyuki Iwashima, stable, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Kuniyuki Iwashima,
Linus Torvalds, netdev, Igor Ushakov
In-Reply-To: <20260407155827.GA1993342@google.com>
On Tue, Apr 07, 2026 at 04:58:27PM +0100, Lee Jones wrote:
> INTENTIONAL TOP POST
>
> I note that this was not sent to Stable, but it should be included please.
As mentioned on chat, It already is, if you want it backported further,
can you please provide working backports?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net-next v2 1/2] dt-bindings: net: document Microchip PIC64-HPSC/HX MDIO controller
From: Rob Herring @ 2026-04-07 17:00 UTC (permalink / raw)
To: Charles Perry
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Krzysztof Kozlowski, Conor Dooley,
Heiner Kallweit, Russell King, devicetree, linux-kernel
In-Reply-To: <20260323220254.3822444-2-charles.perry@microchip.com>
On Mon, Mar 23, 2026 at 03:02:53PM -0700, Charles Perry wrote:
> This MDIO hardware is based on a Microsemi design supported in Linux by
> mdio-mscc-miim.c. However, The register interface is completely different
> with pic64hpsc, hence the need for separate documentation.
>
> The hardware supports C22 and C45.
>
> The documentation recommends an input clock of 156.25MHz and a prescaler
> of 39, which yields an MDIO clock of 1.95MHz.
>
> The hardware supports an interrupt pin to signal transaction completion
> which is not strictly needed as the software can also poll a "TRIGGER"
> bit for this.
>
> Signed-off-by: Charles Perry <charles.perry@microchip.com>
> ---
>
> Notes:
> Changes in v2:
> - Make "clocks" and "interrupts" required (Andrew)
> - Add a default value to "clock-frequency" (Andrew)
>
> .../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
>
> diff --git a/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
> new file mode 100644
> index 000000000000..d690afe3d3cf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/microchip,pic64hpsc-mdio.yaml
> @@ -0,0 +1,68 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/microchip,pic64hpsc-mdio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip PIC64-HPSC/HX MDIO controller
> +
> +maintainers:
> + - Charles Perry <charles.perry@microchip.com>
> +
> +description: |
Don't need '|' if no formatting to preserve.
> + Microchip PIC64-HPSC/HX SoCs have two MDIO bus controller. This MDIO bus
s/controller/controllers/
Though how many instances there are is not really applicable to the
binding unless there is some difference.
> + controller supports C22 and C45 register access. It is named "MDIO Initiator"
> + in the documentation.
> +
> +allOf:
> + - $ref: mdio.yaml#
> +
> +properties:
> + compatible:
> + oneOf:
> + - const: microchip,pic64hpsc-mdio
> + - items:
> + - const: microchip,pic64hx-mdio
> + - const: microchip,pic64hpsc-mdio
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-frequency:
> + default: 2500000
> +
> + interrupts:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - interrupts
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + bus {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + mdio@4000C21E000 {
Unit-addresses are lower case hex.
> + compatible = "microchip,pic64hpsc-mdio";
> + reg = <0x400 0x0C21E000 0x0 0x1000>;
And generally we use lower case here too.
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&svc_clk>;
> + interrupt-parent = <&saplic0>;
> + interrupts = <168 IRQ_TYPE_LEVEL_HIGH>;
> +
> + phy0: ethernet-phy@0 {
Drop unused labels.
> + reg = <0>;
> + };
> + };
> + };
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH net-next v4 3/3] net: phy: add a PHY write barrier when disabling interrupts
From: Andrew Lunn @ 2026-04-07 16:59 UTC (permalink / raw)
To: Charles Perry
Cc: Russell King (Oracle), netdev, Heiner Kallweit, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <adUupYuD6tM3ahaR@bby-cbu-swbuild03.eng.microchip.com>
> static void phy_write_barrier(struct phy_device *phydev)
> {
> int err;
>
> err = mdiobus_read(phydev->mdio.bus, phydev->mdio.addr, MII_PHYSID1);
> if (err == -EOPNOTSUPP)
> mdiobus_c45_read(phydev->mdio.bus, phydev->mdio.addr,
> __ffs(phydev->c45_ids.mmds_present),
> MII_PHYSID1);
> }
Using __ffs() is maybe more complex than needed.
All you are trying to do is ensure the last write happened, by doing a
read. Any read should work, even if the device does not respond. We
just need to be careful not to read a register which might clear on
read, such as an interrupt status register, or the link status, which
latches. MII_PHYID1 is safe. Since we throw away the value, we don't
care if the MMD is not present, the read will still flush the previous
write. So i would replace the _ffs() with a hard coded value. KISS.
> Do you think there's any way I can test this on my VSC8574 or VSC8541? It
> supports some C45 registers for EEE but not the device discovery part.
It is not so easy to do. You need to hack the C22 read so that is
returns EOPNOTSUPP, but you also need the first few reads to return a
valid value otherwise the probe will fail.
I think this is one of the cases that if the reviewers thinks its
looks O.K, we can accept it without extensive testing.
Andrew
^ permalink raw reply
* [PATCH net v2 4/4] ice: skip unnecessary VF reset when setting trust
From: Jose Ignacio Tornos Martinez @ 2026-04-07 16:52 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, jesse.brandeburg, anthony.l.nguyen, davem,
edumazet, kuba, pabeni, Jose Ignacio Tornos Martinez
In-Reply-To: <20260407165206.1121317-1-jtornosm@redhat.com>
Similar to the i40e fix, ice_set_vf_trust() unconditionally calls
ice_reset_vf() when the trust setting changes.
The ice driver already has logic to clean up MAC LLDP filters when
removing trust, which is the only operation that requires filter
synchronization. After this cleanup, the VF reset is only necessary if
there were actually filters to remove.
For all other trust state changes (setting trust, or removing trust
when no filters exist), the reset is unnecessary as filter
synchronization happens naturally through normal VF operations.
Fix by only triggering the VF reset when removing trust AND filters
were actually cleaned up (num_mac_lldp was non-zero).
This saves some time and eliminates unnecessary service disruption when
changing VF trust settings if not necessary.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
drivers/net/ethernet/intel/ice/ice_sriov.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 7e00e091756d..23f692b1e86c 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1399,14 +1399,19 @@ int ice_set_vf_trust(struct net_device *netdev, int vf_id, bool trusted)
mutex_lock(&vf->cfg_lock);
- while (!trusted && vf->num_mac_lldp)
- ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf), false);
-
vf->trusted = trusted;
- ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
dev_info(ice_pf_to_dev(pf), "VF %u is now %strusted\n",
vf_id, trusted ? "" : "un");
+ /* Only reset VF if removing trust and there are MAC LLDP filters
+ * to clean up. Reset is needed to ensure filter removal completes.
+ */
+ if (!trusted && vf->num_mac_lldp) {
+ while (vf->num_mac_lldp)
+ ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf), false);
+ ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
+ }
+
mutex_unlock(&vf->cfg_lock);
out_put_vf:
--
2.53.0
^ permalink raw reply related
* [PATCH net v2 3/4] iavf: send MAC change request synchronously
From: Jose Ignacio Tornos Martinez @ 2026-04-07 16:52 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, jesse.brandeburg, anthony.l.nguyen, davem,
edumazet, kuba, pabeni, Jose Ignacio Tornos Martinez, stable
In-Reply-To: <20260407165206.1121317-1-jtornosm@redhat.com>
After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs
operations"), iavf_set_mac() is called with the netdev instance lock
already held.
The function queues a MAC address change request via
iavf_replace_primary_mac() and then waits for completion. However, in
the current flow, the actual virtchnl message is sent by the watchdog
task, which also needs to acquire the netdev lock to run. Additionally,
the adminq_task which processes virtchnl responses also needs the netdev
lock.
This creates a deadlock scenario:
1. iavf_set_mac() holds netdev lock and waits for MAC change
2. Watchdog needs netdev lock to send the request -> blocked
3. Even if request is sent, adminq_task needs netdev lock to process
PF response -> blocked
4. MAC change times out after 2.5 seconds
5. iavf_set_mac() returns -EAGAIN
This particularly affects VFs during bonding setup when multiple VFs are
enslaved in quick succession.
Fix by implementing a synchronous MAC change operation similar to the
approach used in commit fdadbf6e84c4 ("iavf: fix incorrect reset handling
in callbacks").
The solution:
1. Send the virtchnl ADD_ETH_ADDR message directly (not via watchdog)
2. Poll the admin queue hardware directly for responses
3. Process all received messages (including non-MAC messages)
4. Return when MAC change completes or times out
A new generic function iavf_poll_virtchnl_response() is introduced that
can be reused for any future synchronous virtchnl operations. It takes a
callback to check completion, allowing flexible condition checking.
This allows the operation to complete synchronously while holding
netdev_lock, without relying on watchdog or adminq_task. The function
can sleep for up to 2.5 seconds polling hardware, but this is acceptable
since netdev_lock is per-device and only serializes operations on the
same interface.
To support this, change iavf_add_ether_addrs() to return an error code
instead of void, allowing callers to detect failures.
Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations")
cc: stable@vger.kernel.org
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v2: Complete rewrite using synchronous polling approach instead of dropping
the netdev lock. New approach:
- Polls admin queue hardware directly (similar to iavf_reset_step)
- Processes all virtchnl messages inline while holding netdev_lock
- Introduced generic iavf_poll_virtchnl_response() for code reuse
- No lock dropping, following accepted pattern from ndo_change_mtu fix
v1: https://lore.kernel.org/netdev/20260406112057.906685-4-jtornosm@redhat.com/
drivers/net/ethernet/intel/iavf/iavf.h | 2 +-
drivers/net/ethernet/intel/iavf/iavf_main.c | 118 +++++++++++++++---
.../net/ethernet/intel/iavf/iavf_virtchnl.c | 11 +-
3 files changed, 110 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf.h b/drivers/net/ethernet/intel/iavf/iavf.h
index e9fb0a0919e3..5bc23519fe9c 100644
--- a/drivers/net/ethernet/intel/iavf/iavf.h
+++ b/drivers/net/ethernet/intel/iavf/iavf.h
@@ -589,7 +589,7 @@ void iavf_configure_queues(struct iavf_adapter *adapter);
void iavf_enable_queues(struct iavf_adapter *adapter);
void iavf_disable_queues(struct iavf_adapter *adapter);
void iavf_map_queues(struct iavf_adapter *adapter);
-void iavf_add_ether_addrs(struct iavf_adapter *adapter);
+int iavf_add_ether_addrs(struct iavf_adapter *adapter);
void iavf_del_ether_addrs(struct iavf_adapter *adapter);
void iavf_add_vlans(struct iavf_adapter *adapter);
void iavf_del_vlans(struct iavf_adapter *adapter);
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 67aa14350b1b..2ef30b1ef35c 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -1047,6 +1047,105 @@ static bool iavf_is_mac_set_handled(struct net_device *netdev,
return ret;
}
+/**
+ * iavf_poll_virtchnl_response - Poll admin queue for virtchnl response
+ * @adapter: board private structure
+ * @condition: callback to check if desired response received
+ * @cond_data: context data passed to condition callback
+ * @timeout_ms: maximum time to wait in milliseconds
+ *
+ * Polls admin queue and processes all messages until condition returns true
+ * or timeout expires. Caller must hold netdev_lock. This can sleep for up to
+ * timeout_ms while polling hardware.
+ *
+ * Returns 0 on success (condition met), -EAGAIN on timeout or error
+ */
+static int iavf_poll_virtchnl_response(struct iavf_adapter *adapter,
+ bool (*condition)(struct iavf_adapter *, void *),
+ void *cond_data,
+ unsigned int timeout_ms)
+{
+ struct iavf_hw *hw = &adapter->hw;
+ struct iavf_arq_event_info event;
+ enum virtchnl_ops v_op;
+ enum iavf_status v_ret;
+ unsigned long timeout;
+ int ret;
+
+ netdev_assert_locked(adapter->netdev);
+
+ event.buf_len = IAVF_MAX_AQ_BUF_SIZE;
+ event.msg_buf = kzalloc(event.buf_len, GFP_KERNEL);
+ if (!event.msg_buf)
+ return -ENOMEM;
+
+ timeout = jiffies + msecs_to_jiffies(timeout_ms);
+ while (time_before(jiffies, timeout)) {
+ if (condition(adapter, cond_data)) {
+ ret = 0;
+ goto out;
+ }
+
+ ret = iavf_clean_arq_element(hw, &event, NULL);
+ if (!ret) {
+ v_op = (enum virtchnl_ops)le32_to_cpu(event.desc.cookie_high);
+ v_ret = (enum iavf_status)le32_to_cpu(event.desc.cookie_low);
+
+ iavf_virtchnl_completion(adapter, v_op, v_ret,
+ event.msg_buf, event.msg_len);
+
+ memset(event.msg_buf, 0, IAVF_MAX_AQ_BUF_SIZE);
+ }
+
+ usleep_range(1000, 2000);
+ }
+
+ ret = -EAGAIN;
+out:
+ kfree(event.msg_buf);
+ return ret;
+}
+
+/**
+ * iavf_mac_change_done - Check if MAC change completed
+ * @adapter: board private structure
+ * @data: MAC address being checked (as void *)
+ *
+ * Callback for iavf_poll_virtchnl_response() to check if MAC change completed.
+ *
+ * Returns true if MAC change completed, false otherwise
+ */
+static bool iavf_mac_change_done(struct iavf_adapter *adapter, void *data)
+{
+ const u8 *addr = data;
+
+ return iavf_is_mac_set_handled(adapter->netdev, addr);
+}
+
+/**
+ * iavf_set_mac_sync - Synchronously change MAC address
+ * @adapter: board private structure
+ * @addr: MAC address to set
+ *
+ * Sends MAC change request to PF and polls admin queue for response.
+ * Caller must hold netdev_lock. This can sleep for up to 2.5 seconds.
+ *
+ * Returns 0 on success or error
+ */
+static int iavf_set_mac_sync(struct iavf_adapter *adapter, const u8 *addr)
+{
+ int ret;
+
+ netdev_assert_locked(adapter->netdev);
+
+ ret = iavf_add_ether_addrs(adapter);
+ if (ret)
+ return ret;
+
+ return iavf_poll_virtchnl_response(adapter, iavf_mac_change_done,
+ (void *)addr, 2500);
+}
+
/**
* iavf_set_mac - NDO callback to set port MAC address
* @netdev: network interface device structure
@@ -1067,25 +1166,12 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
return -EADDRNOTAVAIL;
ret = iavf_replace_primary_mac(adapter, addr->sa_data);
-
if (ret)
return ret;
- ret = wait_event_interruptible_timeout(adapter->vc_waitqueue,
- iavf_is_mac_set_handled(netdev, addr->sa_data),
- msecs_to_jiffies(2500));
-
- /* If ret < 0 then it means wait was interrupted.
- * If ret == 0 then it means we got a timeout.
- * else it means we got response for set MAC from PF,
- * check if netdev MAC was updated to requested MAC,
- * if yes then set MAC succeeded otherwise it failed return -EACCES
- */
- if (ret < 0)
- return ret;
-
- if (!ret)
- return -EAGAIN;
+ ret = iavf_set_mac_sync(adapter, addr->sa_data);
+ if (ret)
+ return ret;
if (!ether_addr_equal(netdev->dev_addr, addr->sa_data))
return -EACCES;
diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
index a52c100dcbc5..fdddf4b033ca 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
@@ -555,8 +555,10 @@ iavf_set_mac_addr_type(struct virtchnl_ether_addr *virtchnl_ether_addr,
* @adapter: adapter structure
*
* Request that the PF add one or more addresses to our filters.
+ *
+ * Returns 0 on success or error
**/
-void iavf_add_ether_addrs(struct iavf_adapter *adapter)
+int iavf_add_ether_addrs(struct iavf_adapter *adapter)
{
struct virtchnl_ether_addr_list *veal;
struct iavf_mac_filter *f;
@@ -568,7 +570,7 @@ void iavf_add_ether_addrs(struct iavf_adapter *adapter)
/* bail because we already have a command pending */
dev_err(&adapter->pdev->dev, "Cannot add filters, command %d pending\n",
adapter->current_op);
- return;
+ return -EBUSY;
}
spin_lock_bh(&adapter->mac_vlan_list_lock);
@@ -580,7 +582,7 @@ void iavf_add_ether_addrs(struct iavf_adapter *adapter)
if (!count) {
adapter->aq_required &= ~IAVF_FLAG_AQ_ADD_MAC_FILTER;
spin_unlock_bh(&adapter->mac_vlan_list_lock);
- return;
+ return 0;
}
adapter->current_op = VIRTCHNL_OP_ADD_ETH_ADDR;
@@ -595,7 +597,7 @@ void iavf_add_ether_addrs(struct iavf_adapter *adapter)
veal = kzalloc(len, GFP_ATOMIC);
if (!veal) {
spin_unlock_bh(&adapter->mac_vlan_list_lock);
- return;
+ return -ENOMEM;
}
veal->vsi_id = adapter->vsi_res->vsi_id;
@@ -617,6 +619,7 @@ void iavf_add_ether_addrs(struct iavf_adapter *adapter)
iavf_send_pf_msg(adapter, VIRTCHNL_OP_ADD_ETH_ADDR, (u8 *)veal, len);
kfree(veal);
+ return 0;
}
/**
--
2.53.0
^ permalink raw reply related
* [PATCH net v2 2/4] i40e: skip unnecessary VF reset when setting trust
From: Jose Ignacio Tornos Martinez @ 2026-04-07 16:52 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, jesse.brandeburg, anthony.l.nguyen, davem,
edumazet, kuba, pabeni, Jose Ignacio Tornos Martinez
In-Reply-To: <20260407165206.1121317-1-jtornosm@redhat.com>
When VF trust is changed, i40e_ndo_set_vf_trust() always calls
i40e_vc_reset_vf() to sync MAC/VLAN filters. However, this reset is
only necessary when trust is removed from a VF that has ADQ (advanced
queue) filters, which need to be deleted
In all other cases, the reset causes a ~10 second delay during which:
- VF must reinitialize completely
- Any in-progress operations (like bonding enslave) fail with timeouts
- VF is unavailable
The MAC/VLAN filter sync will happen naturally through the normal VF
operations and doesn't require a forced reset.
Fix by only resetting when actually needed: when removing trust from a
VF that has ADQ cloud filters. For all other trust changes, just update
the trust flag and let normal operation continue.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index a26c3d47ec15..fea267af7afe 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -4987,16 +4987,21 @@ int i40e_ndo_set_vf_trust(struct net_device *netdev, int vf_id, bool setting)
set_bit(__I40E_MACVLAN_SYNC_PENDING, pf->state);
pf->vsi[vf->lan_vsi_idx]->flags |= I40E_VSI_FLAG_FILTER_CHANGED;
- i40e_vc_reset_vf(vf, true);
dev_info(&pf->pdev->dev, "VF %u is now %strusted\n",
vf_id, setting ? "" : "un");
+ /* Only reset VF if we're removing trust and it has ADQ cloud filters.
+ * Cloud filters can only be added when trusted, so they must be
+ * removed when trust is revoked. Other trust changes don't require
+ * reset - MAC/VLAN filter sync happens through normal operation.
+ */
if (vf->adq_enabled) {
if (!vf->trusted) {
dev_info(&pf->pdev->dev,
"VF %u no longer Trusted, deleting all cloud filters\n",
vf_id);
i40e_del_all_cloud_filters(vf);
+ i40e_vc_reset_vf(vf, true);
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH net v2 1/4] iavf: return EBUSY if reset in progress or not ready during MAC change
From: Jose Ignacio Tornos Martinez @ 2026-04-07 16:52 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, jesse.brandeburg, anthony.l.nguyen, davem,
edumazet, kuba, pabeni, Jose Ignacio Tornos Martinez
In-Reply-To: <20260407165206.1121317-1-jtornosm@redhat.com>
When a MAC address change is requested while the VF is resetting or still
initializing, return -EBUSY immediately instead of attempting the
operation.
Additionally, during early initialization states (before __IAVF_DOWN),
the PF may be slow to respond to MAC change requests, causing long
delays. Only allow MAC changes once the VF reaches __IAVF_DOWN state or
later, when the watchdog is running and the VF is ready for operations.
After commit ad7c7b2172c3 ("net: hold netdev instance lock
during sysfs operations"), MAC changes are called with the netdev lock
held, so we should not wait with the lock held during reset or
initialization. This allows the caller to retry or handle the busy state
appropriately without blocking other operations.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v2: Add state check to prevent MAC changes during early initialization
states (before __IAVF_DOWN). In v1 this patch only checked for reset
in progress.
v1: https://lore.kernel.org/netdev/20260406112057.906685-2-jtornosm@redhat.com/
drivers/net/ethernet/intel/iavf/iavf_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index dad001abc908..67aa14350b1b 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -1060,6 +1060,9 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
struct sockaddr *addr = p;
int ret;
+ if (iavf_is_reset_in_progress(adapter) || adapter->state < __IAVF_DOWN)
+ return -EBUSY;
+
if (!is_valid_ether_addr(addr->sa_data))
return -EADDRNOTAVAIL;
--
2.53.0
^ permalink raw reply related
* [PATCH net v2 0/4] Fix i40e/ice/iavf VF bonding after netdev lock changes
From: Jose Ignacio Tornos Martinez @ 2026-04-07 16:52 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, jesse.brandeburg, anthony.l.nguyen, davem,
edumazet, kuba, pabeni, Jose Ignacio Tornos Martinez
This series fixes VF bonding failures introduced by commit ad7c7b2172c3
("net: hold netdev instance lock during sysfs operations").
When adding VFs to a bond immediately after setting trust mode, MAC
address changes fail with -EAGAIN, preventing bonding setup. This
affects both i40e (700-series) and ice (800-series) Intel NICs.
The core issue is lock contention: iavf_set_mac() is now called with the
netdev lock held and waits for MAC change completion while holding it.
However, both the watchdog task that sends the request and the adminq_task
that processes PF responses also need this lock, creating a deadlock where
neither can run, causing timeouts.
Additionally, setting VF trust triggers an unnecessary ~10 second VF reset
in i40e driver that delays bonding setup, even though filter
synchronization happens naturally during normal VF operation. For ice
driver, the delay is not so big, but in the same way the operation is not
necessary.
This series:
1. Adds safety guard to prevent MAC changes during reset or early
initialization (before VF is ready)
2. Eliminates unnecessary VF reset when setting trust in i40e
3. Fixes lock contention by polling admin queue synchronously
4. Eliminates unnecessary VF reset when setting trust in ice
The key fix (patch 3/4) implements a synchronous MAC change operation
similar to the approach used for ndo_change_mtu deadlock fix:
https://lore.kernel.org/intel-wired-lan/20260211191855.1532226-1-poros@redhat.com/
Instead of scheduling work and waiting, it:
- Sends the virtchnl message directly (not via watchdog)
- Polls the admin queue hardware directly for responses
- Processes all messages inline (including non-MAC messages)
- Returns when complete or times out
This allows the operation to complete synchronously while holding
netdev_lock, without relying on watchdog or adminq_task. A new generic
iavf_poll_virtchnl_response() function is introduced that can be reused
for future synchronous virtchnl operations.
The function can sleep for up to 2.5 seconds polling hardware, but this
is acceptable since netdev_lock is per-device and only serializes
operations on the same interface.
Testing shows VF bonding now works reliably in ~5 seconds vs 15+ seconds
before (i40e), without timeouts or errors (i40e and ice).
Tested on Intel 700-series (i40e) and 800-series (ice) dual-port NICs
with iavf driver.
Thanks to Jan Tluka <jtluka@redhat.com> and Yuying Ma <yuma@redhat.com> for
reporting the issues.
Jose Ignacio Tornos Martinez (4):
iavf: return EBUSY if reset in progress during MAC change
i40e: skip unnecessary VF reset when setting trust
iavf: send MAC change request synchronously
ice: skip unnecessary VF reset when setting trust
---
v2:
- Patch 1: Add state check to prevent MAC changes during early
initialization (before __IAVF_DOWN state)
- Patch 3: Use synchronous polling approach instead of dropping lock,
following the pattern from ndo_change_mtu deadlock fix
- Introduce generic iavf_poll_virtchnl_response() for code reuse
- Add patch 4/4 to fix the same trust reset issue in ice driver
- Add testing confirmation for both i40e and ice hardware
- No changes to patch 2 from v1
v1: https://lore.kernel.org/netdev/20260406112057.906685-1-jtornosm@redhat.com/
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 17 ++-
drivers/net/ethernet/intel/iavf/iavf.h | 2 +-
drivers/net/ethernet/intel/iavf/iavf_main.c | 98 +++++++++++++++++-
drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 15 +--
drivers/net/ethernet/intel/ice/ice_sriov.c | 15 ++-
5 files changed, 123 insertions(+), 24 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH net v2] net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf
From: Simon Horman @ 2026-04-07 16:50 UTC (permalink / raw)
To: Mashiro Chen
Cc: netdev, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, syzbot+ecdb8c9878a81eb21e54, ajk, linux-hams
In-Reply-To: <20260404100350.299117-1-mashiro.chen@mailbox.org>
On Sat, Apr 04, 2026 at 06:03:50PM +0800, Mashiro Chen wrote:
> sixpack_receive_buf() does not properly skip bytes with TTY error flags.
> The while loop iterates through the flags buffer but never advances the
> data pointer (cp), and passes the original count including error bytes
> to sixpack_decode(). This causes sixpack_decode() to process bytes that
> should have been skipped due to TTY errors.
>
> Fix this by processing bytes one at a time, advancing cp on each
> iteration, and only passing non-error bytes to sixpack_decode().
> This matches the pattern used by slip_receive_buf() and
> mkiss_receive_buf() for the same purpose.
>
> Reported-by: syzbot+ecdb8c9878a81eb21e54@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=ecdb8c9878a81eb21e54
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Suggested-by: Simon Horman <horms@kernel.org>
FWIIW, I don't think my suggested by tag is strictly necessary here:
I just suggested a minor tweak, not the idea the patch implements
> Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org>
Sorry for not noticing this earlier, but AI generated review flags
that while this change looks correct, it's not clear how it relates
to the sysbot report: IOW, how is it that bytes with TTY error flags
may be uninitialized?
...
^ permalink raw reply
* [PATCH net-next 2/2] selftests: drv-net: ntuple: Add dst-ip, src-port, dst-port fields
From: Dimitri Daskalakis @ 2026-04-07 16:49 UTC (permalink / raw)
To: David S . Miller
Cc: Andrew Lunn, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Shuah Khan, Willem de Bruijn, Petr Machata, David Wei,
Chris J Arges, Carolina Jubran, Dimitri Daskalakis, netdev,
linux-kselftest
In-Reply-To: <20260407164954.2977820-1-dimitri.daskalakis1@gmail.com>
From: Dimitri Daskalakis <daskald@meta.com>
Extend the ntuple flow steering test to cover dst-ip, src-port, and
dst-port fields. The test supports arbitrary combinations of the fields,
for now we test src_ip/dst_ip, and src_ip/dst_ip/src_port/dst_port.
The tests currently match full fields, but we can consider adding
support for masked fields in the future.
TAP version 13
1..24
ok 1 ntuple.queue.tcp4.src_ip
ok 2 ntuple.queue.tcp4.dst_ip
ok 3 ntuple.queue.tcp4.src_port
ok 4 ntuple.queue.tcp4.dst_port
ok 5 ntuple.queue.tcp4.src_ip.dst_ip
ok 6 ntuple.queue.tcp4.src_ip.dst_ip.src_port.dst_port
ok 7 ntuple.queue.udp4.src_ip
ok 8 ntuple.queue.udp4.dst_ip
ok 9 ntuple.queue.udp4.src_port
ok 10 ntuple.queue.udp4.dst_port
ok 11 ntuple.queue.udp4.src_ip.dst_ip
ok 12 ntuple.queue.udp4.src_ip.dst_ip.src_port.dst_port
ok 13 ntuple.queue.tcp6.src_ip
ok 14 ntuple.queue.tcp6.dst_ip
ok 15 ntuple.queue.tcp6.src_port
ok 16 ntuple.queue.tcp6.dst_port
ok 17 ntuple.queue.tcp6.src_ip.dst_ip
ok 18 ntuple.queue.tcp6.src_ip.dst_ip.src_port.dst_port
ok 19 ntuple.queue.udp6.src_ip
ok 20 ntuple.queue.udp6.dst_ip
ok 21 ntuple.queue.udp6.src_port
ok 22 ntuple.queue.udp6.dst_port
ok 23 ntuple.queue.udp6.src_ip.dst_ip
ok 24 ntuple.queue.udp6.src_ip.dst_ip.src_port.dst_port
# Totals: pass:24 fail:0 xfail:0 xpass:0 skip:0 error:0
Signed-off-by: Dimitri Daskalakis <daskald@meta.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
.../selftests/drivers/net/hw/ntuple.py | 29 +++++++++++++++----
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/drivers/net/hw/ntuple.py b/tools/testing/selftests/drivers/net/hw/ntuple.py
index c50b76198fba..12f0d395f825 100755
--- a/tools/testing/selftests/drivers/net/hw/ntuple.py
+++ b/tools/testing/selftests/drivers/net/hw/ntuple.py
@@ -9,11 +9,14 @@ from lib.py import ksft_eq, ksft_ge
from lib.py import ksft_variants, KsftNamedVariant
from lib.py import EthtoolFamily, NetDrvEpEnv, NetdevFamily
from lib.py import KsftSkipEx
-from lib.py import cmd, ethtool, defer, rand_port, bkg, wait_port_listen
+from lib.py import cmd, ethtool, defer, rand_ports, bkg, wait_port_listen
class NtupleField(Enum):
SRC_IP = auto()
+ DST_IP = auto()
+ SRC_PORT = auto()
+ DST_PORT = auto()
def _require_ntuple(cfg):
@@ -69,7 +72,7 @@ def _setup_isolated_queue(cfg):
return random.randint(1, desired_queues - 1)
-def _send_traffic(cfg, ipver, proto, dst_port, pkt_cnt=40):
+def _send_traffic(cfg, ipver, proto, dst_port, src_port, pkt_cnt=40):
"""Generate traffic with the desired flow signature."""
cfg.require_cmd("socat", remote=True)
@@ -86,28 +89,42 @@ def _send_traffic(cfg, ipver, proto, dst_port, pkt_cnt=40):
send_cmd = f"""
bash -c 'for i in $(seq {pkt_cnt}); do echo msg; sleep 0.02; done' |
socat -{ipver} -u - \
- {socat_proto}:{dst_addr}:{dst_port},reuseaddr{extra_opts}
+ {socat_proto}:{dst_addr}:{dst_port},sourceport={src_port},reuseaddr{extra_opts}
"""
cmd(send_cmd, shell=True, host=cfg.remote)
def _add_ntuple_rule_and_send_traffic(cfg, ipver, proto, fields, test_queue):
- dst_port = rand_port()
+ ports = rand_ports(2)
+ src_port = ports[0]
+ dst_port = ports[1]
flow_parts = [f"flow-type {proto}{ipver}"]
for field in fields:
if field == NtupleField.SRC_IP:
flow_parts.append(f"src-ip {cfg.remote_addr_v[ipver]}")
+ elif field == NtupleField.DST_IP:
+ flow_parts.append(f"dst-ip {cfg.addr_v[ipver]}")
+ elif field == NtupleField.SRC_PORT:
+ flow_parts.append(f"src-port {src_port}")
+ elif field == NtupleField.DST_PORT:
+ flow_parts.append(f"dst-port {dst_port}")
flow_parts.append(f"action {test_queue}")
_ntuple_rule_add(cfg, " ".join(flow_parts))
- _send_traffic(cfg, ipver, proto, dst_port=dst_port)
+ _send_traffic(cfg, ipver, proto, dst_port=dst_port, src_port=src_port)
def _ntuple_variants():
for ipver in ["4", "6"]:
for proto in ["tcp", "udp"]:
- for fields in [[NtupleField.SRC_IP]]:
+ for fields in [[NtupleField.SRC_IP],
+ [NtupleField.DST_IP],
+ [NtupleField.SRC_PORT],
+ [NtupleField.DST_PORT],
+ [NtupleField.SRC_IP, NtupleField.DST_IP],
+ [NtupleField.SRC_IP, NtupleField.DST_IP,
+ NtupleField.SRC_PORT, NtupleField.DST_PORT]]:
name = ".".join(f.name.lower() for f in fields)
yield KsftNamedVariant(f"{proto}{ipver}.{name}",
ipver, proto, fields)
--
2.52.0
^ permalink raw reply related
* [PATCH net-next 1/2] selftests: drv-net: Add ntuple (NFC) flow steering test
From: Dimitri Daskalakis @ 2026-04-07 16:49 UTC (permalink / raw)
To: David S . Miller
Cc: Andrew Lunn, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Shuah Khan, Willem de Bruijn, Petr Machata, David Wei,
Chris J Arges, Carolina Jubran, Dimitri Daskalakis, netdev,
linux-kselftest
In-Reply-To: <20260407164954.2977820-1-dimitri.daskalakis1@gmail.com>
From: Dimitri Daskalakis <daskald@meta.com>
Add a test for ethtool NFC (ntuple) flow steering rules. The test
creates an ntuple rule matching on various flow fields and verifies
that traffic is steered to the correct queue.
The test forces all traffic to queue 0 via the indirection table,
then installs an ntuple rule to steer select traffic to a specific
queue. The test then verifies the expected number of packets is received
on the queue.
This test has variants for TCP/UDP over IPv4/IPv6, with rules matching
the source IP. Additional match fields will be added in the next commit.
TAP version 13
1..4
ok 1 ntuple.queue.tcp4.src_ip
ok 2 ntuple.queue.udp4.src_ip
ok 3 ntuple.queue.tcp6.src_ip
ok 4 ntuple.queue.udp6.src_ip
# Totals: pass:4 fail:0 xfail:0 xpass:0 skip:0 error:0
Signed-off-by: Dimitri Daskalakis <daskald@meta.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
.../testing/selftests/drivers/net/hw/Makefile | 1 +
.../selftests/drivers/net/hw/ntuple.py | 145 ++++++++++++++++++
2 files changed, 146 insertions(+)
create mode 100755 tools/testing/selftests/drivers/net/hw/ntuple.py
diff --git a/tools/testing/selftests/drivers/net/hw/Makefile b/tools/testing/selftests/drivers/net/hw/Makefile
index deeca3f8d080..1f4ebe70c34c 100644
--- a/tools/testing/selftests/drivers/net/hw/Makefile
+++ b/tools/testing/selftests/drivers/net/hw/Makefile
@@ -35,6 +35,7 @@ TEST_PROGS = \
loopback.sh \
nic_timestamp.py \
nk_netns.py \
+ ntuple.py \
pp_alloc_fail.py \
rss_api.py \
rss_ctx.py \
diff --git a/tools/testing/selftests/drivers/net/hw/ntuple.py b/tools/testing/selftests/drivers/net/hw/ntuple.py
new file mode 100755
index 000000000000..c50b76198fba
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/hw/ntuple.py
@@ -0,0 +1,145 @@
+#!/usr/bin/env python3
+# SPDX-License-Identifier: GPL-2.0
+"""Test ethtool NFC (ntuple) flow steering rules."""
+
+import random
+from enum import Enum, auto
+from lib.py import ksft_run, ksft_exit
+from lib.py import ksft_eq, ksft_ge
+from lib.py import ksft_variants, KsftNamedVariant
+from lib.py import EthtoolFamily, NetDrvEpEnv, NetdevFamily
+from lib.py import KsftSkipEx
+from lib.py import cmd, ethtool, defer, rand_port, bkg, wait_port_listen
+
+
+class NtupleField(Enum):
+ SRC_IP = auto()
+
+
+def _require_ntuple(cfg):
+ features = ethtool(f"-k {cfg.ifname}", json=True)[0]
+ if not features["ntuple-filters"]["active"]:
+ raise KsftSkipEx("Ntuple filters not enabled on the device: " + str(features["ntuple-filters"]))
+
+
+def _get_rx_cnts(cfg, prev=None):
+ """Get Rx packet counts for all queues, as a simple list of integers
+ if @prev is specified the prev counts will be subtracted"""
+ cfg.wait_hw_stats_settle()
+ data = cfg.netdevnl.qstats_get({"ifindex": cfg.ifindex, "scope": ["queue"]}, dump=True)
+ data = [x for x in data if x['queue-type'] == "rx"]
+ max_q = max([x["queue-id"] for x in data])
+ queue_stats = [0] * (max_q + 1)
+ for q in data:
+ queue_stats[q["queue-id"]] = q["rx-packets"]
+ if prev and q["queue-id"] < len(prev):
+ queue_stats[q["queue-id"]] -= prev[q["queue-id"]]
+ return queue_stats
+
+
+def _ntuple_rule_add(cfg, flow_spec):
+ """Install an NFC rule via ethtool."""
+
+ output = ethtool(f"-N {cfg.ifname} {flow_spec}").stdout
+ rule_id = int(output.split()[-1])
+ defer(ethtool, f"-N {cfg.ifname} delete {rule_id}")
+
+
+def _setup_isolated_queue(cfg):
+ """Default all traffic to queue 0, and pick a random queue to
+ steer NFC traffic to."""
+
+ channels = cfg.ethnl.channels_get({'header': {'dev-index': cfg.ifindex}})
+ ch_max = channels['combined-max']
+ qcnt = channels['combined-count']
+
+ if ch_max < 2:
+ raise KsftSkipEx(f"Need at least 2 combined channels, max is {ch_max}")
+
+ desired_queues = min(ch_max, 4)
+ if qcnt >= desired_queues:
+ desired_queues = qcnt
+ else:
+ ethtool(f"-L {cfg.ifname} combined {desired_queues}")
+ defer(ethtool, f"-L {cfg.ifname} combined {qcnt}")
+
+ ethtool(f"-X {cfg.ifname} equal 1")
+ defer(ethtool, f"-X {cfg.ifname} default")
+
+ return random.randint(1, desired_queues - 1)
+
+
+def _send_traffic(cfg, ipver, proto, dst_port, pkt_cnt=40):
+ """Generate traffic with the desired flow signature."""
+
+ cfg.require_cmd("socat", remote=True)
+
+ socat_proto = proto.upper()
+ dst_addr = f"[{cfg.addr_v['6']}]" if ipver == '6' else cfg.addr_v['4']
+
+ extra_opts = ",nodelay" if proto == "tcp" else ",shut-null"
+
+ listen_cmd = (f"socat -{ipver} -t 2 -u "
+ f"{socat_proto}-LISTEN:{dst_port},reuseport /dev/null")
+ with bkg(listen_cmd, exit_wait=True):
+ wait_port_listen(dst_port, proto=proto)
+ send_cmd = f"""
+ bash -c 'for i in $(seq {pkt_cnt}); do echo msg; sleep 0.02; done' |
+ socat -{ipver} -u - \
+ {socat_proto}:{dst_addr}:{dst_port},reuseaddr{extra_opts}
+ """
+ cmd(send_cmd, shell=True, host=cfg.remote)
+
+
+def _add_ntuple_rule_and_send_traffic(cfg, ipver, proto, fields, test_queue):
+ dst_port = rand_port()
+ flow_parts = [f"flow-type {proto}{ipver}"]
+
+ for field in fields:
+ if field == NtupleField.SRC_IP:
+ flow_parts.append(f"src-ip {cfg.remote_addr_v[ipver]}")
+
+ flow_parts.append(f"action {test_queue}")
+ _ntuple_rule_add(cfg, " ".join(flow_parts))
+ _send_traffic(cfg, ipver, proto, dst_port=dst_port)
+
+
+def _ntuple_variants():
+ for ipver in ["4", "6"]:
+ for proto in ["tcp", "udp"]:
+ for fields in [[NtupleField.SRC_IP]]:
+ name = ".".join(f.name.lower() for f in fields)
+ yield KsftNamedVariant(f"{proto}{ipver}.{name}",
+ ipver, proto, fields)
+
+
+@ksft_variants(_ntuple_variants())
+def queue(cfg, ipver, proto, fields):
+ """Test that an NFC rule steers traffic to the correct queue."""
+
+ cfg.require_ipver(ipver)
+ _require_ntuple(cfg)
+
+ test_queue = _setup_isolated_queue(cfg)
+
+ cnts = _get_rx_cnts(cfg)
+ _add_ntuple_rule_and_send_traffic(cfg, ipver, proto, fields, test_queue)
+ cnts = _get_rx_cnts(cfg, prev=cnts)
+
+ ksft_ge(cnts[test_queue], 40, f"Traffic on test queue {test_queue}: {cnts}")
+ sum_idle = sum(cnts) - cnts[0] - cnts[test_queue]
+ ksft_eq(sum_idle, 0, f"Traffic on idle queues: {cnts}")
+
+
+def main() -> None:
+ """Ksft boilerplate main."""
+
+ with NetDrvEpEnv(__file__, nsim_test=False) as cfg:
+ cfg.ethnl = EthtoolFamily()
+ cfg.netdevnl = NetdevFamily()
+ ksft_run([queue], args=(cfg,))
+ ksft_exit()
+
+
+if __name__ == "__main__":
+ main()
--
2.52.0
^ permalink raw reply related
* [PATCH net-next 0/2] Add selftests for ntuple (NFC) rules
From: Dimitri Daskalakis @ 2026-04-07 16:49 UTC (permalink / raw)
To: David S . Miller
Cc: Andrew Lunn, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Shuah Khan, Willem de Bruijn, Petr Machata, David Wei,
Chris J Arges, Carolina Jubran, Dimitri Daskalakis, netdev,
linux-kselftest
From: Dimitri Daskalakis <daskald@meta.com>
Thoroughly testing a device's NFC implementation can be tedious. The more
features a device supports, the more combinations to validate.
This series aims to ease that burden, validating the most common NFC rule
combinations.
Dimitri Daskalakis (2):
selftests: drv-net: Add ntuple (NFC) flow steering test
selftests: drv-net: ntuple: Add dst-ip, src-port, dst-port fields
.../testing/selftests/drivers/net/hw/Makefile | 1 +
.../selftests/drivers/net/hw/ntuple.py | 162 ++++++++++++++++++
2 files changed, 163 insertions(+)
create mode 100755 tools/testing/selftests/drivers/net/hw/ntuple.py
--
2.52.0
^ permalink raw reply
* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Jim Mattson @ 2026-04-07 16:46 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm, Asit Mallick,
Tao Zhang, bpf, netdev, linux-doc, chao.gao
In-Reply-To: <20260407163943.y6tkh26z2rfktn3y@desk>
On Tue, Apr 7, 2026 at 9:40 AM Pawan Gupta
<pawan.kumar.gupta@linux.intel.com> wrote:
>
> On Mon, Apr 06, 2026 at 07:23:25AM -0700, Jim Mattson wrote:
> > Yes, but the guest needs a way to determine whether the hypervisor
> > will do what's necessary to make the short sequence effective. And, in
> > particular, no KVM hypervisor today is prepared to do that.
> >
> > When running under a hypervisor, without BHI_CTRL and without any
> > evidence to the contrary, the guest must assume that the longer
> > sequence is necessary. At the very least, we need a CPUID or MSR bit
> > that says, "the short BHB clearing sequence is adequate for this
> > vCPU."
>
> After discussing this internally, the consensus is that the best path
> forward is to add virtual SPEC_CTRL support to KVM, which also aligns with
> Intel's guidance. In the long term, virtual SPEC_CTRL can benefit future
> mitigations as well. As with many other mitigations (e.g. microcode), the
> guest would rely on the host to enforce the appropriate protections.
I don't think it's reasonable for the guest to rely on a future
implementation to enforce the appropriate protections.
This is already a problem today. If a guest sees that BHI_CTRL is
unavailable, it will deploy the short BHB clearing sequence and
declare that the vulnerability is mitigated. That isn't true if the
guest is running on Alder Lake or newer.
^ permalink raw reply
* Re: [PATCH v9 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-04-07 16:39 UTC (permalink / raw)
To: Jim Mattson
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm, Asit Mallick,
Tao Zhang, bpf, netdev, linux-doc, chao.gao
In-Reply-To: <CALMp9eR70eE2U63gzNzTiic0PqJVGv3CBBuVUOVbi3nqbWKZkQ@mail.gmail.com>
On Mon, Apr 06, 2026 at 07:23:25AM -0700, Jim Mattson wrote:
> Yes, but the guest needs a way to determine whether the hypervisor
> will do what's necessary to make the short sequence effective. And, in
> particular, no KVM hypervisor today is prepared to do that.
>
> When running under a hypervisor, without BHI_CTRL and without any
> evidence to the contrary, the guest must assume that the longer
> sequence is necessary. At the very least, we need a CPUID or MSR bit
> that says, "the short BHB clearing sequence is adequate for this
> vCPU."
After discussing this internally, the consensus is that the best path
forward is to add virtual SPEC_CTRL support to KVM, which also aligns with
Intel's guidance. In the long term, virtual SPEC_CTRL can benefit future
mitigations as well. As with many other mitigations (e.g. microcode), the
guest would rely on the host to enforce the appropriate protections.
^ permalink raw reply
* Re: [BUG] net/sched: skb leak with HTB + fq_codel on packet drops
From: Fernando Fernandez Mancera @ 2026-04-07 16:38 UTC (permalink / raw)
To: Damilola Bello, netdev, linux-kernel
In-Reply-To: <CAPgFtOLaedBMU0f_BxV2bXftTJSmJr018Q5uozOo5vVo6b9tjw@mail.gmail.com>
On 4/6/26 4:29 PM, Damilola Bello wrote:
> Description:
>
> Using fq_codel as a child qdisc under HTB results in continuous growth
> of skbuff_head_cache objects when packet drops occur. Memory is not
> freed even after traffic stops, and the system can eventually run out
> of memory.
>
> Regression:
>
> - Works on: 6.18.16
>
> - Fails on: 6.19.x (tested on 6.19.10-200.fc43)
>
> Environment:
>
> - Kernel: 6.19.10-200.fc43
>
> - Distro: Fedora 43
>
> - NICs: ens2f0np0, ens2f1np1
>
> - GRO/GSO/TSO: disabled
>
> Reproduction:
>
> #!/bin/sh
> DEVS="ens2f0np0 ens2f1np1"
> for DEV in $DEVS; do
> tc qdisc del dev $DEV root 2>/dev/null
> tc qdisc add dev $DEV root handle 1: htb default 10
> tc class add dev $DEV parent 1: classid 1:10 htb rate 100mbit
> tc qdisc add dev $DEV parent 1:10 handle 10: fq_codel
> tc filter add dev $DEV parent 1: matchall flowid 1:10
> done
>
> Generate traffic exceeding 100mbit (e.g., iperf3) to force drops.
>
Hi,
I managed to reproduce this and did a bisect. This commit introduces the
issue:
commit a6efc273ab8245722eee2150fa12cf75781dc410
Author: Eric Dumazet <edumazet@google.com>
Date: Fri Nov 21 08:32:56 2025 +0000
net_sched: use qdisc_dequeue_drop() in cake, codel, fq_codel
cake, codel and fq_codel can drop many packets from dequeue().
Use qdisc_dequeue_drop() so that the freeing can happen
outside of the qdisc spinlock scope.
Add TCQ_F_DEQUEUE_DROPS to sch->flags.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link:
https://patch.msgid.link/20251121083256.674562-15-edumazet@google.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
I tested this solution a bit and seems to be fine. We could probably
just drop directly if the qdisc isn't the root.. but I believe this is
cleaner and more future-proof.
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index c3d657359a3d..61ba54e909f2 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -1170,12 +1170,18 @@ static inline void tcf_kfree_skb_list(struct
sk_buff *skb)
static inline void qdisc_dequeue_drop(struct Qdisc *q, struct sk_buff
*skb,
enum skb_drop_reason reason)
{
+ struct Qdisc *root = qdisc_root_sleeping(q);
+
DEBUG_NET_WARN_ON_ONCE(!(q->flags & TCQ_F_DEQUEUE_DROPS));
DEBUG_NET_WARN_ON_ONCE(q->flags & TCQ_F_NOLOCK);
- tcf_set_drop_reason(skb, reason);
- skb->next = q->to_free;
- q->to_free = skb;
+ if (root->flags & TCQ_F_DEQUEUE_DROPS) {
+ tcf_set_drop_reason(skb, reason);
+ skb->next = q->to_free;
+ q->to_free = skb;
+ } else {
+ kfree_skb_reason(skb, reason);
+ }
}
/* Instead of calling kfree_skb() while root qdisc lock is held,
Of course, in this situation if the root qdisc does not support
TCQ_F_DEQUEUE_DROPS flag then, the child won't use the optimization. If
I am not wrong all the qdiscs that can be parent currently do not
support TCQ_F_DEQUEUE_DROPS. Anyway, this generic fix is in my opinion
cleaner than handling every caller.
I am sending this as patch for net tree.
Thanks,
Fernando.
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox