linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Lameter <cl@gentwo.de>
To: "Gong, Sishuai" <sishuai@purdue.edu>
Cc: "penberg@kernel.org" <penberg@kernel.org>,
	 "rientjes@google.com" <rientjes@google.com>,
	 "iamjoonsoo.kim@lge.com" <iamjoonsoo.kim@lge.com>,
	 "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	 "vbabka@suse.cz" <vbabka@suse.cz>,
	 "linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: A racy reading spot on n->free_objects in slab.c
Date: Wed, 14 Apr 2021 09:32:52 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2104140930030.592014@gentwo.de> (raw)
In-Reply-To: <BD83F9C4-BC29-4206-A140-B066AEAC1B40@purdue.edu>

On Tue, 13 Apr 2021, Gong, Sishuai wrote:

> We found a racy reading spot on shared variable n->free_objects in
> slab.c and it can be data-racing with several writers that update this
> variable. As shown below, in function cache_alloc_refill(),
> n->free_objects will be read without any protection. It could be
> possible that the read value immediately becomes out-of-date when
> another writer is changing it (e.g. free_block())

Ok that is fine. If we mistakenly fill up the per cpu cache with new
objects to the slab then so be it.

If we mistakenly take the lock and fail to get an object then we can still
reverse that decision and do the other thing.

Maybe we need to add a comment there?



  reply	other threads:[~2021-04-14  7:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-13 22:06 Gong, Sishuai
2021-04-14  7:32 ` Christoph Lameter [this message]
2021-04-14 11:06   ` Vlastimil Babka
2021-04-14 15:09     ` Gong, Sishuai

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=alpine.DEB.2.22.394.2104140930030.592014@gentwo.de \
    --to=cl@gentwo.de \
    --cc=akpm@linux-foundation.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=sishuai@purdue.edu \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox