linux-kernel - Re: [PATCH v2] mm: slab: optimize memcg_slab_free

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: <970bbb88-3fc7-d2b9-6bb5-9c315888a889@suse.cz>
Date:   Wed, 25 May 2022 12:09:19 +0200
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Muchun Song <songmuchun@...edance.com>
Cc:     cl@...ux.com, penberg@...nel.org, rientjes@...gle.com,
        iamjoonsoo.kim@....com, akpm@...ux-foundation.org,
        roman.gushchin@...ux.dev, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, smuchun@...il.com
Subject: Re: [PATCH v2] mm: slab: optimize memcg_slab_free_hook()

On 5/25/22 11:15, Muchun Song wrote:
> On Wed, May 25, 2022 at 09:34:58AM +0200, Vlastimil Babka wrote:
>> On 5/25/22 04:18, Muchun Song wrote:
>> > On Tue, May 24, 2022 at 07:05:31PM +0200, Vlastimil Babka wrote:
>> >> On 4/29/22 14:30, Muchun Song wrote:
>> >> > Most callers of memcg_slab_free_hook() already know the slab,  which could
>> >> > be passed to memcg_slab_free_hook() directly to reduce the overhead of an
>> >> > another call of virt_to_slab().  For bulk freeing of objects, the call of
>> >> > slab_objcgs() in the loop in memcg_slab_free_hook() is redundant as well.
>> >> > Rework memcg_slab_free_hook() and build_detached_freelist() to reduce
>> >> > those unnecessary overhead and make memcg_slab_free_hook() can handle bulk
>> >> > freeing in slab_free().
>> >> > 
>> >> > Move the calling site of memcg_slab_free_hook() from do_slab_free() to
>> >> > slab_free() for slub to make the code clearer since the logic is weird
>> >> > (e.g. the caller need to judge whether it needs to call
>> >> > memcg_slab_free_hook()). It is easy to make mistakes like missing calling
>> >> > of memcg_slab_free_hook() like fixes of:
>> >> > 
>> >> >   commit d1b2cf6cb84a ("mm: memcg/slab: uncharge during kmem_cache_free_bulk()")
>> >> >   commit ae085d7f9365 ("mm: kfence: fix missing objcg housekeeping for SLAB")
>> >> 
>> >> Hm is this commit also fixing such bug? in mm/slab.c __cache_free():
>> >>
> 
> Sorry, I think I have misread it and misled you here.  I mean commit

My bad, I should have said "this patch" referring to yours, not "this
commit" which could refer to ae085d7f9365.

> ae085d7f9365 ("mm: kfence: fix missing objcg housekeeping for SLAB")
> is a bug fix, this commit does not fix any issue since __cache_free()
> will be called from qlink_free() and __cache_free() will call
> memcg_slab_free_hook(), so there is no issues.  This commit is totally
> an improvements for memcg_slab_free_hook().

Ah, I see, indeed. The un-quarantining in kasan went through
memcg_slab_free_hook() before your patch. But yeah it's better to do it
earlier as the freed object's user is who charged it to the memcg, and is no
longer using it - no reason to keep it accounted while in kasan's quarantine.