All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: rcu@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com,
	rostedt@goodmis.org, "Paul E. McKenney" <paulmck@kernel.org>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Hyeonggon Yoo <42.hyeyoo@gmail.com>,
	linux-mm@kvack.org
Subject: [PATCH rcu 5/8] slab: Explain why SLAB_DESTROY_BY_RCU reference before locking
Date: Wed, 19 Oct 2022 15:46:56 -0700	[thread overview]
Message-ID: <20221019224659.2499511-5-paulmck@kernel.org> (raw)
In-Reply-To: <20221019224652.GA2499358@paulmck-ThinkPad-P17-Gen-1>

It is not obvious to the casual user why it is absolutely necessary to
acquire a reference to a SLAB_DESTROY_BY_RCU structure before acquiring
a lock in that structure.  Therefore, add a comment explaining this point.

Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Roman Gushchin <roman.gushchin@linux.dev>
Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
Cc: <linux-mm@kvack.org>
---
 include/linux/slab.h | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/include/linux/slab.h b/include/linux/slab.h
index 90877fcde70bd..446303e385265 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -76,6 +76,12 @@
  * rcu_read_lock before reading the address, then rcu_read_unlock after
  * taking the spinlock within the structure expected at that address.
  *
+ * Note that it is not possible to acquire a lock within a structure
+ * allocated with SLAB_DESTROY_BY_RCU without first acquiring a reference
+ * as described above.  The reason is that SLAB_DESTROY_BY_RCU pages are
+ * not zeroed before being given to the slab, which means that any locks
+ * must be initialized after each and every kmem_struct_alloc().
+ *
  * Note that SLAB_TYPESAFE_BY_RCU was originally named SLAB_DESTROY_BY_RCU.
  */
 /* Defer freeing slabs to RCU */
-- 
2.31.1.189.g2e36527f23


  parent reply	other threads:[~2022-10-19 22:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19 22:46 [PATCH rcu 0/8] Miscellaneous fixes for v6.2 Paul E. McKenney
2022-10-19 22:46 ` [PATCH rcu 1/8] rcu: Remove duplicate RCU exp QS report from rcu_report_dead() Paul E. McKenney
2022-10-19 22:46 ` [PATCH rcu 2/8] rcu: Synchronize ->qsmaskinitnext in rcu_boost_kthread_setaffinity() Paul E. McKenney
2022-10-19 22:46 ` [PATCH rcu 3/8] rcu: Remove unused 'cpu' in rcu_virt_note_context_switch() Paul E. McKenney
2022-10-19 22:46 ` [PATCH rcu 4/8] rcu: Use READ_ONCE() for lockless read of rnp->qsmask Paul E. McKenney
2022-10-19 22:46 ` Paul E. McKenney [this message]
2022-10-20  7:10   ` [PATCH rcu 5/8] slab: Explain why SLAB_DESTROY_BY_RCU reference before locking Vlastimil Babka
2022-10-20 16:31     ` Paul E. McKenney
2022-10-21  7:44   ` Christoph Lameter
2022-10-21 13:43     ` Paul E. McKenney
2022-10-21 13:50       ` Vlastimil Babka
2022-10-21 15:42         ` Paul E. McKenney
2022-10-21 15:50           ` Vlastimil Babka
2022-10-21 16:10             ` Paul E. McKenney
2022-10-19 22:46 ` [PATCH rcu 6/8] rcu: Remove rcu_is_idle_cpu() Paul E. McKenney
2022-10-19 22:46 ` [PATCH rcu 7/8] rcu-tasks: Make grace-period-age message human-readable Paul E. McKenney
2022-10-19 22:46 ` [PATCH rcu 8/8] rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state() Paul E. McKenney

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=20221019224659.2499511-5-paulmck@kernel.org \
    --to=paulmck@kernel.org \
    --cc=42.hyeyoo@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.org \
    --cc=rcu@vger.kernel.org \
    --cc=rientjes@google.com \
    --cc=roman.gushchin@linux.dev \
    --cc=rostedt@goodmis.org \
    --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.