linux-kernel - Re: [PATCH 1/2] gfp: add __GFP

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]

Message-ID: <20150506150058.GA4705@cmpxchg.org>
Date:	Wed, 6 May 2015 11:00:58 -0400
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	Vladimir Davydov <vdavydov@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...nel.org>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <iamjoonsoo.kim@....com>,
	Greg Thelen <gthelen@...gle.com>, linux-mm@...ck.org,
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] gfp: add __GFP_NOACCOUNT

On Wed, May 06, 2015 at 03:46:20PM +0200, Michal Hocko wrote:
> On Wed 06-05-15 09:16:22, Johannes Weiner wrote:
> > On Wed, May 06, 2015 at 01:59:41PM +0200, Michal Hocko wrote:
> > > On Tue 05-05-15 12:45:42, Vladimir Davydov wrote:
> > > > Not all kmem allocations should be accounted to memcg. The following
> > > > patch gives an example when accounting of a certain type of allocations
> > > > to memcg can effectively result in a memory leak.
> > > 
> > > > This patch adds the __GFP_NOACCOUNT flag which if passed to kmalloc
> > > > and friends will force the allocation to go through the root
> > > > cgroup. It will be used by the next patch.
> > > 
> > > The name of the flag is way too generic. It is not clear that the
> > > accounting is KMEMCG related.
> > 
> > The memory controller is the (primary) component that accounts
> > physical memory allocations in the kernel, so I don't see how this
> > would be ambiguous in any way.
> 
> What if a high-level allocator wants to do some accounting as well?
> E.g. slab allocator accounts {un}reclaimable pages. It is a different
> thing because the accounting is per-cache rather than gfp based but I
> just wanted to point out that accounting is rather a wide term.

This is a concept we have discussed so many times before.  The more
generic or fundamental the functionality in its context, the more
generic the name.  The longer and more specific the name, the more
niche its functionality in that context.

See schedule().

See open().

Accounting is a broad term, but in the context of a physical memory
request I can not think of a more fundamental meaning of "do not
account" - without further qualification - then inhibiting what memcg
does: accounting the requested memory to the caller.

If some allocator would want to modify the accounting of a certain
*type* of memory, then that would be more specific, and a flag to
accomplish this would be expected to have a longer name.

One is a core feature of the VM, the other is a niche aspect of
another core feature of the VM.
--
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/