[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170413161709.ej3qxuqitykhqtyf@hirez.programming.kicks-ass.net>
Date: Thu, 13 Apr 2017 18:17:09 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org, mingo@...nel.org,
jiangshanlai@...il.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
dhowells@...hat.com, edumazet@...gle.com, fweisbec@...il.com,
oleg@...hat.com, bobby.prani@...il.com,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>, linux-mm@...ck.org
Subject: Re: [PATCH tip/core/rcu 01/13] mm: Rename SLAB_DESTROY_BY_RCU to
SLAB_TYPESAFE_BY_RCU
On Thu, Apr 13, 2017 at 01:06:56PM +0200, Vlastimil Babka wrote:
> On 04/13/2017 11:12 AM, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2017 at 09:55:37AM -0700, Paul E. McKenney wrote:
> >> 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.
> >
> > And that while we wrote a huge honking comment right along with it...
> >
> >> [ paulmck: Add "tombstone" comments as requested by Eric Dumazet. ]
> >
> > I cannot find any occurrence of "tomb" or "TOMB" in the actual patch,
> > confused?
>
> It's the comments such as:
>
> + * Note that SLAB_TYPESAFE_BY_RCU was originally named SLAB_DESTROY_BY_RCU.
>
> so that people who remember the old name can git grep its fate.
git log -S SLAB_DESTROY_BY_RCU
Powered by blists - more mailing lists