linux-kernel - Re: [PATCH] kernel: trace_syscalls: Replace rcu_assign_pointer() with RCU_INIT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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/