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? 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. 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.
