linux-kernel - Re: [PATCH 0/2] Fix memcg/memory.high in case kmem accounting is enabled

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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 31 Aug 2015 15:24:15 +0200
From:	Michal Hocko <mhocko@...nel.org>
To:	Vladimir Davydov <vdavydov@...allels.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Tejun Heo <tj@...nel.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] Fix memcg/memory.high in case kmem accounting is
 enabled

On Sun 30-08-15 22:02:16, Vladimir Davydov wrote:
> Hi,
> 
> Tejun reported that sometimes memcg/memory.high threshold seems to be
> silently ignored if kmem accounting is enabled:
> 
>   http://www.spinics.net/lists/linux-mm/msg93613.html
> 
> It turned out that both SLAB and SLUB try to allocate without __GFP_WAIT
> first. As a result, if there is enough free pages, memcg reclaim will
> not get invoked on kmem allocations, which will lead to uncontrollable
> growth of memory usage no matter what memory.high is set to.

Right but isn't that what the caller explicitly asked for? Why should we
ignore that for kmem accounting? It seems like a fix at a wrong layer to
me. Either we should start failing GFP_NOWAIT charges when we are above
high wmark or deploy an additional catchup mechanism as suggested by
Tejun. I like the later more because it allows to better handle GFP_NOFS
requests as well and there are many sources of these from kmem paths.
 
> This patch set attempts to fix this issue. For more details please see
> comments to individual patches.
> 
> Thanks,
> 
> Vladimir Davydov (2):
>   mm/slab: skip memcg reclaim only if in atomic context
>   mm/slub: do not bypass memcg reclaim for high-order page allocation
> 
>  mm/slab.c | 32 +++++++++++---------------------
>  mm/slub.c | 24 +++++++++++-------------
>  2 files changed, 22 insertions(+), 34 deletions(-)
> 
> -- 
> 2.1.4

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/