On Thu, Apr 02, 2015 at 09:48:34PM +0200, Peter Zijlstra wrote:
> @@ -158,20 +257,20 @@ static void pv_wait_head(struct qspinloc
> void __pv_queue_spin_unlock(struct qspinlock *lock)
> {
> struct __qspinlock *l = (void *)lock;
> + struct pv_hash_bucket *hb;
>
> if (xchg(&l->locked, 0) != _Q_SLOW_VAL)
> return;
>
> /*
> * At this point the memory pointed at by lock can be freed/reused,
> + * however we can still use the pointer value to search in our hash
> + * table.
> *
> + * Also, if we observe _Q_SLOW_VAL we _must_ now observe 'our' hash
> + * bucket. See pv_wait_head().
> */
> + hb = pv_hash_find(lock);
> + pv_kick(hb->cpu);
> + WRITE_ONCE(hb->lock, NULL); /* unhash */
> }
So I _think_ I found a problem with this approach :/
If, as per the above, the lock does indeed get freed, it can get
re-allocated and stuck in the hash table (again) before we get the
lookup and unhash it.
I'll have to ponder that a bit more.
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
