On Tue 11-10-22 10:30:15, Waiman Long wrote:
> Since commit bc50bcc6e00b ("mm: memcontrol: clean up and document
> effective low/min calculations"), the effective low/min protections can
> be non-zero even if the corresponding memory.low/min values are 0. That
> can surprise users to see MEMCG_LOW events even when the memory.low
> value is not set. One example is the LTP's memcontrol04 test which fails
> because it detects some MEMCG_LOW events for a cgroup with a memory.min
> value of 0.
Is this with memory_recursiveprot mount option?
> Fix this by updating effective_protection() to not returning a non-zero
> low/min protection values if the corresponding memory.low/min values
> or those of its parent are 0.
>
> Fixes: bc50bcc6e00b ("mm: memcontrol: clean up and document effective low/min calculations")
> Signed-off-by: Waiman Long <longman@xxxxxxxxxx>
> ---
> mm/memcontrol.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index b69979c9ced5..893d4d5e518a 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -6660,6 +6660,9 @@ static unsigned long effective_protection(unsigned long usage,
> unsigned long protected;
> unsigned long ep;
>
> + if (!setting || !parent_effective)
> + return 0UL; /* No protection is needed */
> +
This will break the above memory_recursiveprot AFAICS.
> protected = min(usage, setting);
> /*
> * If all cgroups at this level combined claim and use more
> --
> 2.31.1
--
Michal Hocko
SUSE Labs
