From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: smtp.codeaurora.org; dkim=pass (2048-bit key) header.d=profitbricks-com.20150623.gappssmtp.com header.i=@profitbricks-com.20150623.gappssmtp.com header.b="zHj/8C0s" DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org C3F85601D2 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=profitbricks.com Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752187AbeFFOln (ORCPT + 25 others); Wed, 6 Jun 2018 10:41:43 -0400 Received: from mail-io0-f181.google.com ([209.85.223.181]:35415 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751994AbeFFOll (ORCPT ); Wed, 6 Jun 2018 10:41:41 -0400 X-Google-Smtp-Source: ADUXVKKYDfMoiaZHf7skTPWO3BiqWqvwMeR723I9ZinB1Ij/jF2jOtTYJAic5wuLHv/Od0h74iJs+IsDGyFrT1LnJJs= MIME-Version: 1.0 In-Reply-To: References: From: Roman Penyaev Date: Wed, 6 Jun 2018 16:41:20 +0200 Message-ID: Subject: Re: LKMM litmus test for Roman Penyaev's rcu-rr To: Alan Stern Cc: "Paul E. McKenney" , Linus Torvalds , Linux Kernel Mailing List , linux-arch , andrea.parri@amarulasolutions.com, Will Deacon , Peter Zijlstra , Boqun Feng , Nick Piggin , David Howells , Jade Alglave , Luc Maranget , Akira Yokosawa , Ingo Molnar Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 6, 2018 at 3:54 PM, Alan Stern wrote: > On Wed, 6 Jun 2018, Roman Penyaev wrote: > >> > Preserving the order of volatile accesses isn't sufficient. The >> > compiler is still allowed to translate >> > >> > r1 = READ_ONCE(x); >> > if (r1) { >> > ... >> > } >> > WRITE_ONCE(y, r2); >> > >> > into something resembling >> > >> > r1 = READ_ONCE(x); >> > WRITE_ONCE(y, r2); >> > if (r1) { >> > ... >> > } >> >> Hi Alan, >> >> According to the standard C99 Annex C "the controlling expression of >> a selection statement (if or switch)" are the sequence points, just >> like a volatile access (READ_ONCE or WRITE_ONCE). >> >> "5.1.2.3 Program execution" states: >> "At certain specified points in the execution sequence called sequence >> points, all side effects of previous evaluations shall be complete >> and no side effects of subsequent evaluations shall have taken place." >> >> So in the example we have 3 sequence points: "READ_ONCE", "if" and >> "WRITE_ONCE", which it seems can't be reordered. Am I mistaken >> interpreting standard? Could you please clarify. > > Well, for one thing, we're talking about C11, not C99. C11 is a n1570, ISO/IEC 9899:2011 ? (according to wiki). Found pdf on the web contains similar lines, so should not be any differences for that particular case. > For another, as far as I understand it, the standard means the program > should behave _as if_ the side effects are completed in the order > stated. It doesn't mean that the generated code has to behave that way > literally. Then I do not understand what are the differences between "side effects are completed" and "code generated". Abstract machine state should provide some guarantees between sequence points, e.g.: foo(); /* function call */ ------------| *a = 1; | *b = 12; | Compiler in his right to reorder. *c = 123; | ------------| boo(); /* function call */ compiler in his right to reorder memory accesses between foo() and boo() calls (foo and boo are sequence points, but memory accesses are not), but: foo(); /* function call */ *(volatile int *)a = 1; *(volatile int *)b = 12; *(volatile int *)c = 123; boo(); /* function call */ are all sequence points, so compiler can't reorder them. Where am I mistaken? > And in particular, the standard is referring to the > behavior of a single thread, not the interaction between multiple > concurrent threads. Yes, that is clear: we are talking about code reordering in one particular function in a single threaded environment. -- Roman