From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6531 Path: news.gmane.org!not-for-mail From: Catalin Marinas Newsgroups: gmane.linux.ports.arm.kernel,gmane.linux.lib.musl.general Subject: Re: ARM atomics overhaul for musl Date: Mon, 17 Nov 2014 11:48:33 +0000 Message-ID: <20141117114832.GB29595@e104818-lin.cambridge.arm.com> References: <20141116055656.GA13940@brightrain.aerifal.cx> <20141116163355.GK4042@n2100.arm.linux.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1416225104 20965 80.91.229.3 (17 Nov 2014 11:51:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 17 Nov 2014 11:51:44 +0000 (UTC) Cc: Szabolcs Nagy , Rich Felker , Kees Cook , "musl@lists.openwall.com" , Andy Lutomirski , "linux-arm-kernel@lists.infradead.org" To: Russell King - ARM Linux Original-X-From: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org Mon Nov 17 12:51:39 2014 Return-path: Envelope-to: linux-arm-kernel@m.gmane.org Original-Received: from bombadil.infradead.org ([198.137.202.9]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XqKqG-0004WI-4t for linux-arm-kernel@m.gmane.org; Mon, 17 Nov 2014 12:51:36 +0100 Original-Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XqKpl-0005qA-Pu; Mon, 17 Nov 2014 11:51:05 +0000 Original-Received: from foss-mx-na.foss.arm.com ([217.140.108.86]) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1XqKo3-0002oA-Ux for linux-arm-kernel@lists.infradead.org; Mon, 17 Nov 2014 11:49:20 +0000 Original-Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8]) by foss-mx-na.foss.arm.com (Postfix) with ESMTP id DC09DD6; Mon, 17 Nov 2014 05:48:39 -0600 (CST) Original-Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com [10.112.81.134]) by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id 920DE5FAD7; Mon, 17 Nov 2014 05:48:36 -0600 (CST) Original-Received: from e104818-lin.cambridge.arm.com (e104818-lin.cambridge.arm.com [10.1.203.148]) by collaborate-mta1.arm.com (Postfix) with ESMTPS id 5B79313F8B9; Mon, 17 Nov 2014 05:48:35 -0600 (CST) Content-Disposition: inline In-Reply-To: <20141116163355.GK4042@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.23 (2014-03-12) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141117_034920_181981_1FFC449E X-CRM114-Status: GOOD ( 14.49 ) X-Spam-Score: -0.0 (/) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-0.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org Xref: news.gmane.org gmane.linux.ports.arm.kernel:372449 gmane.linux.lib.musl.general:6531 Archived-At: On Sun, Nov 16, 2014 at 04:33:56PM +0000, Russell King - ARM Linux wrote: > On Sun, Nov 16, 2014 at 12:56:56AM -0500, Rich Felker wrote: > > Aside from that, the only case among the above that's "right" already > > is v7+. Hard-coding the mcr-based barrier on v6 is wrong because it's > > I don't think it's wrong at all. The instruction isn't going away from > ARMv7, because ARMv7 deprecates it, but it _still_ has to be implemented > by a CPU conforming to ARMv7. As ARMv7 is going to be the last 32-bit > ARM architecture, we aren't going to see the MCR instruction disappearing > on 32-bit CPUs. You are wrong here. ARMv8-A supports 32-bit at all levels. ARMv8-R is 32-bit only (and it even has an MMU at EL1). And there is a slight chance that we may even see 32-bit only ARMv8-A implementations (I'm not really giving a hint and I'm not aware of any but I don't see anything preventing this, it's all marketing driven). http://www.arm.com/products/processors/instruction-set-architectures/armv8-r-architecture.php > On ARMv8, it may have been removed, but we have already decided that the > kernel _must_ provide emulation for this op-code, because otherwise we > are breaking existing userspace, which is just not permissible. However, > you are absolutely right that running on ARMv8 should use the new > instruction where possible. Even on ARMv8 we could enable CP15 barriers in hardware, they are just deprecated but haven't been removed (yet). What I'm pushing for, though it's not easy, is that the hardware just deprecates such instructions for performance rather than removing them entirely. This would make them faster than emulation but I fully agree with you that the new instructions should be used where possible. -- Catalin