[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <85259217-3805-92d8-3be1-8279d8a6a85b@huawei.com>
Date: Thu, 20 Aug 2020 09:56:23 +0800
From: Abel Wu <wuyun.wu@...wei.com>
To: Andrew Morton <akpm@...ux-foundation.org>
CC: Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
"David Rientjes" <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>, <liu.xiang6@....com.cn>,
"open list:SLAB ALLOCATOR" <linux-mm@...ck.org>,
open list <linux-kernel@...r.kernel.org>,
<hewenliang4@...wei.com>, <hushiyuan@...wei.com>
Subject: Re: [PATCH] mm/slub: make add_full() condition more explicit
On 2020/8/20 3:37, Andrew Morton wrote:
> On Tue, 11 Aug 2020 10:02:36 +0800 <wuyun.wu@...wei.com> wrote:
>
>> From: Abel Wu <wuyun.wu@...wei.com>
>>
>> The commit below is incomplete, as it didn't handle the add_full() part.
>> commit a4d3f8916c65 ("slub: remove useless kmem_cache_debug() before remove_full()")
>>
>> This patch checks for SLAB_STORE_USER instead of kmem_cache_debug(),
>> since that should be the only context in which we need the list_lock for
>> add_full().
>>
>
> Does this contradict what the comment tells us?
>
> * This also ensures that the scanning of full
> * slabs from diagnostic functions will not see
> * any frozen slabs.
>
I don't think so. If the flag SLAB_STORE_USER is not set, the slab won't
be added to the full list no matter this patch is applied or not, since
the check inside add_full() will guard for that. Am I missing something
here?
Regards,
Abel
Powered by blists - more mailing lists