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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 72C16C4332F for ; Tue, 5 Oct 2021 11:50:56 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2361261425 for ; Tue, 5 Oct 2021 11:50:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2361261425 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id A298A6B006C; Tue, 5 Oct 2021 07:50:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9D8D66B0071; Tue, 5 Oct 2021 07:50:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A15A900002; Tue, 5 Oct 2021 07:50:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id 7C6986B006C for ; Tue, 5 Oct 2021 07:50:55 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2E5B5180318E4 for ; Tue, 5 Oct 2021 11:50:55 +0000 (UTC) X-FDA: 78662217270.17.FC207DA Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by imf19.hostedemail.com (Postfix) with ESMTP id DFF53B000444 for ; Tue, 5 Oct 2021 11:50:54 +0000 (UTC) Received: by mail-oi1-f175.google.com with SMTP id w206so25844466oiw.4 for ; Tue, 05 Oct 2021 04:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZXyHYhWprLF6VOTKKbJ9elBPTHHvHE5sqZFrMqC4ukc=; b=AdpPxdZ9CqU5FBxAA98Y3fzXjRIpzwI+jLyQpXlS0B2Zag9lwe0Tm/W8yG54SJ9A9u ZloN1JllYx08BhPRvTu5lLeMVb90zvrbUzw51Q/oTdDElg8798X7vT7CKO7GyYUcONLE k9O1RUB4qxTUoeLEVIq3Grm6ll7KDg+JufpDII0qJIcg/GKTG35cmkQ5XWHVutEWOyV9 afmn3IVBAGabm9Ko1S1/pP/T924r2z5QRlfubG528dYb2KvZAfCV+7dPjVhxdNnppO46 HYvS1v3YPsVAuU8KqDjulvXw2WkI0lv0lSxJUhzjPCzS4XqZ3dFKVW9ScGGE+fi2AxGF NvfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZXyHYhWprLF6VOTKKbJ9elBPTHHvHE5sqZFrMqC4ukc=; b=H/OkUBnIXFoL94amHmK8hguTIVQorsIY4i/ElAOBu3LNUVF/nLN+rXEFUBLqnNZFZa Z2tepJ93p456auh3Y1kDvr6FdMAjy2GaZ8vaDbpkMydbM6WISvAzHZifiJtoZy3cD9OG Hyv4aGZ7yucYR2ZJyN296YcZs/o8az6H4WT882Zcp1C4Q7VKWAggGkhNLzPvqAXM/8sg efGhjWaVtat7wa+rwbgPvaUTC/m10ZpcOcuIbfy3C2OgYhlfgVdUyAcsDQN3SEm/Bl1/ N533xq/UQ2Fj20jCmoxB/b6u2v6nFXXdubOEYXtPNj+9fafVzxCNjfOE8nLzmWGY0Wa1 /vkA== X-Gm-Message-State: AOAM533su7Do3ecZFsi5SIKtVi3jHbmWjAbLpmcVwUzDbCQJjDpyT4lh pxe4I99Jii4ZM9XC5+rPKSkwBIYyZz/KL9bzCDQTHg== X-Google-Smtp-Source: ABdhPJxU3FVSA1SHRlaHXINF41V/Q42Bl2cBP1TOm69/Ej2eU70kaiasNkoR/CPckzvekLYzclXnlPHunaY5s8EHghQ= X-Received: by 2002:a54:4618:: with SMTP id p24mr2068916oip.134.1633434652953; Tue, 05 Oct 2021 04:50:52 -0700 (PDT) MIME-Version: 1.0 References: <20211005105905.1994700-1-elver@google.com> <20211005105905.1994700-6-elver@google.com> In-Reply-To: From: Marco Elver Date: Tue, 5 Oct 2021 13:50:41 +0200 Message-ID: Subject: Re: [PATCH -rcu/kcsan 05/23] kcsan: Add core memory barrier instrumentation functions To: Peter Zijlstra Cc: "Paul E . McKenney" , Alexander Potapenko , Boqun Feng , Borislav Petkov , Dmitry Vyukov , Ingo Molnar , Josh Poimboeuf , Mark Rutland , Thomas Gleixner , Waiman Long , Will Deacon , kasan-dev@googlegroups.com, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: DFF53B000444 X-Stat-Signature: dusz8si4qsn6873fpc6ztigr8bpdprah Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=AdpPxdZ9; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of elver@google.com designates 209.85.167.175 as permitted sender) smtp.mailfrom=elver@google.com X-HE-Tag: 1633434654-167978 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 5 Oct 2021 at 13:45, Peter Zijlstra wrote: > On Tue, Oct 05, 2021 at 01:41:18PM +0200, Peter Zijlstra wrote: > > On Tue, Oct 05, 2021 at 12:58:47PM +0200, Marco Elver wrote: > > > +static __always_inline void kcsan_atomic_release(int memorder) > > > +{ > > > + if (memorder == __ATOMIC_RELEASE || > > > + memorder == __ATOMIC_SEQ_CST || > > > + memorder == __ATOMIC_ACQ_REL) > > > + __kcsan_release(); > > > +} > > > + [...] > > > + kcsan_atomic_release(memorder); > > > __atomic_thread_fence(memorder); > > > } > > > EXPORT_SYMBOL(__tsan_atomic_thread_fence); > > > > I find that very hard to read.. kcsan_atomic_release() it not in fact a > > release. It might be a release if @memorder implies one. You're right, this name can be improved. `kcsan_atomic_builtin_memorder(..)` is probably better > Also, what's the atomic part signify? Is that because you're modeling > the difference in acquire/release semantics between > smp_load_{acquire,release}() and atomic*_{acquire,release}() ? Sorry, just a bad name. It's about the builtins. The above suggested name should hopefully be clearer.