linux-kernel - Re: [BUG] mm/cgroupv2: memory.min may lead to an OOM error

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAK1f24mOdm6YK=3ZY4QE2eQq4ggeiNKoq_Nhp1bguE8E5jBwBg@mail.gmail.com>
Date: Fri, 2 Aug 2024 09:56:04 +0800
From: Lance Yang <ioworker0@...il.com>
To: Michal Koutný <mkoutny@...e.com>
Cc: "Vlastimil Babka (SUSE)" <vbabka@...nel.org>, akpm@...ux-foundation.org, 21cnbao@...il.com, 
	ryan.roberts@....com, david@...hat.com, shy828301@...il.com, ziy@...dia.com, 
	libang.li@...group.com, baolin.wang@...ux.alibaba.com, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	Johannes Weiner <hannes@...xchg.org>, Michal Hocko <mhocko@...nel.org>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Shakeel Butt <shakeel.butt@...ux.dev>, 
	Muchun Song <muchun.song@...ux.dev>, Cgroups <cgroups@...r.kernel.org>
Subject: Re: [BUG] mm/cgroupv2: memory.min may lead to an OOM error

Hi Michal,

Thanks a lot for clarifying!

On Fri, Aug 2, 2024 at 6:58 AM Michal Koutný <mkoutny@...e.com> wrote:
>
> Hello.
>
> On Thu, Aug 01, 2024 at 07:40:10PM GMT, Lance Yang <ioworker0@...il.com> wrote:
> > However, if the child cgroup doesn't exist and we add a process to the 'test'
> > cgroup, then attempt to create a large file(2GB) using dd, we won't encounter
> > an OOM error; everything works as expected.
>
> That's due to the way how effective protections are calculated, see [1].
> If reclaim target is cgroup T, then it won't enjoy protection configured
> on itself, whereas the child of T is subject of ancestral reclaim hence
> the protection applies.

Makes sense to me.

>
> That would mean that in your 1st demo, it is test/memory.max that
> triggers reclaim and then failure to reclaim from test/test-child causes
> OOM in test.
> That's interesting since the (same) limit of test-child/memory.max
> should be evaluated first. I guess it is in your example there are
> actually two parallel processes (1321 and 1324) so some charges may
> randomly propagate to the upper test/memory.max limit.
>
> As explained above, the 2nd demo has same reclaim target but due to no
> nesting, protection is moot.

Ah, that clears it up. I appreciate the detailed explanation - thanks!

> I believe you could reproduce with merely
>
>         test/memory.max
>         test-child/memory.min

Yep, I just tested it, and you're right ;)

>
> > Hmm... I'm a bit confused about that.
>
> I agree, the calculation of effective protection wrt reclaim target can
> be confusing.
>
> The effects you see are documented for memory.min:
>
> > Putting more memory than generally available under this
> > protection is discouraged and may lead to constant OOMs.

Thanks a lot again for your time!
Lance

>
> HTH,
> Michal
>
> [1] https://lore.kernel.org/all/20200729140537.13345-2-mkoutny@suse.com/