[PATCH 2/2] ARM: include: asm: use 'int' instead of 'unsigned long' for normal register variables within atomic.h

Chen Gang gang.chen at asianux.com
Tue Oct 8 00:10:12 EDT 2013


Excluding current discussion, the 2 patches (patch 1/2, patch 2/2) for
arm are both OK?

Thanks.

On 10/05/2013 08:11 AM, Chen Gang wrote:
> On 10/05/2013 07:55 AM, Chen Gang wrote:
>> On 10/04/2013 11:42 PM, Will Deacon wrote:
>>> On Fri, Oct 04, 2013 at 04:37:42PM +0100, Will Deacon wrote:
>>>> On Fri, Oct 04, 2013 at 10:51:56AM +0100, Chen Gang wrote:
>>>>> On 10/04/2013 12:32 AM, Will Deacon wrote:
>>>>>> The problem with arm64 is that we're using *unsigned long* for 32-bit
>>>>>> clear_mask, which is definitely wrong because it's 64-bit (another patch to
>>>>>> fix this!).
>>>>>>
>>>>>
>>>>> At least, that is not a bug.
>>>>
>>>> Sure it is. What if the adjacent 32-bit value was being accessed by another
>>>> CPU under a spinlock?
>>>
>>> (Oh, ok, that would still work on arm because of the way the exclusive
>>> monitor is implemented, but we shouldn't rely on that).
>>>
>>
>> Hmm... in my opinion, we need divide atomic_*_mask() into 32-bit and
>> 64-bit versions. We already have demands to only use 32-bit value to
>> express mask (can save size), and may have demands to use 64-bit too.
>>
>> If so, can easily standard all atomic_*_mask() which are in asm-generic
>> and various architectures: use atomic_*_mask() for 32-bit mask, and use
>> atomic64_*_mask() for 64-bit mask (can delayed before get real demands).
>>
>> Since it is about API, so it is related with asm-generic and all other
>> architectures interfaces, it is better to consider about them firstly
>> before the fix under arm64.
>>
>>
>> And also, excuse me, I am not quite familiar with "exclusive monitor",
>> could you please provide more details about it?
>>
> 
> If in arm64 with allmodconfig, we only need atomic_*_mask() for 32-bit
> mask, don't need 64-bit, we can use 'unsigned int' instead of 'unsigned
> long' (need not consider about asm-generic and other architectures).
> 
> 
> 
>>
>>> Will
>>>
>>>
>>
>>
>> Thanks.
>>
> 
> 


-- 
Chen Gang



More information about the linux-arm-kernel mailing list