On Tue, Oct 20, 2026 at 6:20 PM Jakub Kicinski <[email protected]> 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.
