From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4D972C433F5 for ; Tue, 26 Apr 2022 13:00:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=JzH2OYFystH65DCPP95EuspTTU+N2wmF6dLjwmAqgJA=; b=2YIIuJhLdI2UGV lqWlqUzJAt2LBfmmRYA23nnoitmFZjQAkwPq/3qx/zcgzG63jH9TB+bjHGYuL7bgW/pP6IMxXsW12 Yye2oO2gVK6FvcNd8Zetq90ctfovBMoKfvOy93/gjxyG6gXbmJUWrniQdwVxLD2L0QO/LRPnsacjZ sIyCRVPyQROZ/nFTtJcu9ohlGo+ZMUfkvr5vHEbcxV4xQ2ed2tgQJRcs9eg3eAyy51FeB9WutSnG1 BUvLx3BXu9h3ycp1M/emGuWSxWv/1dRzy6xEDGOhF7fVzzr23NcAbvFnfL3e4T4Tu2PfBJdtFm6zV xb3z+bIJJaSrF64SAtWA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1njKmo-00EPj8-0h; Tue, 26 Apr 2022 12:59:22 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1njKX3-00EK7N-4h for linux-arm-kernel@lists.infradead.org; Tue, 26 Apr 2022 12:43:07 +0000 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 40CBD23A; Tue, 26 Apr 2022 05:43:02 -0700 (PDT) Received: from lakrids (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5BD4B3F774; Tue, 26 Apr 2022 05:43:01 -0700 (PDT) Date: Tue, 26 Apr 2022 13:42:31 +0100 From: Mark Rutland To: Kefeng Wang Cc: elver@google.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: kcsan: Fix kcsan test_barrier fail and panic Message-ID: References: <20220426081700.1376542-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220426081700.1376542-1-wangkefeng.wang@huawei.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220426_054305_324359_B21C4104 X-CRM114-Status: GOOD ( 24.86 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Tue, Apr 26, 2022 at 08:17:00AM +0000, Kefeng Wang wrote: > As "kcsan: Support detecting a subset of missing memory barriers" > introduced KCSAN_STRICT which make kcsan detects more missing memory > barrier, but arm64 don't have KCSAN instrumentation for barriers, so > the new selftest test_barrier() will fail, then panic. > > Let's prefix all barriers with __ on arm64, as asm-generic/barriers.h > defined the final instrumented version of these barriers, which will > fix the above issues. > > Fixes: dd03762ab608 ("arm64: Enable KCSAN") > Signed-off-by: Kefeng Wang I don't think the Fixes tag is necessary given this is a new feature which depends upon EXPERT, and I'm worried it encourages backporting this into a kernel where it would be broken, so I'd prefer we drop that tag. IIUC when we originially looked at this the instrumentation wasn't safe and would violate noinstr requirements. Looking at linux/kcsan-checks.h, the comments block for __KCSAN_BARRIER_TO_SIGNAL_FENCE() say that it will respect __nokcsan, so it looks like that might be safe now. It looks like that's the case as of commit: bd3d5bd1a0ad3864 ("kcsan: Support WEAK_MEMORY with Clang where no objtool support exists") ... which requires clang 14.0.0+. That looks to have gone in concurrently with dd03762ab608, but is clearly a prerequisite, so as above I'd strongly prefer we drop the Fixes tag. It would be good if we could note that explicitly in the commit message. Have you eyeballed the generated assembly to verify that this works as expected for __nokcsan ? Thanks, Mark. > --- > arch/arm64/include/asm/barrier.h | 12 ++++++------ > include/asm-generic/barrier.h | 4 ++++ > 2 files changed, 10 insertions(+), 6 deletions(-) > > diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h > index 62217be36217..9760a8d4ed0a 100644 > --- a/arch/arm64/include/asm/barrier.h > +++ b/arch/arm64/include/asm/barrier.h > @@ -46,13 +46,13 @@ > #define pmr_sync() do {} while (0) > #endif > > -#define mb() dsb(sy) > -#define rmb() dsb(ld) > -#define wmb() dsb(st) > +#define __mb() dsb(sy) > +#define __rmb() dsb(ld) > +#define __wmb() dsb(st) > > -#define dma_mb() dmb(osh) > -#define dma_rmb() dmb(oshld) > -#define dma_wmb() dmb(oshst) > +#define __dma_mb() dmb(osh) > +#define __dma_rmb() dmb(oshld) > +#define __dma_wmb() dmb(oshst) > > #define io_stop_wc() dgh() > > diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h > index fd7e8fbaeef1..18863c50e9ce 100644 > --- a/include/asm-generic/barrier.h > +++ b/include/asm-generic/barrier.h > @@ -38,6 +38,10 @@ > #define wmb() do { kcsan_wmb(); __wmb(); } while (0) > #endif > > +#ifdef __dma_mb > +#define dma_mb() do { kcsan_mb(); __dma_mb(); } while (0) > +#endif > + > #ifdef __dma_rmb > #define dma_rmb() do { kcsan_rmb(); __dma_rmb(); } while (0) > #endif > -- > 2.27.0 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel