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  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <bfbfc15f-3d16-f127-0642-d5f78147a58d@bytedance.com>
Date: Mon, 15 May 2023 18:20:21 +0800
From: Abel Wu <wuyun.abel@...edance.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: Paolo Abeni <pabeni@...hat.com>, "David S . Miller"
 <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
 netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] sock: Fix misuse of sk_under_memory_pressure()

On 5/15/23 3:21 PM, Eric Dumazet wrote:>
> I still do not understand the patch.
> 
> If I do not understand the patch and its changelog now in May 2023,
> how will anyone understand it later
> when/if a regression is investigated ?
> 
> I repeat :
> 
> Changelog is evasive, I do not see what practical problem you want to solve.
> 
> 
> sk_has_memory_pressure() is not about memcg, simply the fact that a
> proto has a non NULL memory_pressure pointer.

Yes, it has nothing to do with sk_has_memory_pressure(), this accessor
is removed only due to it is not used anymore after this fix. I really
should have put this into a separate patch.

> 
> I suggest that you answer these questions, and send a V2 with an
> updated changelog.

OK, I will.

> 
> Again, what is the practical problem you want to solve ?
> What is the behavior of the current stack that you think is a problem ?

The status of global tcp_mem pressure is updated when:

   a) __sk_mem_raise_allocated():

	enter: sk_memory_allocated(sk) >  tcp_mem[1]
	leave: sk_memory_allocated(sk) <= tcp_mem[0]

   b) __sk_mem_reduce_allocated():

	leave: sk_under_memory_pressure(sk) &&
		sk_memory_allocated(sk) < tcp_mem[0]

So the conditions of leaving global pressure are inconstant, which may
lead to the situation that one pressured memcg prevents the global
pressure from being cleared when there is indeed no global pressure,
thus the global constrains are still in effect unexpectedly on the other
sockets. The patch fixes this by removing the condition of net-memcg's
pressure in __sk_mem_reduce_allocated().

As for the changes in __sk_mem_raise_allocated(), I don't think it is
the right place to check the pressure of the @sk's memcg. That piece of
code was originally only trying to be fair between all the sockets if
there is global pressure. And if we really want to forbid the socket
memory from being raised when the socket's memcg is in pressure, the
condition should be in the first place inside this function.

So I plan to split this patch into three in v2:

   [1/3] fix inconstant condition in __sk_mem_reduce_allocated()
   [2/3] remove unrelated check in __sk_mem_raise_allocated()
   [3/3] remove sk_has_memory_pressure() since it is no longer used

Does this make sense to you?

Thanks & Best,
	Abel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ