Re: [PATCH 2/2] locking/rwsem: Use a return variable in rwsem_spin_on_owner()

[Linus Torvalds]

On Thu, Apr 9, 2015 at 10:56 AM, Paul E. McKenney
<paulmck@xxxxxxxxxxxxxxxxxx> wrote:
>
> And if such long-term spins are likely, I cannot resist asking if this
> should be instead using SRCU.  If you have your own srcu_struct, you
> get to delay your own SRCU grace periods as long as you want.  ;-)

No, this is plain RCU, and it is only needed because the 'struct
task_struct' is RCU-allocated, and we do an optimistic access of that
'owner->on_cpu' without actually holding any locks.

And even *that* wouldn't be needed if it wasn't for DEBUG_PAGEALLOC.
We could just access stale memory.

I wonder if we should get rid of the whole RCU thing (which does add
overhead to a potentially critical piece of code), and replace it with
a new "optimistic_kernel_read()" function that basically just does a
memory read with an exception table entry (ie like __get_user(), but
without any of the user access overhead - no clac etc), so that if we
fault due to DEBUG_PAGEALLOC it just ignores the fault.

Hmm? I think there might be a few other places that currently get RCU
read locks just because they want to do an optimistic read of
something that migth be going away from under them.

The pointer is a known-safe kernel pointer - it's just that it was
"known safe" a few instructions ago, and might be rcu-free'd at any
time.

                          Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/