Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5697517ybe; Tue, 10 Sep 2019 07:34:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqzOiB0Mltoue3OtdhHq81ue0vEwnQ0zGLj+IPX0lKtW0tBKOP+mL4mkp9XnHmfS5Qly2Ei2 X-Received: by 2002:a17:906:d932:: with SMTP id rn18mr25222406ejb.49.1568126069912; Tue, 10 Sep 2019 07:34:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568126069; cv=none; d=google.com; s=arc-20160816; b=pZTn4jYoAD6MOEtSNVy6A2NSbt0MZvy1bIqiVU39XiDmHjTUACDeIVId2XnnOoMlxS mGT5RBY2GSnd6r/67I99BPGxmvTAb/iwcTR5n65QRPaNAR+soB82CI+IDRbn2L34gRWv ldt2+hLjtCfz3o48y885Z0Gd2rrIdatTR8XZsNsr1OtLY8KDeBcHzje2F/fr0njKNA7/ gLkLYzVKwefYypBmOAtpbzRvc6zLlyiuTjZNz6rlK6NAH3mKxwoFmEmSFf4RUcu1QN3p HcIixYE7bMRRIC6zo80OUAN42wNJg5aZjN1+J8DwDACV/WIsb1Xk2NMUd+Rban0gHVOz 5Klw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=7Y75V9fDKzp+2J49oYKhrB+wp1MupSTaAL/uxnift3Y=; b=JVQOZXZfBJxkdpoNjsDA0eNc9EZWA31otV1vxswb62H5sTgdEfV5ILxLC4Ho4dVUyI YeLx6myXFKLn1qGd6M2wRF5UMAenuBvaTAPtgLvMh6mXrfWnRZfLXoZO/spv1wqxo+Bk V+dK6uYLVG9dkeReCtiY4Mz2rGOlvb1oUndbzbqfJvpxHJ5SaeuoxinFlCs2+T34Vrsn jGjUwcOVaRv80FDCPQk8vFbHgFwltKRpn3Z+BUNxhBF6SSdfh4fMR0pfSmxF49egUyGF otZKuHxrq0EUGdnxGAFnOt86vjVi+IKTPBnJWhRSB252Y/wQaedaW1XjoM19+QekX9g0 j51w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y26si9510389ejj.298.2019.09.10.07.34.05; Tue, 10 Sep 2019 07:34:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732581AbfIJOVY (ORCPT + 99 others); Tue, 10 Sep 2019 10:21:24 -0400 Received: from foss.arm.com ([217.140.110.172]:36004 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730779AbfIJOVY (ORCPT ); Tue, 10 Sep 2019 10:21:24 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9925828; Tue, 10 Sep 2019 07:21:23 -0700 (PDT) Received: from localhost (unknown [10.37.6.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 10C1E3F71F; Tue, 10 Sep 2019 07:21:22 -0700 (PDT) Date: Tue, 10 Sep 2019 15:21:21 +0100 From: Andrew Murray To: Will Deacon Cc: Arnd Bergmann , Catalin Marinas , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com Subject: Re: [PATCH] arm64: fix unreachable code issue with cmpxchg Message-ID: <20190910142120.GM9720@e119886-lin.cambridge.arm.com> References: <20190909202153.144970-1-arnd@arndb.de> <20190910074606.45k5m2pkztlpj4nj@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190910074606.45k5m2pkztlpj4nj@willie-the-truck> User-Agent: Mutt/1.10.1+81 (426a6c1) (2018-08-26) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 10, 2019 at 08:46:07AM +0100, Will Deacon wrote: > On Mon, Sep 09, 2019 at 10:21:35PM +0200, Arnd Bergmann wrote: > > On arm64 build with clang, sometimes the __cmpxchg_mb is not inlined > > when CONFIG_OPTIMIZE_INLINING is set. > > Hmm. Given that CONFIG_OPTIMIZE_INLINING has also been shown to break > assignment of local 'register' variables on GCC, perhaps we should just > disable that option for arm64 (at least) since we don't have any toolchains > that seem to like it very much! I'd certainly prefer that over playing > whack-a-mole with __always_inline. I assume we're referring to stuff such as the following? https://www.spinics.net/lists/arm-kernel/msg730329.html Are these breakages limited to the out-of-line hacks made for LL/SC atomics, or were there other breakages elsewhere? Now that the out-of-line hacks have gone, I wonder if this is actually still a problem anymore. In any case isn't the right thing to do there to add the __always_inline to functions that use the register keyword in a function currently annotated inline? I'm happy to look into this if there is likely to be some benefit in turning on CONFIG_OPTIMIZE_INLINING. Thanks, Andrew Murray > > Will