On Thu, Apr 13, 2017 at 10:39:51AM -0700, Paul E. McKenney wrote:
> Well, if there are no objections, I will fix up the smp_mb__before_atomic()
> and smp_mb__after_atomic() pieces.
Feel free.
> I suppose that one alternative is the new variant of kerneldoc, though
> very few of these functions have comment headers, let alone kerneldoc
> headers. Which reminds me, the question of spin_unlock_wait() and
> spin_is_locked() semantics came up a bit ago. Here is what I believe
> to be the case. Does this match others' expectations?
>
> o spin_unlock_wait() semantics:
>
> 1. Any access in any critical section prior to the
> spin_unlock_wait() is visible to all code following
> (in program order) the spin_unlock_wait().
>
> 2. Any access prior (in program order) to the
> spin_unlock_wait() is visible to any critical
> section following the spin_unlock_wait().
>
> o spin_is_locked() semantics: Half of spin_unlock_wait(),
> but only if it returns false:
>
> 1. Any access in any critical section prior to the
> spin_unlock_wait() is visible to all code following
> (in program order) the spin_unlock_wait().
Urgh.. yes those are pain. The best advise is to not use them.
055ce0fd1b86 ("locking/qspinlock: Add comments")
