[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f13eaa33c4f73bce9bdcf08b072aeaf23b0551d5.camel@redhat.com>
Date: Tue, 08 Sep 2020 10:46:13 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: dust.li@...ux.alibaba.com,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH] net/sock: don't drop udp packets if udp_mem[2] not
reached
Hi,
On Tue, 2020-09-08 at 11:15 +0800, dust.li wrote:
> Actually, with more udp sockets, I can always make it large
> enough to exceed udp_mem[0], and drop packets before udp_mem[1]
> and udp_mem[2].
Sure, but with enough sockets you can also exceeeds any limits ;).
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 6c5c6b18eff4..fed8211d8dbe 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2648,6 +2648,12 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)
> atomic_read(&sk->sk_rmem_alloc) +
> sk->sk_forward_alloc))
> return 1;
> + } else {
> + /* for prots without memory_pressure callbacks, we should not
> + * drop until hard limit reached
> + */
> + if (allocated <= sk_prot_mem_limits(sk, 2))
> + return 1;
At this point, the above condition is always true, due to an earlier
check. Additionally, accepting any value below udp_mem[2] would make
the previous checks to allow a minimum per socket memory useless.
You can obtain the same result setting udp_mem[0] = udp_mem[2], without
any kernel change.
But with this change applied you can't guarantee anymore a minimum per
socket amount of memory.
I think you are possibly mislead by your own comment: the point is that
we should never allow allocation above the hard limit, but the protocol
is allowed to drop as soon as the memory allocated raises above the
lower limit.
Note that the current behavior is correctly documented
in Documentation/networking/ip-sysctl.rst.
Your problem must be solved in another way e.g. raising udp_mem[0] -
and keeping udp_mem[2] above that value.
Cheers,
Paolo
Powered by blists - more mailing lists