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
| ||
|
Date: Tue, 25 Aug 2020 09:25:38 +0200 From: Michal Hocko <mhocko@...e.com> To: Alex Shi <alex.shi@...ux.alibaba.com> Cc: Qian Cai <cai@....pw>, akpm@...ux-foundation.org, Johannes Weiner <hannes@...xchg.org>, Vladimir Davydov <vdavydov.dev@...il.com>, cgroups@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org, nao.horiguchi@...il.com, osalvador@...e.de, mike.kravetz@...cle.com Subject: Re: [Resend PATCH 1/6] mm/memcg: warning on !memcg after readahead page charged On Tue 25-08-20 09:25:01, Alex Shi wrote: > reproduce using our linux-mm random bug collection on NUMA systems. > >> > >> OK, I must have missed that this was on ppc. The order makes more sense > >> now. I will have a look at this next week. > > > > OK, so I've had a look and I know what's going on there. The > > move_pages12 is migrating hugetlb pages. Those are not charged to any > > memcg. We have completely missed this case. There are two ways going > > around that. Drop the warning and update the comment so that we do not > > forget about that or special case hugetlb pages. > > > > I think the first option is better. > > > > > Hi Michal, > > Compare to ignore the warning which is designed to give, seems addressing > the hugetlb out of charge issue is a better solution, otherwise the memcg > memory usage is out of control on hugetlb, is that right? Hugetlb memory is out of memcg scope deliberately. This is not a reclaimable memory and something that can easily get out of control. The memory is preallocated and overcommit is strictly controlled as well. We have a dedicated hugetlb cgroup controller to offer a better control of the preallocated pool distribution. Anyway this just shows that there are more subtle cases where a page with no memcg can hit some common paths so the patch is clearly not ready. I should have realized that when giving my ack but same as you I got misled by the existing comment. -- Michal Hocko SUSE Labs
Powered by blists - more mailing lists