Firstly thank you very much for replying quickly with details.
On 06/28/2013 11:09 PM, Ralf Baechle wrote:
> On Fri, Jun 28, 2013 at 09:51:35AM +0800, Chen Gang wrote:
>
>> Need add cmpxchg64(), or will cause compiling issue.
>>
>> Just define it as cmpxchg(), since cmpxchg() can support 8 bytes.
>>
>> The related error (with allmodconfig):
>>
>> drivers/block/blockconsole.c: In function ‘bcon_advance_console_bytes’:
>> drivers/block/blockconsole.c:164:2: error: implicit declaration of
>> function ‘cmpxchg64’ [-Werror=implicit-function-declaration]
>>
>> Signed-off-by: Chen Gang <gang.c...@asianux.com>
>> ---
>> arch/tile/include/asm/cmpxchg.h | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/tile/include/asm/cmpxchg.h
>> b/arch/tile/include/asm/cmpxchg.h
>> index 276f067..7688c28 100644
>> --- a/arch/tile/include/asm/cmpxchg.h
>> +++ b/arch/tile/include/asm/cmpxchg.h
>> @@ -68,6 +68,8 @@ extern unsigned long
>> __cmpxchg_called_with_bad_pointer(void);
>>
>> #define tas(ptr) (xchg((ptr), 1))
>>
>> +#define cmpxchg64(ptr, o, n) cmpxchg((ptr), (o), (n))
>
> that's broken. cmpxchg64 is suposed to work on 64 bit operands ONLY. This
> definition (used by MIPS and Alpha) will work properly:
>
Oh, really it is. thanks.
> #define cmpxchg64(ptr, o, n) \
> ({ \
> BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
> cmpxchg((ptr), (o), (n)); \
> })
>
I should follow it to send patch v2, thanks.
> This should cure blockconsole on Tile but not on MIPS.
>
> struct blockconsole {
> ..
> u64 console_bytes;
> ..
> };
>
> static void bcon_advance_console_bytes(struct blockconsole *bc, int bytes)
> {
> u64 old, new;
> ...
> } while (cmpxchg64(&bc->console_bytes, old, new) != old);
> }
>
> So it's using cmpxchg64() to operate on 64 bit objects - but that's not
> going to work on every architecture. Many 32 bit architectures only
> provide atomic operations that operate on 32 bit quantities.
>
I guess your meaning is:
cmpxchg64() should be an atomic operation.
but on some of 32-bit architectures, they don't implement it as atomic
(no lock protected, at least).
it may cause issue on these 32-bit architectures.
Is it correct ?
If it is correct, I should continue to try to fix it.
Thanks.
--
Chen Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
