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 874A2C4332F for ; Tue, 5 Oct 2021 12:17:09 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 260916117A for ; Tue, 5 Oct 2021 12:17:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 260916117A 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 B43DC940008; Tue, 5 Oct 2021 08:17:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AF46B6B0074; Tue, 5 Oct 2021 08:17:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 994FF940008; Tue, 5 Oct 2021 08:17:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0064.hostedemail.com [216.40.44.64]) by kanga.kvack.org (Postfix) with ESMTP id 8CC836B0073 for ; Tue, 5 Oct 2021 08:17:08 -0400 (EDT) Received: from smtpin40.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 47BC62C6BB for ; Tue, 5 Oct 2021 12:17:08 +0000 (UTC) X-FDA: 78662283336.40.A5825B7 Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) by imf23.hostedemail.com (Postfix) with ESMTP id 020539000382 for ; Tue, 5 Oct 2021 12:17:07 +0000 (UTC) Received: by mail-ot1-f51.google.com with SMTP id l16-20020a9d6a90000000b0053b71f7dc83so25551478otq.7 for ; Tue, 05 Oct 2021 05:17:07 -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=Qtirudvd3CXF1rYRgKYcpMfzejgCL2epG1sP1VQEe9s=; b=KTwb/ogrtt/E591H/tN/VTYlhqrR9Vl5tddsqaZzE0kkrXYzv/GX8tid0+F3lr5qQq yPWVTg2B314ddDgSwSevNhKAu64R7YWiSygh+c8h3Asl4LsYrFegO/B6AISMwFJ6D8Vr XRXfMMIK8QWdqX+E7w/eSWk7FDRpKdoGDgzRD0PpaXqgSjJuzh6nSIptpD4f/Bs/ztSK 2TK//39Gd5LVxzA5kd9wKdOxiLO1a+l5Db/we0xTTygfsehseuN2h/z0vzxEdg7X2hEt 0wvhmExP39oZanRDPHEP3T1fKkhGJjnqPf1v/7cFh+00IaE9+I2+0LRHTzwjraO4OnYR TByA== 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=Qtirudvd3CXF1rYRgKYcpMfzejgCL2epG1sP1VQEe9s=; b=exrjEfQWzr1Ei1bk0OBCY/J7SDUh4n3J1esg1kD+i6HyOOSLyHoGNjryQy4GCrljBx eMxl3fxsIgbTl1Qev9dUtxyrndYlw5feh7PHHnMpwjCBDeZYl3ljoFCs7/jIYUzXfdSf W/PUvYQPJr8aQFVSY9T7aUcMvf64OWkkB14yp190LWvOeWnwsWlMmmKo05/aT4Ma9ZhQ MeTN2BqzgBin61lOoGIQ1JaaqAV2tj/Q2ZHnEyouL54nzJCONIhPa6g+MY/eijO1GmI5 yNfDKOoBWl3RnZ4ESzaYimqf+v6KM7HWl2+htXm1KC/qtqUUOWVwtfOFFSMhs65PuNBo 4GGQ== X-Gm-Message-State: AOAM531VdfecZKv/ZczS/kfMQsgRoXc6TWBbsXmoeWomM34+3J33J6wr /dAp9yWS7/8GL97oBJN39GGYho6DfyFs9VSp5XhnXg== X-Google-Smtp-Source: ABdhPJwjDgxSZtLpmCXXe/rrN8LcDZxzExGHH2uRskhVorKYUt+/6c8rdV+/ZTp3iqUz8WZjpWJJNavoVIUkrlZN2QA= X-Received: by 2002:a9d:3e04:: with SMTP id a4mr14216116otd.329.1633436226924; Tue, 05 Oct 2021 05:17:06 -0700 (PDT) MIME-Version: 1.0 References: <20211005105905.1994700-1-elver@google.com> <20211005105905.1994700-17-elver@google.com> In-Reply-To: From: Marco Elver Date: Tue, 5 Oct 2021 14:16:55 +0200 Message-ID: Subject: Re: [PATCH -rcu/kcsan 16/23] locking/atomics, kcsan: Add instrumentation for barriers 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: rspam05 X-Rspamd-Queue-Id: 020539000382 X-Stat-Signature: eba5r9b6jnsifhbcb11hoxi5dys56no8 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="KTwb/ogr"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of elver@google.com designates 209.85.210.51 as permitted sender) smtp.mailfrom=elver@google.com X-HE-Tag: 1633436227-355062 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 14:03, Peter Zijlstra wrote: > > On Tue, Oct 05, 2021 at 12:58:58PM +0200, Marco Elver wrote: > > @@ -59,6 +60,7 @@ atomic_add(int i, atomic_t *v) > > static __always_inline int > > atomic_add_return(int i, atomic_t *v) > > { > > + kcsan_mb(); > > instrument_atomic_read_write(v, sizeof(*v)); > > return arch_atomic_add_return(i, v); > > } > > This and others,.. is this actually correct? Should that not be > something like: > > kscan_mb(); > instrument_atomic_read_write(...); > ret = arch_atomic_add_return(i, v); > kcsan_mb(); > return ret; > > ? In theory, yes, but right now it's redundant. Because right now KCSAN only models "buffering", and no "prefetching". So there's no way that a later instruction would be reordered before this point. And atomic accesses are never considered for reordering, so it's also impossible that it would be reordered later. Each kcsan_mb() is a call, so right now it makes sense to just have 1 call to be a bit more efficient.