All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hao Ge <hao.ge@linux.dev>
To: Harry Yoo <harry.yoo@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	Christoph Lameter <cl@gentwo.org>,
	David Rientjes <rientjes@google.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Suren Baghdasaryan <surenb@google.com>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Hao Ge <gehao@kylinos.cn>
Subject: Re: [PATCH v2] slab: Fix obj_ext is mistakenly considered NULL due to race condition
Date: Fri, 24 Oct 2025 17:27:42 +0800	[thread overview]
Message-ID: <49a186cf-c248-45ff-a61c-a6de1a3a98b7@linux.dev> (raw)
In-Reply-To: <aPs-sKOJQs-OelVM@hyeyoo>

Hi Harry


On 2025/10/24 16:54, Harry Yoo wrote:
> On Thu, Oct 23, 2025 at 10:33:13PM +0800, Hao Ge wrote:
>> From: Hao Ge <gehao@kylinos.cn>
>>
>> If two competing threads enter alloc_slab_obj_exts(), if the process
>> that allocates the vector wins cmpxchg(), and the other thread mistakenly
>> assume slab->obj_ext is still empty due to its own allocation failure.
> Massaging this a little bit:
>
>    "If two competing threads enter alloc_slab_obj_exts(), and the one that
>     allocates the vector wins the cmpxchg(), the other thread that failed
>     allocation mistakenly assumes that slab->obj_exts is still empty due to
>     its own allocation failure."
>
>> This
>> will then trigger warnings enforced by CONFIG_MEM_ALLOC_PROFILING_DEBUG
>> checks in the subsequent free path.
>>
>> Therefore, let's add an additional check when the process that allocates
>> the vector loses the cmpxchg()
> You mean "when the process that failed to allocate the vector loses the
> cmpxchg()"?

Yes, I apologize for not being clear enough in my description here.

>> Suggested-by: Harry Yoo <harry.yoo@oracle.com>
>> Signed-off-by: Hao Ge <gehao@kylinos.cn>
>> ---
>> v2: Revise the solution according to Harry's suggestion.
>>      Add Suggested-by: Harry Yoo <harry.yoo@oracle.com>
>> ---
>>
>>   mm/slub.c | 16 +++++++++++-----
>>   1 file changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/slub.c b/mm/slub.c
>> index d4403341c9df..d7bfec6c0171 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -2052,9 +2052,9 @@ static inline void mark_objexts_empty(struct slabobj_ext *obj_exts)
>>   	}
>>   }
>>   
>> -static inline void mark_failed_objexts_alloc(struct slab *slab)
>> +static inline bool mark_failed_objexts_alloc(struct slab *slab)
>>   {
>> -	cmpxchg(&slab->obj_exts, 0, OBJEXTS_ALLOC_FAIL);
>> +	return cmpxchg(&slab->obj_exts, 0, OBJEXTS_ALLOC_FAIL) == 0;
>>   }
>>   
>>   static inline void handle_failed_objexts_alloc(unsigned long obj_exts,
>> @@ -2076,7 +2076,7 @@ static inline void handle_failed_objexts_alloc(unsigned long obj_exts,
>>   #else /* CONFIG_MEM_ALLOC_PROFILING_DEBUG */
>>   
>>   static inline void mark_objexts_empty(struct slabobj_ext *obj_exts) {}
>> -static inline void mark_failed_objexts_alloc(struct slab *slab) {}
>> +static inline bool mark_failed_objexts_alloc(struct slab *slab) { return false; }
>>   static inline void handle_failed_objexts_alloc(unsigned long obj_exts,
>>   			struct slabobj_ext *vec, unsigned int objects) {}
>>   
>> @@ -2124,8 +2124,14 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
>>   				   slab_nid(slab));
>>   	}
>>   	if (!vec) {
>> -		/* Mark vectors which failed to allocate */
>> -		mark_failed_objexts_alloc(slab);
>> +		/*
>> +		 * Try to mark vectors which failed to allocate
> nit:
>                                                                 ^ missing
> 							       period
> 							       (.) here
>
> With the comments resolved,
> Reviewed-by: Harry Yoo <harry.yoo@oracle.com>


A period is indeed missing here.


Hi Vlastimil


Thank you for adding V2 to your tree. Now, should I resubmit V3,

or can you assist with making these modifications in your tree?


>
>> +		 * If this operation fails, there may be a racing process
>> +		 * that has already completed the allocation.
>> +		 */
>> +		if (!mark_failed_objexts_alloc(slab) &&
>> +		    slab_obj_exts(slab))
>> +			return 0;
>>   
>>   		return -ENOMEM;
>>   	}
>> -- 
>> 2.25.1


  reply	other threads:[~2025-10-24  9:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-23 14:33 [PATCH v2] slab: Fix obj_ext is mistakenly considered NULL due to race condition Hao Ge
2025-10-23 16:33 ` Suren Baghdasaryan
2025-10-24  8:54 ` Harry Yoo
2025-10-24  9:27   ` Hao Ge [this message]
2025-10-24  9:39     ` Vlastimil Babka
2025-10-24 10:06       ` Hao Ge
2025-10-24 10:34         ` Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49a186cf-c248-45ff-a61c-a6de1a3a98b7@linux.dev \
    --to=hao.ge@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.org \
    --cc=gehao@kylinos.cn \
    --cc=harry.yoo@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.