lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 17 Jan 2020 19:37:17 +0100
From:   Paolo Abeni <pabeni@...hat.com>
To:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>,
        Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: [PATCH net 3/3] udp: avoid bulk memory scheduling on memory
 pressure.

Hi,

On Fri, 2020-01-17 at 09:51 -0800, Eric Dumazet wrote:
> On 1/17/20 9:27 AM, Paolo Abeni wrote:
> > 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 <willemdebruijn.kernel@...il.com>
> > 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

Powered by blists - more mailing lists