From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933258AbcLGWRA (ORCPT ); Wed, 7 Dec 2016 17:17:00 -0500 Received: from mail-wj0-f175.google.com ([209.85.210.175]:33094 "EHLO mail-wj0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932339AbcLGWQ6 (ORCPT ); Wed, 7 Dec 2016 17:16:58 -0500 From: Rasmus Villemoes To: Christian Borntraeger Cc: Michal Hocko , Vlastimil Babka , Xishi Qiu , Andrew Morton , Mel Gorman , Yaowei Bai , Linux MM , LKML , Yisheng Xie Subject: Re: [RFC PATCH v3] mm: use READ_ONCE in page_cpupid_xchg_last() Organization: D03 References: <584523E4.9030600@huawei.com> <58461A0A.3070504@huawei.com> <20161207084305.GA20350@dhcp22.suse.cz> <7b74a021-e472-a21e-7936-6741e07906b5@suse.cz> <20161207085809.GD17136@dhcp22.suse.cz> <20161207095943.GF17136@dhcp22.suse.cz> <5d4accd3-e26b-d23f-5417-debe9ad7148a@de.ibm.com> X-Hashcash: 1:20:161207:borntraeger@de.ibm.com::aKoP0v5xHvsx/Iek:0000000000000000000000000000000000000000el+ X-Hashcash: 1:20:161207:xieyisheng1@huawei.com::wo6Mv5tt0s5lGSfh:0000000000000000000000000000000000000001iVd X-Hashcash: 1:20:161207:vbabka@suse.cz::3TaDJ8PKRk/LoR4k:0001upE X-Hashcash: 1:20:161207:baiyaowei@cmss.chinamobile.com::CkbCZJN6L73Me++n:00000000000000000000000000000001wlV X-Hashcash: 1:20:161207:linux-kernel@vger.kernel.org::Z30bKPxWyLpXAXpQ:0000000000000000000000000000000001XR+ X-Hashcash: 1:20:161207:akpm@linux-foundation.org::fhmMeUiOc4ZcrmZF:0000000000000000000000000000000000001lkl X-Hashcash: 1:20:161207:mgorman@techsingularity.net::jzcLiulqGQK/IwZT:000000000000000000000000000000000020os X-Hashcash: 1:20:161207:mhocko@kernel.org::32bYFs7KL4JkRvK2:000000000000000000000000000000000000000000003gPZ X-Hashcash: 1:20:161207:qiuxishi@huawei.com::FYIrcAfH0wIR/gVV:0000000000000000000000000000000000000000002yGE X-Hashcash: 1:20:161207:linux-mm@kvack.org::JWWijUxBx1BnQ+7w:0000000000000000000000000000000000000000000DUqt Date: Wed, 07 Dec 2016 23:16:55 +0100 In-Reply-To: <5d4accd3-e26b-d23f-5417-debe9ad7148a@de.ibm.com> (Christian Borntraeger's message of "Wed, 7 Dec 2016 11:03:29 +0100") Message-ID: <877f7bqt9k.fsf@rasmusvillemoes.dk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 07 2016, Christian Borntraeger wrote: > On 12/07/2016 10:59 AM, Michal Hocko wrote: >> On Wed 07-12-16 10:40:47, Christian Borntraeger wrote: >>> On 12/07/2016 10:29 AM, Vlastimil Babka wrote: >>>> On 12/07/2016 09:58 AM, Michal Hocko wrote: >>>>> On Wed 07-12-16 09:48:52, Vlastimil Babka wrote: >>>>> Anyway, this could be addressed easily by >>>> >>>> Yes, that way there should be no doubt. >>> >>> That change would make it clearer, but the code is correct anyway, >>> as assignments in C are done from right to left, so >>> old_flags = flags = READ_ONCE(page->flags); >>> >>> is equivalent to >>> >>> flags = READ_ONCE(page->flags); >>> old_flags = flags; >> >> OK, I guess you are right. For some reason I thought that the compiler >> is free to bypass flags and split an assignment >> a = b = c; into b = c; a = c >> which would still follow from right to left rule. I guess I am over >> speculating here though, so sorry for the noise. > > Hmmm, just rereading C, I am no longer sure... > I cannot find anything right now, that adds a sequence point in here. > Still looking... C99 6.5.16.3: ... An assignment expression has the value of the left operand after the assignment, .... So if the expression c can have side effects or is for any reason (e.g. volatile) not guaranteed to produce the same value if it's evaluated again, there's no way the compiler would be allowed to change a=b=c; into b=c; a=c;. (Also, this means that in "int a, c = 256; char b; a=b=c;", a ends up with the value 0.) Somewhat related: https://lwn.net/Articles/233902/