From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751316AbdKUSv6 (ORCPT ); Tue, 21 Nov 2017 13:51:58 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:51092 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751067AbdKUSv4 (ORCPT ); Tue, 21 Nov 2017 13:51:56 -0500 Date: Tue, 21 Nov 2017 10:51:47 -0800 From: "Paul E. McKenney" To: David Laight Cc: Peter Zijlstra , Will Deacon , Sami Tolvanen , Nick Desaulniers , Alex Matveev , Andi Kleen , Ard Biesheuvel , Greg Hackmann , Kees Cook , "linux-arm-kernel@lists.infradead.org" , Linux Kbuild mailing list , LKML , Mark Rutland , Masahiro Yamada , Maxim Kuvyrkov , Michal Marek , Yury Norov , Matthias Kaehlcke , Alexander Potapenko , Stephen Hines , Pirama Arumuga Nainar , Manoj Gupta Subject: Re: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG Reply-To: paulmck@linux.vnet.ibm.com References: <20171116174830.GX3624@linux.vnet.ibm.com> <20171116183950.GA3624@linux.vnet.ibm.com> <20171116184508.GC21898@arm.com> <20171116191307.GC3624@linux.vnet.ibm.com> <20171116201701.GA143965@samitolvanen.mtv.corp.google.com> <20171120180554.GM32488@arm.com> <20171120193256.e6fnn2arwqc5wqkp@hirez.programming.kicks-ass.net> <20171120205350.GZ3624@linux.vnet.ibm.com> <1f19a8816278495f997f4331ef0e015e@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f19a8816278495f997f4331ef0e015e@AcuMS.aculab.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17112118-0052-0000-0000-0000028627CA X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008103; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000240; SDB=6.00949206; UDB=6.00479358; IPR=6.00729465; BA=6.00005706; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00018124; XFM=3.00000015; UTC=2017-11-21 18:51:53 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17112118-0053-0000-0000-000052B16309 Message-Id: <20171121185147.GN3624@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-11-21_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711210246 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 21, 2017 at 05:23:52PM +0000, David Laight wrote: > From: Paul E. McKenney > > Sent: 20 November 2017 20:54 > > > > On Mon, Nov 20, 2017 at 08:32:56PM +0100, Peter Zijlstra wrote: > > > On Mon, Nov 20, 2017 at 06:05:55PM +0000, Will Deacon wrote: > > > > Although the current direction of the C++ committee is to prefer > > > > that dependencies are explicitly "marked", this is not deemed to be > > > > acceptable for the kernel (in other words, everything is always considered > > > > "marked"). > > > > > > Yeah, that is an attitude not compatible with existing code. Much like > > > the proposal to allow temporary/wide stores on everything not explicitly > > > declared atomic. Such stuff instantly breaks all extant code that does > > > multi-threading with no recourse. > > > > If someone suggests temporary/wide stores, even on non-atomics, tell > > them that the standard does not permit them to introduce data races. > > The C standard doesn't say anything about multi-threading. Actually, recent versions of the C standard really do cover multi-threading, and have for some years. For example, the June 2010 draft has this to say in section 5.1.2.4: Under a hosted implementation, a program can have more than one thread of execution (or thread) running concurrently. Later, in paragraph 25 of this same section: The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior. Because the compiler is not allowed to introduce undefined behavior in a program that does not already contain undefined behavior, the compiler is absolutely forbidden from inventing stores unless it can prove that doing so does not introduce a data race. One (painful and annoying) case in which it can prove this is just before a normal (non-volatile and non-atomic) store. > The x86 bis (bit set) family are well known for being problematic > because they always do a 32bit wide rmw cycle. If the compiler is careful, it can invent atomic read-modify-write cycles to uninvolved variables. Here "is careful" includes ensuring that any read from or write to one of those uninvolved variables acts just as it would in the absence of the atomic read-modify-write cycle. But I did say "store" above, not atomic read-modify-write operation. ;-) Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57742 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750794AbdKUSvz (ORCPT ); Tue, 21 Nov 2017 13:51:55 -0500 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vALInHbx040455 for ; Tue, 21 Nov 2017 13:51:55 -0500 Received: from e14.ny.us.ibm.com (e14.ny.us.ibm.com [129.33.205.204]) by mx0b-001b2d01.pphosted.com with ESMTP id 2ecsdn8skh-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 21 Nov 2017 13:51:54 -0500 Received: from localhost by e14.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 21 Nov 2017 13:51:53 -0500 Date: Tue, 21 Nov 2017 10:51:47 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG Reply-To: paulmck@linux.vnet.ibm.com References: <20171116174830.GX3624@linux.vnet.ibm.com> <20171116183950.GA3624@linux.vnet.ibm.com> <20171116184508.GC21898@arm.com> <20171116191307.GC3624@linux.vnet.ibm.com> <20171116201701.GA143965@samitolvanen.mtv.corp.google.com> <20171120180554.GM32488@arm.com> <20171120193256.e6fnn2arwqc5wqkp@hirez.programming.kicks-ass.net> <20171120205350.GZ3624@linux.vnet.ibm.com> <1f19a8816278495f997f4331ef0e015e@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1f19a8816278495f997f4331ef0e015e@AcuMS.aculab.com> Message-Id: <20171121185147.GN3624@linux.vnet.ibm.com> Sender: linux-kbuild-owner@vger.kernel.org List-ID: To: David Laight Cc: Peter Zijlstra , Will Deacon , Sami Tolvanen , Nick Desaulniers , Alex Matveev , Andi Kleen , Ard Biesheuvel , Greg Hackmann , Kees Cook , "linux-arm-kernel@lists.infradead.org" , Linux Kbuild mailing list , LKML , Mark Rutland , Masahiro Yamada , Maxim Kuvyrkov , Michal Marek , Yury Norov , Matthias Kaehlcke , Alexander Potapenko , Stephen Hines , Pirama Arumuga Nainar , Manoj Gupta On Tue, Nov 21, 2017 at 05:23:52PM +0000, David Laight wrote: > From: Paul E. McKenney > > Sent: 20 November 2017 20:54 > > > > On Mon, Nov 20, 2017 at 08:32:56PM +0100, Peter Zijlstra wrote: > > > On Mon, Nov 20, 2017 at 06:05:55PM +0000, Will Deacon wrote: > > > > Although the current direction of the C++ committee is to prefer > > > > that dependencies are explicitly "marked", this is not deemed to be > > > > acceptable for the kernel (in other words, everything is always considered > > > > "marked"). > > > > > > Yeah, that is an attitude not compatible with existing code. Much like > > > the proposal to allow temporary/wide stores on everything not explicitly > > > declared atomic. Such stuff instantly breaks all extant code that does > > > multi-threading with no recourse. > > > > If someone suggests temporary/wide stores, even on non-atomics, tell > > them that the standard does not permit them to introduce data races. > > The C standard doesn't say anything about multi-threading. Actually, recent versions of the C standard really do cover multi-threading, and have for some years. For example, the June 2010 draft has this to say in section 5.1.2.4: Under a hosted implementation, a program can have more than one thread of execution (or thread) running concurrently. Later, in paragraph 25 of this same section: The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior. Because the compiler is not allowed to introduce undefined behavior in a program that does not already contain undefined behavior, the compiler is absolutely forbidden from inventing stores unless it can prove that doing so does not introduce a data race. One (painful and annoying) case in which it can prove this is just before a normal (non-volatile and non-atomic) store. > The x86 bis (bit set) family are well known for being problematic > because they always do a 32bit wide rmw cycle. If the compiler is careful, it can invent atomic read-modify-write cycles to uninvolved variables. Here "is careful" includes ensuring that any read from or write to one of those uninvolved variables acts just as it would in the absence of the atomic read-modify-write cycle. But I did say "store" above, not atomic read-modify-write operation. ;-) Thanx, Paul From mboxrd@z Thu Jan 1 00:00:00 1970 From: paulmck@linux.vnet.ibm.com (Paul E. McKenney) Date: Tue, 21 Nov 2017 10:51:47 -0800 Subject: [PATCH v2 18/18] arm64: select ARCH_SUPPORTS_LTO_CLANG In-Reply-To: <1f19a8816278495f997f4331ef0e015e@AcuMS.aculab.com> References: <20171116174830.GX3624@linux.vnet.ibm.com> <20171116183950.GA3624@linux.vnet.ibm.com> <20171116184508.GC21898@arm.com> <20171116191307.GC3624@linux.vnet.ibm.com> <20171116201701.GA143965@samitolvanen.mtv.corp.google.com> <20171120180554.GM32488@arm.com> <20171120193256.e6fnn2arwqc5wqkp@hirez.programming.kicks-ass.net> <20171120205350.GZ3624@linux.vnet.ibm.com> <1f19a8816278495f997f4331ef0e015e@AcuMS.aculab.com> Message-ID: <20171121185147.GN3624@linux.vnet.ibm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Nov 21, 2017 at 05:23:52PM +0000, David Laight wrote: > From: Paul E. McKenney > > Sent: 20 November 2017 20:54 > > > > On Mon, Nov 20, 2017 at 08:32:56PM +0100, Peter Zijlstra wrote: > > > On Mon, Nov 20, 2017 at 06:05:55PM +0000, Will Deacon wrote: > > > > Although the current direction of the C++ committee is to prefer > > > > that dependencies are explicitly "marked", this is not deemed to be > > > > acceptable for the kernel (in other words, everything is always considered > > > > "marked"). > > > > > > Yeah, that is an attitude not compatible with existing code. Much like > > > the proposal to allow temporary/wide stores on everything not explicitly > > > declared atomic. Such stuff instantly breaks all extant code that does > > > multi-threading with no recourse. > > > > If someone suggests temporary/wide stores, even on non-atomics, tell > > them that the standard does not permit them to introduce data races. > > The C standard doesn't say anything about multi-threading. Actually, recent versions of the C standard really do cover multi-threading, and have for some years. For example, the June 2010 draft has this to say in section 5.1.2.4: Under a hosted implementation, a program can have more than one thread of execution (or thread) running concurrently. Later, in paragraph 25 of this same section: The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior. Because the compiler is not allowed to introduce undefined behavior in a program that does not already contain undefined behavior, the compiler is absolutely forbidden from inventing stores unless it can prove that doing so does not introduce a data race. One (painful and annoying) case in which it can prove this is just before a normal (non-volatile and non-atomic) store. > The x86 bis (bit set) family are well known for being problematic > because they always do a 32bit wide rmw cycle. If the compiler is careful, it can invent atomic read-modify-write cycles to uninvolved variables. Here "is careful" includes ensuring that any read from or write to one of those uninvolved variables acts just as it would in the absence of the atomic read-modify-write cycle. But I did say "store" above, not atomic read-modify-write operation. ;-) Thanx, Paul