Hi,

On Fri, 2020-01-17 at 09:51 -0800, Eric Dumazet wrote:

On 1/17/20 9:27 AM, Paolo Abeni wrote:

quoted

Williem reported that after commit 0d4a6608f68c ("udp: do rmem bulk
free even if the rx sk queue is empty") the memory allocated by
an almost idle system with many UDP sockets can grow a lot.

This change addresses the issue enabling memory pressure tracking
for UDP and flushing the fwd allocated memory on dequeue if the
UDP protocol is under memory pressure.

Note that with this patch applied, the system allocates more
liberally memory for UDP sockets while the total memory usage is
below udp_mem[1], while the vanilla kernel would allow at most a
single page per socket when UDP memory usage goes above udp_mem[0]
- see __sk_mem_raise_allocated().

Reported-and-diagnosed-by: Willem de Bruijn [off-list ref]
Fixes: commit 0d4a6608f68c ("udp: do rmem bulk free even if the rx sk queue is empty")

Thank you for the feedback.

Not a proper Fixes: tag

Frankly I would rather revert this patch, unless you show how much things were improved.

unpatched version:

# ensure we will hit memory pressure
echo "5000 10000 20000" > /proc/sys/net/ipv4/udp_mem

# run the repro from Willem
./repro.py

# it get stuck after opening a bunch of sockets, because
# __udp_enqueue_schedule_skb() hits the memory limit
# and packets are dropped.

patched kernel:
echo "5000 10000 20000" > /proc/sys/net/ipv4/udp_mem
./repro.py
# completes successfully, output trimmed
sockets: used 10179
TCP: inuse 4 orphan 0 tw 0 alloc 7 mem 1
UDP: inuse 4 mem 19860
UDPLITE: inuse 0
RAW: inuse 0
FRAG: inuse 0 memory 0

To complete successfully with an unpatched kernel the reproducer
requires memory limits 1 or 2 order of magnitude greaters.

Where in the UDP code the forward allocations will be released while udp_memory_pressure
is hit ?

fwd memory is released by udp_rmem_release(), so every time some
process tries to read from any UDP socket. Surely less effective than
the TCP infrastructure, but that other option looks overkill for UDP?!?

Thanks,

Paolo