|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCHv3 1/4] x86: provide xadd()
>>> On 21.04.15 at 14:36, <david.vrabel@xxxxxxxxxx> wrote:
> On 21/04/15 11:36, Jan Beulich wrote:
>>>>> On 21.04.15 at 12:11, <david.vrabel@xxxxxxxxxx> wrote:
>>> +static always_inline unsigned long __xadd(
>>> + volatile void *ptr, unsigned long v, int size)
>>> +{
>>> + switch ( size )
>>> + {
>>> + case 1:
>>> + asm volatile ( "lock; xaddb %b0,%1"
>>> + : "+r" (v), "+m" (*__xg((volatile void *)ptr))
>>> + :: "memory");
>>> + return v;
>>
>> This doesn't seem to guarantee to return the old value: When the
>> passed in v has more than 8 significant bits (which will get ignored
>> as input), nothing will zap those bits from the register. Same for
>> the 16-bit case obviously.
>>
>>> +#define xadd(ptr, v) ({ \
>>> + __xadd((ptr), (unsigned long)(v), sizeof(*(ptr))); \
>>> + })
>>
>> Assuming only xadd() is supposed to be used directly, perhaps
>> the easiest would be to cast v to typeof(*(ptr)) (instead of
>> unsigned long) here?
>
> I don't see how this helps. Did you perhaps mean cast the result?
>
> #define xadd(ptr, v) ({ \
> (typeof *(ptr))__xadd(ptr, (unsigned long)(v), \
> sizeof(*(ptr))); \
> })
Casting the result would work too; casting the input would have
the same effect because (as said) the actual xadd doesn't alter
bits 8...63 (or 16...63 in the 16-bit case), i.e. whether zero
extension happens before or after doing the xadd doesn't matter.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |