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:

quoted

On 10/04/2013 11:42 PM, Will Deacon wrote:

quoted

On Fri, Oct 04, 2013 at 04:37:42PM +0100, Will Deacon wrote:

quoted

On Fri, Oct 04, 2013 at 10:51:56AM +0100, Chen Gang wrote:

quoted

On 10/04/2013 12:32 AM, Will Deacon wrote:

quoted

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).

quoted

quoted

Will

Thanks.

-- 
Chen Gang