>>> On 23.04.15 at 16:43, <t...@xen.org> wrote:
> At 14:54 +0100 on 23 Apr (1429800874), Jan Beulich wrote:
>> >>> On 23.04.15 at 14:03, <t...@xen.org> wrote:
>> > At 11:11 +0100 on 21 Apr (1429614687), David Vrabel wrote:
>> >> void _spin_unlock(spinlock_t *lock)
>> >> {
>> >> + smp_mb();
>> >> preempt_enable();
>> >> LOCK_PROFILE_REL;
>> >> - _raw_spin_unlock(&lock->raw);
>> >> + lock->tickets.head++;
>> >
>> > This needs to be done with an explicit atomic (though not locked)
>> > write; otherwise the compiler might use some unsuitable operation that
>> > clobbers .tail as well.
>>
>> How do you imagine that to happen? An increment of one
>> structure member surely won't modify any others.
>
> AIUI, the '++' could end up as a word-size read, modify, and word-size
> write. If another CPU updates .tail parallel, that update could get
> lost.
Ah, right, compilers are allowed to do that, albeit normally wouldn't
unless the architecture has no suitable loads/stores.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
