Re: [PATCH net-next] xfrm: fix xfrm_dev_offload_ok() returning true for software SAs

[Sabrina Dubroca <sd@queasysnail.net>]

2026-05-27, 18:47:17 +0200, Petr Wozniak wrote:
> 2026-05-27, Sabrina Dubroca wrote:
> > 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