On Mon, 2013-06-24 at 14:49 -0400, Peter Hurley wrote: > On 06/24/2013 01:11 PM, Tim Chen wrote: > > On Sun, 2013-06-23 at 13:03 -0700, Davidlohr Bueso wrote: > >> On Sat, 2013-06-22 at 03:57 -0400, Peter Hurley wrote: > >>> On 06/21/2013 07:51 PM, Tim Chen wrote: > >>>> > >>>> +static inline bool rwsem_can_spin_on_owner(struct rw_semaphore *sem) > >>>> +{ > >>>> + int retval = true; > >>>> + > >>>> + /* Spin only if active writer running */ > >>>> + if (!sem->owner) > >>>> + return false; > >>>> + > >>>> + rcu_read_lock(); > >>>> + if (sem->owner) > >>>> + retval = sem->owner->on_cpu; > >>> ^^^^^^^^^^^^^^^^^^ > >>> > >>> Why is this a safe dereference? Could not another cpu have just > >>> dropped the sem (and thus set sem->owner to NULL and oops)? > >>> > > > > The rcu read lock should protect against sem->owner being NULL. > > It doesn't. > > Here's the comment from mutex_spin_on_owner(): > > /* > * Look out! "owner" is an entirely speculative pointer > * access and not reliable. > */ >
In mutex_spin_on_owner, after rcu_read_lock, the owner_running() function de-references the owner pointer. The rcu_read_lock prevents owner from getting freed. The comment's intention is to warn that owner->on_cpu may not be reliable. I'm using similar logic in rw-sem. Tim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/