2026-05-27, 18:47:17 +0200, Petr Wozniak wrote:

2026-05-27, Sabrina Dubroca wrote:

quoted

Incorrectly? IPsec in SW with GSO is a valid setup. I think you're
breaking that with your patch.

Fair point — SW IPsec with GSO is intentional and the patch is too broad.

(this whole email looks like direct c/p from an LLM...)

The actual observable bug on this platform (MT7988A, EIP-197 async crypto):

  xfrm_dev_offload_ok() → true (SW SA, dev == NULL)
  → esp4_gso_encap() marks the skb
  → validate_xmit_xfrm() → esp_xmit() → async crypto → -EINPROGRESS
  → validate_xmit_xfrm() returns NULL

On bridge interfaces (noqueue qdisc), __dev_queue_xmit() takes the
direct branch, initialises rc = -ENOMEM and never overwrites it
when skb is NULL → ENOMEM on every packet.

On real netdevs with a qdisc, sch_direct_xmit() handles NULL
gracefully and async completion via xfrm_dev_resume() delivers
the packet correctly.

But the packet is delivered correctly also in the bridge case, right?
Once we enter async crypto, the original datapath becomes irrelevant.

Where would you suggest the actual fix should go — in the
bridge/noqueue path, or in validate_xmit_xfrm() / sch_direct_xmit()?

It looks like commit f53c723902d1 ("net: Add asynchronous callbacks
for xfrm on layer 2.") updated the meaning of validate_xmit_xfrm()
returning NULL from "packet was dropped" to "packet was stolen (maybe
dropped, maybe still going)" and this isn't handled well.

I guess validate_xmit_xfrm() could propagate -EINPROGRESS via
ERR_PTR(), and validate_xmit_skb() could return that to its callers.
validate_xmit_skb_list() would need to check IS_ERR_OR_NULL(skb)
instead of !skb, and __dev_queue_xmit() could now differentiate the
EINPROGRESS case from a drop.

-- 
Sabrina