linux-kernel - Re: [RFC PATCH] mm: use ACCESS_ONCE in page_cpupid_xchg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 5 Dec 2016 09:50:02 +0100
From:   Christian Borntraeger <borntraeger@...ibm.com>
To:     Xishi Qiu <qiuxishi@...wei.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...hsingularity.net>,
        Yaowei Bai <baiyaowei@...s.chinamobile.com>
Cc:     Linux MM <linux-mm@...ck.org>, LKML <linux-kernel@...r.kernel.org>,
        Yisheng Xie <xieyisheng1@...wei.com>
Subject: Re: [RFC PATCH] mm: use ACCESS_ONCE in page_cpupid_xchg_last()

On 12/05/2016 09:31 AM, Christian Borntraeger wrote:
> On 12/05/2016 09:23 AM, Xishi Qiu wrote:
>> By reading the code, I find the following code maybe optimized by
>> compiler, maybe page->flags and old_flags use the same register,
>> so use ACCESS_ONCE in page_cpupid_xchg_last() to fix the problem.
> 
> please use READ_ONCE instead of ACCESS_ONCE for future patches.
> 
>>
>> Signed-off-by: Xishi Qiu <qiuxishi@...wei.com>
>> ---
>>  mm/mmzone.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/mm/mmzone.c b/mm/mmzone.c
>> index 5652be8..e0b698e 100644
>> --- a/mm/mmzone.c
>> +++ b/mm/mmzone.c
>> @@ -102,7 +102,7 @@ int page_cpupid_xchg_last(struct page *page, int cpupid)
>>  	int last_cpupid;
>>
>>  	do {
>> -		old_flags = flags = page->flags;
>> +		old_flags = flags = ACCESS_ONCE(page->flags);
>>  		last_cpupid = page_cpupid_last(page);
>>
>>  		flags &= ~(LAST_CPUPID_MASK << LAST_CPUPID_PGSHIFT);
> 
> 
> I dont thing that this is actually a problem. The code below does  
> 
>    } while (unlikely(cmpxchg(&page->flags, old_flags, flags) != old_flags))
> 
> and the cmpxchg should be an atomic op that should already take care of everything
> (page->flags is passed as a pointer).
> 

Reading the code again, you might be right, but I think your patch description
is somewhat misleading. I think the problem is that old_flags and flags are
not necessarily the same.

So what about

a compiler could re-read "old_flags" from the memory location after reading
and calculation "flags" and passes a newer value into the cmpxchg making 
the comparison succeed while it should actually fail.