Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 5f0d5a3a authored by Paul E. McKenney's avatar Paul E. McKenney
Browse files

mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU 



A group of Linux kernel hackers reported chasing a bug that resulted
from their assumption that SLAB_DESTROY_BY_RCU provided an existence
guarantee, that is, that no block from such a slab would be reallocated
during an RCU read-side critical section.  Of course, that is not the
case.  Instead, SLAB_DESTROY_BY_RCU only prevents freeing of an entire
slab of blocks.

However, there is a phrase for this, namely "type safety".  This commit
therefore renames SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU in order
to avoid future instances of this sort of confusion.

Signed-off-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
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: <linux-mm@kvack.org>
Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
Acked-by: default avatarVlastimil Babka <vbabka@suse.cz>
[ paulmck: Add comments mentioning the old name, as requested by Eric
  Dumazet, in order to help people familiar with the old name find
  the new one. ]
Acked-by: default avatarDavid Rientjes <rientjes@google.com>
parent 4495c08e

Documentation/RCU/00-INDEX

+1 −1
Original line number Diff line number Diff line
@@ -17,7 +17,7 @@ rcu_dereference.txt 
rcubarrier.txt

	- RCU and Unloadable Modules

rculist_nulls.txt

	- RCU list primitives for use with SLAB_DESTROY_BY_RCU

	- RCU list primitives for use with SLAB_TYPESAFE_BY_RCU

rcuref.txt

	- Reference-count design for elements of lists/arrays protected by RCU

rcu.txt

Documentation/RCU/rculist_nulls.txt

+3 −3
Original line number Diff line number Diff line 
Using hlist_nulls to protect read-mostly linked lists and

objects using SLAB_DESTROY_BY_RCU allocations.

objects using SLAB_TYPESAFE_BY_RCU allocations.



Please read the basics in Documentation/RCU/listRCU.txt
@@ -7,7 +7,7 @@ Using special makers (called 'nulls') is a convenient way 
to solve following problem :



A typical RCU linked list managing objects which are

allocated with SLAB_DESTROY_BY_RCU kmem_cache can

allocated with SLAB_TYPESAFE_BY_RCU kmem_cache can

use following algos :



1) Lookup algo
@@ -96,7 +96,7 @@ unlock_chain(); // typically a spin_unlock() 
3) Remove algo

--------------

Nothing special here, we can use a standard RCU hlist deletion.

But thanks to SLAB_DESTROY_BY_RCU, beware a deleted object can be reused

But thanks to SLAB_TYPESAFE_BY_RCU, beware a deleted object can be reused

very very fast (before the end of RCU grace period)



if (put_last_reference_on(obj) {

Documentation/RCU/whatisRCU.txt

+2 −1
Original line number Diff line number Diff line
@@ -925,7 +925,8 @@ d. Do you need RCU grace periods to complete even in the face 


e.	Is your workload too update-intensive for normal use of

	RCU, but inappropriate for other synchronization mechanisms?

	If so, consider SLAB_DESTROY_BY_RCU.  But please be careful!

	If so, consider SLAB_TYPESAFE_BY_RCU (which was originally

	named SLAB_DESTROY_BY_RCU).  But please be careful!



f.	Do you need read-side critical sections that are respected

	even though they are in the middle of the idle loop, during

drivers/gpu/drm/i915/i915_gem.c

+1 −1
Original line number Diff line number Diff line
@@ -4552,7 +4552,7 @@ i915_gem_load_init(struct drm_i915_private *dev_priv) 
	dev_priv->requests = KMEM_CACHE(drm_i915_gem_request,

					SLAB_HWCACHE_ALIGN |

					SLAB_RECLAIM_ACCOUNT |

					SLAB_DESTROY_BY_RCU);

					SLAB_TYPESAFE_BY_RCU);

	if (!dev_priv->requests)

		goto err_vmas;

drivers/gpu/drm/i915/i915_gem_request.h

+1 −1
Original line number Diff line number Diff line
@@ -493,7 +493,7 @@ static inline struct drm_i915_gem_request * 
__i915_gem_active_get_rcu(const struct i915_gem_active *active)

{

	/* Performing a lockless retrieval of the active request is super

	 * tricky. SLAB_DESTROY_BY_RCU merely guarantees that the backing

	 * tricky. SLAB_TYPESAFE_BY_RCU merely guarantees that the backing

	 * slab of request objects will not be freed whilst we hold the

	 * RCU read lock. It does not guarantee that the request itself

	 * will not be freed and then *reused*. Viz,