Thread (35 messages) 35 messages, 4 authors, 2017-10-25

Re: [PATCH 17/19] locking/barriers: Kill lockless_dereference

From: Will Deacon <hidden>
Date: 2017-10-24 09:44:39
Also in: lkml

On Tue, Oct 24, 2017 at 11:31:04AM +0200, Ingo Molnar wrote:
* Paul E. McKenney [off-list ref] wrote:
quoted
From: Will Deacon <redacted>

lockless_dereference is a nice idea, but its gained little traction in
kernel code since it's introduction three years ago. This is partly
s/its/it
s/it's/its
Crikey, no idea what happened there!
quoted
because it's a pain to type, but also because using READ_ONCE instead
will work correctly on all architectures apart from Alpha, which is a
fully supported but somewhat niche architecture these days.

This patch moves smp_read_barrier_depends() (a NOP on all architectures
other than Alpha) from lockless_dereference into READ_ONCE, converts
the few actual users over to READ_ONCE and then finally removes
lockless_dereference altogether.
Nit: if we refer to smp_read_barrier_depends() with parentheses (which is the nice 
thing to do for function-alike symbols), then we should do the same with 
READ_ONCE() and lockless_dereference() as well.

Also, could we please split this into three patches:

 #1: Add smp_read_barrier_depends() to READ_ONCE()
 #2: Convert all lockless_dereference() users to READ_ONCE()
 #3: Remove the now unused lockless_dereference() API

to make it easier to analyze if bisected to, should any problems arise?
Sure, I'll do that now.

Will
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help