linux-kernel - Re: [PATCH v1] memcg: add charging of already allocated slab objects

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

Message-ID: <a5rzw7uuf7pgrhhut7keoy66c6u4rgiuxx2qmwywbvl2iktfku@23dzxczejcet>
Date: Wed, 28 Aug 2024 12:03:47 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Muchun Song <muchun.song@...ux.dev>
Cc: Roman Gushchin <roman.gushchin@...ux.dev>, 
	Andrew Morton <akpm@...ux-foundation.org>, Johannes Weiner <hannes@...xchg.org>, 
	Michal Hocko <mhocko@...nel.org>, Vlastimil Babka <vbabka@...e.cz>, 
	David Rientjes <rientjes@...gle.com>, Hyeonggon Yoo <42.hyeyoo@...il.com>, 
	Eric Dumazet <edumazet@...gle.com>, "David S . Miller" <davem@...emloft.net>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Linux Memory Management List <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>, 
	Meta kernel team <kernel-team@...a.com>, cgroups@...r.kernel.org, netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v1] memcg: add charging of already allocated slab objects

Hi Muchun,

On Wed, Aug 28, 2024 at 10:36:06AM GMT, Muchun Song wrote:
> 
> 
> > On Aug 28, 2024, at 01:23, Shakeel Butt <shakeel.butt@...ux.dev> wrote:
> > 
[...]
> >> 
> >> Does it handle the case of a too-big-to-be-a-slab-object allocation?
> >> I think it's better to handle it properly. Also, why return false here?
> >> 
> > 
> > Yes I will fix the too-big-to-be-a-slab-object allocations. I presume I
> > should just follow the kfree() hanlding on !folio_test_slab() i.e. that
> > the given object is the large or too-big-to-be-a-slab-object.
> 
> Hi Shakeel,
> 
> If we decide to do this, I suppose you will use memcg_kmem_charge_page
> to charge big-object. To be consistent, I suggest renaming kmem_cache_charge
> to memcg_kmem_charge to handle both slab object and big-object. And I saw
> all the functions related to object charging is moved to memcontrol.c (e.g.
> __memcg_slab_post_alloc_hook), so maybe we should also do this for
> memcg_kmem_charge?
> 

If I understand you correctly, you are suggesting to handle the general
kmem charging and slab's large kmalloc (size > KMALLOC_MAX_CACHE_SIZE)
together with memcg_kmem_charge(). However that is not possible due to
slab path updating NR_SLAB_UNRECLAIMABLE_B stats while no updates for
this stat in the general kmem charging path (__memcg_kmem_charge_page in
page allocation code path).

Also this general kmem charging path is used by many other users like
vmalloc, kernel stack and thus we can not just plainly stuck updates to
NR_SLAB_UNRECLAIMABLE_B in that path.

Thanks for taking a look.
Shakeel