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

[Jakub Kicinski <kuba@kernel.org>]

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.