Re: [PATCH tip/core/rcu 1/9] rcu: Upgrade rcu_swap_protected() to rcu_replace()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 03, 2019 at 01:21:14PM -0400, Mathieu Desnoyers wrote:
> ----- On Oct 3, 2019, at 12:52 PM, paulmck paulmck@xxxxxxxxxx wrote:
> 
> > On Thu, Oct 03, 2019 at 12:35:30PM -0400, Mathieu Desnoyers wrote:
> >> ----- On Oct 2, 2019, at 9:43 PM, paulmck paulmck@xxxxxxxxxx wrote:
> >> 
> >> > From: "Paul E. McKenney" <paulmck@xxxxxxxxxx>
> >> > 
> >> > Although the rcu_swap_protected() macro follows the example of swap(),
> >> > the interactions with RCU make its update of its argument somewhat
> >> > counter-intuitive.  This commit therefore introduces an rcu_replace()
> >> > that returns the old value of the RCU pointer instead of doing the
> >> > argument update.  Once all the uses of rcu_swap_protected() are updated
> >> > to instead use rcu_replace(), rcu_swap_protected() will be removed.
> >> 
> >> We expose the rcu_xchg_pointer() API in liburcu (Userspace RCU) project.
> >> Any reason for not going that way and keep the kernel and user-space RCU
> >> APIs alike ?
> >> 
> >> It's of course fine if they diverge, but we might want to at least consider
> >> if using the same API name would be OK.
> > 
> > Different semantics.  An rcu_xchg_pointer() allows concurrent updates,
> > and rcu_replace() does not.
> > 
> > But yes, if someone needs the concurrent updates, rcu_xchg_pointer()
> > would certainly be my choice for the name.
> 
> Then considering that its assignment counterpart is "rcu_assign_pointer()"
> (and not "rcu_assign()"), would "rcu_replace_pointer()" be less ambiguous
> about its intended use ?

The sequence was rcu_swap_protected() -> rcu_swap() -> rcu_replace().
Because that rcu_replace(), unlike rcu_swap_protected(), returns a
value, the shorter name is valuable.

Maybe we should have used rcu_assign() instead of rcu_assign_pointer(),
but there is no point in that sort of change at this late date!

							Thanx, Paul

> Thanks,
> 
> Mathieu
> 
> 
> > 
> >							Thanx, Paul
> > 
> >> Thanks,
> >> 
> >> Mathieu
> >> 
> >> 
> >> > 
> >> > Link:
> >> > https://lore.kernel.org/lkml/CAHk-=wiAsJLw1egFEE=Z7-GGtM6wcvtyytXZA1+BHqta4gg6Hw@xxxxxxxxxxxxxx/
> >> > Reported-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> >> > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
> >> > Cc: Bart Van Assche <bart.vanassche@xxxxxxx>
> >> > Cc: Christoph Hellwig <hch@xxxxxx>
> >> > Cc: Hannes Reinecke <hare@xxxxxxx>
> >> > Cc: Johannes Thumshirn <jthumshirn@xxxxxxx>
> >> > Cc: Shane M Seymour <shane.seymour@xxxxxxx>
> >> > Cc: Martin K. Petersen <martin.petersen@xxxxxxxxxx>
> >> > ---
> >> > include/linux/rcupdate.h | 18 ++++++++++++++++++
> >> > 1 file changed, 18 insertions(+)
> >> > 
> >> > diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> >> > index 75a2ede..3b73287 100644
> >> > --- a/include/linux/rcupdate.h
> >> > +++ b/include/linux/rcupdate.h
> >> > @@ -383,6 +383,24 @@ do {									      \
> >> > } while (0)
> >> > 
> >> > /**
> >> > + * rcu_replace() - replace an RCU pointer, returning its old value
> >> > + * @rcu_ptr: RCU pointer, whose old value is returned
> >> > + * @ptr: regular pointer
> >> > + * @c: the lockdep conditions under which the dereference will take place
> >> > + *
> >> > + * Perform a replacement, where @rcu_ptr is an RCU-annotated
> >> > + * pointer and @c is the lockdep argument that is passed to the
> >> > + * rcu_dereference_protected() call used to read that pointer.  The old
> >> > + * value of @rcu_ptr is returned, and @rcu_ptr is set to @ptr.
> >> > + */
> >> > +#define rcu_replace(rcu_ptr, ptr, c)					\
> >> > +({									\
> >> > +	typeof(ptr) __tmp = rcu_dereference_protected((rcu_ptr), (c));	\
> >> > +	rcu_assign_pointer((rcu_ptr), (ptr));				\
> >> > +	__tmp;								\
> >> > +})
> >> > +
> >> > +/**
> >> >  * rcu_swap_protected() - swap an RCU and a regular pointer
> >> >  * @rcu_ptr: RCU pointer
> >> >  * @ptr: regular pointer
> >> > --
> >> > 2.9.5
> >> 
> >> --
> >> Mathieu Desnoyers
> >> EfficiOS Inc.
> > > http://www.efficios.com
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux