Re: [PATCH net v2 2/2] selftests: net: packetdrill: add test for negative sk_forward_alloc in tcp_wmem_schedule()

[Octavian Purdila]

On Tue, Oct 20, 2026 at 6:20 PM Jakub Kicinski <kuba@xxxxxxxxxx> wrote:
>
> On Tue, 20 Oct 2026 16:38:35 +0000 Octavian Purdila wrote:
> > Add a packetdrill test that drives sk->sk_forward_alloc negative via
> > tcp_collapse() on the receive queue while sk->sk_wmem_queued exceeds
> > sysctl_tcp_wmem[0], and verifies that a subsequent non-blocking write()
> > under TCP memory pressure fails with EAGAIN rather than returning a
> > negative copy length from tcp_wmem_schedule() and failing with EFAULT.
>
> This is failing in our CI, it doesn't need any packetdrill updates,
> right?
>

Hi Jakub,

Correct, no packetdrill updates are needed.

>
> Here's the AI report about the failure:
>
> The new packetdrill test tcp_wmem_schedule_negative_fwd_alloc.pkt is
> failing in our CI (both the regular and debug kernel configs, all three
> address-family sub-tests: ipv4, ipv6, ipv4-mapped-ipv6):
>
>   tcp_wmem_schedule_negative_fwd_alloc.pkt:105: runtime error in write call:
>   Expected result -1 but got 3680 with errno 22 (Invalid argument)
>
> Instead of the non-blocking write() failing with EAGAIN as the test
> expects, it succeeds and returns 3680 bytes. The kernel log for the run
> also shows the test's memory cgroup repeatedly entering the OOM-killer
> path (try_charge_memcg() -> mem_cgroup_out_of_memory(), "Out of memory
> and no killable processes...") from inside tcp_wmem_schedule(), rather
> than the write() being throttled and returning -EAGAIN as intended.
>
> This suggests the test's reproduction recipe (tcp_collapse() driving
> sk_forward_alloc negative while sk_wmem_queued exceeds
> sysctl_tcp_wmem[0]) isn't landing the socket in the TCP memory-pressure
> path in our test environment, but instead in the memcg hard-limit/OOM
> path, which the companion fix (clamping tcp_wmem_schedule()'s return
> value) does not need to handle the same way.
>

Thanks for the report!

> Could you take a look at why the test's preconditions (buffer sizes,
> cgroup memory limit, write() size) aren't reliably reproducing the
> negative-forward-alloc + EAGAIN scenario in our VM environment? It's
> possible the memory cgroup limit used by the test is too tight relative
> to the data pushed through write(), causing it to hit the generic memcg
> OOM path before/instead of the TCP memory-pressure check.

Ah, looks like my local .config was the issue
(CONFIG_MAX_SKB_FRAGS=45). With the netdev CI .config I got the same
error and OOM as you are seeing. I'll fix the script in v3 to work
with both 45 and 17 skb frags.