[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140826005722.GJ2663@linux.vnet.ibm.com>
Date: Mon, 25 Aug 2014 17:57:22 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Andreea-Cristina Bernat <bernat.ada@...il.com>, mingo@...hat.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kernel: trace_syscalls: Replace rcu_assign_pointer()
with RCU_INIT_POINTER()
On Mon, Aug 25, 2014 at 07:05:54PM -0400, Steven Rostedt wrote:
> On Mon, 25 Aug 2014 15:56:54 -0700
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
>
>
> > > I guess I can add this. It's a very slow path thus it isn't critical.
> > >
> > > Although, I hate the name. Perhaps we should add another macro called
> > > RCU_CLEAR_POINTER() or something that just nulls it. That way it
> > > documents the use. To me, INIT means the pointer is being initialized,
> > > where in reality it's just being cleared. I guess one could argue that
> > > the pointer is being "re-initialized".
> >
> > I considered that, but there end up being three separate use cases
> > for this thing:
> >
> > 1. NULLing the pointer, as in this case.
> >
> > 2. Initializing the pointer at a time when no readers have a
> > reference to that pointer. (In this case, there is presumably
> > a later rcu_assign_pointer() that makes the whole thing visible
> > to readers.)
> >
> > 3. Rearranging data that is already visible to readers, the usual
> > example being removing an element -- readers can already see
> > the successor in this case.
> >
> > Having three different APIs for identical macros seemed like overkill
> > to me. Especially given that people already complain about the RCU
> > API being too big. :-(
> >
>
> Yeah, understood. But I think CLEAR is better than INIT as it says
> what it's doing more than what it is for. In all three above, we want
> to clear the pointer, but in only one case we want to initialize it.
>
> But this is bikeshedding, and not worth the time of this dicussion.
PLAID!!! We must paint the bikeshed plaid!
> No need to look further. Nothings going on here. Move along people or
> I'll have to get my pepper spray out.
;-) ;-) ;-)
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists