On Nov 7, 2017, at 4:59 AM, Jan Kara <[email protected]> wrote: > On Mon 06-11-17 10:47:08, Davidlohr Bueso wrote: >> + /* >> + * Serialize dlist->used_lists such that a 0->1 transition is not >> + * missed by another thread checking if any of the dlock lists are >> + * used. >> + * >> + * CPU0 CPU1 >> + * dlock_list_add() dlock_lists_empty() >> + * [S] atomic_inc(used_lists); >> + * smp_mb__after_atomic(); >> + * smp_mb__before_atomic(); >> + * [L] atomic_read(used_lists) >> + * list_add() >> + */ >> + smp_mb__before_atomic(); >> + return !atomic_read(&dlist->used_lists);
Just a general kernel programming question here - I thought the whole point
of atomics is that they are, well, atomic across all CPUs so there is no
need for a memory barrier? If there is a need for a memory barrier for
each atomic access (assuming it isn't accessed under another lock, which would
make the use of atomic types pointless, IMHO) then I'd think there is a lot
of code in the kernel that isn't doing this properly.
What am I missing here?
I don't see how this helps if the operations are executed like:
* CPU0 CPU1
* dlock_list_add() dlock_lists_empty()
* [S] atomic_inc(used_lists);
* smp_mb__before_atomic();
* smp_mb__after_atomic();
* [L] atomic_read(used_lists)
or alternately like:
* CPU0 CPU1
* dlock_list_add() dlock_lists_empty()
* smp_mb__before_atomic();
* [S] atomic_inc(used_lists);
* smp_mb__after_atomic();
* [L] atomic_read(used_lists)
then the same problem would exist, unless those functions/macros are somehow
bound to the atomic operations themselves? In that case, what makes the use
of atomic_{inc,dec,read}() in other parts of the code safe without them?
Cheers, Andreas
signature.asc
Description: Message signed with OpenPGP
