Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp2840552rdb; Tue, 12 Sep 2023 13:55:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFYQ8JMDVSY915TfK3+3f4IOKjFH9JYrfMEq8zHVdgwRn2s+A9vziuQMW8RzjJQoX76SSLC X-Received: by 2002:a05:6a20:8e03:b0:14e:429e:b0e3 with SMTP id y3-20020a056a208e0300b0014e429eb0e3mr675303pzj.52.1694552102099; Tue, 12 Sep 2023 13:55:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694552102; cv=none; d=google.com; s=arc-20160816; b=oFtR71cW4BeHoQ4gEkU8PtCfccwobC1IBer74bcpS3YvzHcWCuL37YvbtkEfn8yqed LfXAwl1g64vzPSp8zBoXPVz2M10rTmuFRLk2m3JXx13Ba8shg89tBmmLy/8y+kqpoMum tZfDT4m3Ab+axefMISfFdmSANz6gdP3uq3cl4EpBhB5HYlOWQk0vFQ0h2/OLkFhR6dOk 97KXOQBj8ZEDCOhLg9W6A1uozxOKI4Nxa4lxbN5J6ydhNdL//f9xK5RBoy7h+ITblXBT GkoFJcnUVuNyYpn/W3INNt3Ax45vwDU4Nk0nIS27eST2R0jaZ3qY7ECop9Tz9Jarn570 osoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=3zscny04+Iy3y+F3i8E2Hu+bo7hgGblgHrEoqxCmfG0=; fh=uE1hNl29FTbQqSors6e48xk6V8vZsCUk3D1m8T88gbY=; b=lyNpIzLps6wDR7qLMAd/poaHjywK0JpqzCTOh+EtsXapjVN6KgmDW+80m6RgodkPo9 4iGSqB8c07PpboRLiF8boa7/wCNPsmCTlqX9YSLBthaoMNDeOyuf6tFQ7D6gHlNFZyRu r5+BhuhbXs8DBu+d4cmPKnAocKa+RmgDd5PlkhN8Wnf1oOkh9rgO3mZR6C+U47pXGdkI CSo4k2GBC9tnlzbnIa2Gn/hrk20B7RwM9WU8gxd3XV5k7wjwEvVRV4aIfpVlIZt/7b9s ZkG3+Kv6HL7g+SGZzTb+pp3EaZc37u+M3d5TMX6CuAXKZrY4xAYc1wwDH1Tsk8iha7c1 1b/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=ECBUe5vj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id s21-20020a17090330d500b001b895a2c09esi8149347plc.381.2023.09.12.13.54.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 13:55:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=ECBUe5vj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id DFAA7813CDBD; Mon, 11 Sep 2023 21:11:51 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.8 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236346AbjILCHu (ORCPT + 99 others); Mon, 11 Sep 2023 22:07:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244253AbjILCHM (ORCPT ); Mon, 11 Sep 2023 22:07:12 -0400 Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E73E8CC35C; Mon, 11 Sep 2023 18:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1694482733; bh=e/MtnjLVSuAmechzlzx02wdSV0OA7qKD1FjdUlt9PcI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ECBUe5vjPPUgZ50JQeZl3PSxn/F2jWFEcsxaq9mfjSu0rMiU1jOK+UViwsd/soWE3 +g9hRTwnA6nCpkawy2NiUaGv5JirKBU3ONshMvi/hU7umoWKI92+98RijMAUg7vQjl S7nY6Klq2314F458vSisQKTHiYpcumy2N4tzU5WjQt0AxojLeCtK8ql0Nf2SKZnn4O 5NIz2NxzbfE+X/8FK+Px/Ew+I2LROeINhACxJV8QSNAoms+ScV4Luj8UeuuFBgR33e yPQWhXA+up+ntvi/riW6Xd8V1uTwNwV7ot0cs5DNNZ7x3kfDiHMOnR0ViUtCuWrcif rvroZw0ZVfwCw== Received: from [IPV6:2606:6d00:100:4000:cacb:9855:de1f:ded2] (unknown [IPv6:2606:6d00:100:4000:cacb:9855:de1f:ded2]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4Rl5pN6zdwz1PQV; Mon, 11 Sep 2023 21:38:52 -0400 (EDT) Message-ID: <60a9eee6-1f9c-f9c1-33bb-007e22437087@efficios.com> Date: Mon, 11 Sep 2023 21:40:14 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: [PATCH RFC] selftests/rseq: fix kselftest Clang build warnings Content-Language: en-US To: Justin Stitt Cc: Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Shuah Khan , Nathan Chancellor , Nick Desaulniers , Tom Rix , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, llvm@lists.linux.dev References: <20230908-kselftest-param_test-c-v1-1-e35bd9052d61@google.com> <1fae4a2f-eaf1-c54c-9ec5-040b2714709e@efficios.com> From: Mathieu Desnoyers In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 11 Sep 2023 21:11:52 -0700 (PDT) On 9/11/23 12:53, Justin Stitt wrote: > On Sat, Sep 9, 2023 at 5:37 AM Mathieu Desnoyers > wrote: >> >> On 9/8/23 19:03, Justin Stitt wrote: >>> Hi, >>> >>> I am experiencing many warnings when trying to build tools/testing/selftests. >>> >>> Here's one such example from rseq tree: >>> | param_test.c:1234:10: error: address argument to atomic operation must be a pointer to _Atomic type ('intptr_t *' (aka 'long *') invalid) >>> | 1234 | while (!atomic_load(&args->percpu_list_ptr)) {} >>> | | ^ ~~~~~~~~~~~~~~~~~~~~~~ >>> | /usr/local/google/home/justinstitt/repos/tc-build/build/llvm/final/lib/clang/18/include/stdatomic.h:140:29: note: expanded from macro 'atomic_load' >>> | 140 | #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST) >>> | | ^ ~~~~~~ >>> >>> I added the _Atomic type in various locations to silence _all_ (10) of these >>> warnings. I'm wondering, though, perhaps the absence of these _Atomic >>> types in the first place is on purpose? Am I on the right track to fix >>> these warnings without damaging the legitimacy of the tests at hand? >>> >>> I'd like some feedback about where to go from here and if others are >>> experiencing the same issues. Thanks! >>> >>> FWIW here's my specific build incantation on Clang-18 (49d41de57896e935cd5726719c5208bce22694ae): >>> $ make LLVM=1 -j128 ARCH=x86_64 mrproper headers defconfig kselftest-merge >>> $ make LLVM=1 ARCH=x86_64 -C tools/testing/selftests >> >> I should have used the __atomic_load_n() compiler builtin rather than >> atomic_load(), mainly because it does not require the _Atomic annotation >> to each type it touches. > > Would you like me to send a patch in with this change? Yes, please, although I suspect we'd want to turn atomic_store() into builtins as well. And use a release MO for stores, and acquire for loads. This should make validators like TSAN happier. Thanks, Mathieu > >> >> Thanks, >> >> Mathieu >> >> >>> >>> Link: https://github.com/ClangBuiltLinux/linux/issues/1698 >>> Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/61 >>> Signed-off-by: Justin Stitt >>> --- >>> tools/testing/selftests/rseq/param_test.c | 8 ++++---- >>> 1 file changed, 4 insertions(+), 4 deletions(-) >>> >>> diff --git a/tools/testing/selftests/rseq/param_test.c b/tools/testing/selftests/rseq/param_test.c >>> index bf951a490bb4..94802aeed2c6 100644 >>> --- a/tools/testing/selftests/rseq/param_test.c >>> +++ b/tools/testing/selftests/rseq/param_test.c >>> @@ -356,7 +356,7 @@ struct inc_thread_test_data { >>> }; >>> >>> struct percpu_list_node { >>> - intptr_t data; >>> + _Atomic intptr_t data; >>> struct percpu_list_node *next; >>> }; >>> >>> @@ -1212,8 +1212,8 @@ static int set_signal_handler(void) >>> /* Test MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU membarrier command. */ >>> #ifdef TEST_MEMBARRIER >>> struct test_membarrier_thread_args { >>> - int stop; >>> - intptr_t percpu_list_ptr; >>> + _Atomic int stop; >>> + _Atomic intptr_t percpu_list_ptr; >>> }; >>> >>> /* Worker threads modify data in their "active" percpu lists. */ >>> @@ -1240,7 +1240,7 @@ void *test_membarrier_worker_thread(void *arg) >>> int cpu = get_current_cpu_id(); >>> >>> ret = rseq_offset_deref_addv(RSEQ_MO_RELAXED, RSEQ_PERCPU, >>> - &args->percpu_list_ptr, >>> + (intptr_t*)&args->percpu_list_ptr, >>> sizeof(struct percpu_list_entry) * cpu, 1, cpu); >>> } while (rseq_unlikely(ret)); >>> } >>> >>> --- >>> base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c >>> change-id: 20230908-kselftest-param_test-c-1763b62e762f >>> >>> Best regards, >>> -- >>> Justin Stitt >>> >> >> -- >> Mathieu Desnoyers >> EfficiOS Inc. >> https://www.efficios.com >> -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com