Received: by 10.213.65.68 with SMTP id h4csp931472imn; Wed, 4 Apr 2018 09:36:14 -0700 (PDT) X-Google-Smtp-Source: AIpwx48Xld+h1PiQV26Z2JGAaTrpBtdtRrAcxt3rBbk9V9U6gvV3Lc7gX/N+wjiC8xHX9xObcZ2F X-Received: by 2002:a17:902:5204:: with SMTP id z4-v6mr19213939plh.385.1522859774304; Wed, 04 Apr 2018 09:36:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522859774; cv=none; d=google.com; s=arc-20160816; b=LBdfy/iDK9GdBuN2sWSEPW6HbqnukJQySafPodWPW7IsEEqAXkR01bHZ4BD4TkGLbp AaW2p+91Txrkhdy/XQ6vx8xJtJMJjLfv6u+paNBamXzyzJzTbWhAIHHUKGE1BkVZexYK 8EBr+/l4nNlY+FZV+s3QTUI4UX+2PNc2JFmjpYZtOptwU8OgpVpjYmr/mi89A6Qyz3KR wSiTfxkPkGa1gFgYK08Cb8UlwhVOZrrJVGA6ql62h8FRMOP4p/mvJXGbw0DFgLuLTSvV gspA3IY1dIE7BSQedVaAlzovORWBa6TBiv5hFT6oSVHvPussb4Z2xPU/GeuQcgq59t6u sY3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=+2I0+SQRJ0nt8xQDy4YbKpubvaC0hyqBiPTvBj5XlbY=; b=F4G1663U5lQyjsnsnTko69yqSxG4KH/5JgudIFud+1OC2yJv0tKcMlQ5EwWeFOI0qw iHASuG95QYcFJmNIB5x1DZw55Nkr67gc0dQOzNfBVIU5YtiFxrEjJfUyvhx8xT9pKetB sxPdgZkBUgX4S6wIGu0xp5e00Fu8CnsEcOVB4gV1pxw+JhMLEZagSbHwR9AoIyT4pKjt L+ia10B5KR4TLK7ErLs2081b7EQhrVDvB0tr5X2w/RnoZp6sCeri5sCFmDZBWvBlMDF6 Qyi6DAuLJ4gFTCJotxP2F+tBHTGL7C9a5Ac/+e2y+5x1bqTd35hk6RNp6NvjguSZS1uA vZ7g== 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 f12si3832939pgq.411.2018.04.04.09.35.59; Wed, 04 Apr 2018 09:36:14 -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 S1752125AbeDDQev (ORCPT + 99 others); Wed, 4 Apr 2018 12:34:51 -0400 Received: from foss.arm.com ([217.140.101.70]:46440 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751896AbeDDQeu (ORCPT ); Wed, 4 Apr 2018 12:34:50 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 497E41529; Wed, 4 Apr 2018 09:34:50 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 39B8A3F24A; Wed, 4 Apr 2018 09:34:49 -0700 (PDT) From: Mark Rutland To: linux-kernel@vger.kernel.org Cc: lizhijian@cn.fujitsu.com, sandipan@linux.vnet.ibm.com, Mark Rutland , Arnaldo Carvalho de Melo Subject: [PATCH] tools: restore READ_ONCE() C++ compatibility Date: Wed, 4 Apr 2018 17:34:45 +0100 Message-Id: <20180404163445.16492-1-mark.rutland@arm.com> X-Mailer: git-send-email 2.11.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Our userspace defines READ_ONCE() in a way that clang doesn't like, as we have an anonymous union in which neither field is initialized. WRITE_ONCE() is fine since it initializes the __val field. For READ_ONCE() we can keep clang and GCC happy with a dummy initialization of the __c field, so let's do that. At the same time, let's split READ_ONCE() and WRITE_ONCE() over several lines for legibility, as we do in the in-kernel . Signed-off-by: Mark Rutland Fixes: 6aa7de059173a986 ("locking/atomics: COCCINELLE/treewide: Convert trivial ACCESS_ONCE() patterns to READ_ONCE()/WRITE_ONCE()") Reported-by: Li Zhijian Reported-by: Sandipan Das Cc: Arnaldo Carvalho de Melo --- tools/include/linux/compiler.h | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) Hi, This is fallout from my automated ACCESS_ONCE() removal, and I'm not that familiar with using clang for perf. In local testing, this fixes READ_ONCE() when compiling with clang, but I subsequently hit some other issues which I believe are down to LLVM API changes. Zhijian, Sandipan, does this patch work for you? Thanks, Mark. diff --git a/tools/include/linux/compiler.h b/tools/include/linux/compiler.h index 04e32f965ad7..1827c2f973f9 100644 --- a/tools/include/linux/compiler.h +++ b/tools/include/linux/compiler.h @@ -151,11 +151,21 @@ static __always_inline void __write_once_size(volatile void *p, void *res, int s * required ordering. */ -#define READ_ONCE(x) \ - ({ union { typeof(x) __val; char __c[1]; } __u; __read_once_size(&(x), __u.__c, sizeof(x)); __u.__val; }) - -#define WRITE_ONCE(x, val) \ - ({ union { typeof(x) __val; char __c[1]; } __u = { .__val = (val) }; __write_once_size(&(x), __u.__c, sizeof(x)); __u.__val; }) +#define READ_ONCE(x) \ +({ \ + union { typeof(x) __val; char __c[1]; } __u = \ + { .__c = { 0 } }; \ + __read_once_size(&(x), __u.__c, sizeof(x)); \ + __u.__val; \ +}) + +#define WRITE_ONCE(x, val) \ +({ \ + union { typeof(x) __val; char __c[1]; } __u = \ + { .__val = (val) }; \ + __write_once_size(&(x), __u.__c, sizeof(x)); \ + __u.__val; \ +}) #ifndef __fallthrough -- 2.11.0