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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 828A6C433EF for ; Mon, 6 Dec 2021 07:54:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0A2236B007B; Mon, 6 Dec 2021 02:54:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 051FF6B007D; Mon, 6 Dec 2021 02:54:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E34EF6B007E; Mon, 6 Dec 2021 02:54:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay035.a.hostedemail.com [64.99.140.35]) by kanga.kvack.org (Postfix) with ESMTP id D41356B007B for ; Mon, 6 Dec 2021 02:54:11 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 08F6F2061C for ; Mon, 6 Dec 2021 07:16:24 +0000 (UTC) X-FDA: 78886511088.01.A1D41DB Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by imf14.hostedemail.com (Postfix) with ESMTP id A3DE86001990 for ; Mon, 6 Dec 2021 07:16:23 +0000 (UTC) Received: by mail-oi1-f175.google.com with SMTP id q25so19979767oiw.0 for ; Sun, 05 Dec 2021 23:16:23 -0800 (PST) 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=kMt90pKBGW/au5Bipth7kSeTJYiTzTjqmOMqmPuidYA=; b=XEkNxxxqqg+NZL/6yCqEZBN2SeXMqSO5LfwtQ38GYELUORg3SUHVW8Q5aVqB7bhGqn P4iX/WHdPtE2QjtkMfpoDJLQXNyPbDZrMsykHhDPapvSd5QU7F3VliQV9Yy6W3/x1/yp SPQHl5+NAMtC+/KeBPgVEFMP73nHOjUip8Pe4dz+ysEDvSgMxniak2Xxhya2c2DVmQoB PAasdNsXl2mjxk6waC9R44KBY4SXaQNbBsyaROg55cDONmTVDVBc7DjWKqjzSswf44xw uR5reE0LtjENxNpcjPtWEzqZ5Ub/3t0LHAu34RONtIOSh3hnK5gcV77ZKBM4aWABzWMB VIWw== 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=kMt90pKBGW/au5Bipth7kSeTJYiTzTjqmOMqmPuidYA=; b=jCtekXqhg6F0vcW/BiDZHrgHlgrNQEV/fSnXiLllvF/aPBolRRYTsckGRZLap/viO5 0zAv7k1EOvK6kLF1c12qaeC9XHY+CG3GHNPGiDK9bgTMUhg+SMvHYIC3/K4GRbw0VkWZ mbU1SXwMtf4kcdgkJoNFH+3VvdDAhLelwqJg3vYxxQCJvHWt9GCy9Votsi5jBWwsX0NU bVal+rSlpoaWlpd0YzG4HWdrSgzEPb7xg9lyQeocIQEN6osfIYgm6vRtfidkNNZ0Islx aOBkQOCXLPJ1v4PaCHkozJ5QOcy4SZVneOzTJ+DrDZ0ps5Usx4ocCB9edArLCOmnj8YN qcqw== X-Gm-Message-State: AOAM533wNhYnXRTuo+sHwBBGqlaXT9JkxTnFslTJiwPYxNI8Zpp83kWu 0aELMKLDrgE+0rJwLy1lU2YEO01v355iLjV1fGht/w== X-Google-Smtp-Source: ABdhPJwuGLpnUIDTjpBX3F4eSh7hJt4tJrtZLc3E+7J6kt6gm5BiWZwD1+kzTVPh5ygzYL7/rFy9FoV52gjMqiSEDPo= X-Received: by 2002:aca:af50:: with SMTP id y77mr22543199oie.134.1638774982675; Sun, 05 Dec 2021 23:16:22 -0800 (PST) MIME-Version: 1.0 References: <20211130114433.2580590-1-elver@google.com> <20211130114433.2580590-9-elver@google.com> In-Reply-To: From: Marco Elver Date: Mon, 6 Dec 2021 08:16:11 +0100 Message-ID: Subject: Re: [PATCH v3 08/25] kcsan: Show location access was reordered to To: Boqun Feng Cc: "Paul E. McKenney" , Alexander Potapenko , Borislav Petkov , Dmitry Vyukov , Ingo Molnar , Mark Rutland , Peter Zijlstra , 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, llvm@lists.linux.dev, x86@kernel.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: bq3wh8qth6gcwecstbaehbncnp9docqi Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=XEkNxxxq; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of elver@google.com designates 209.85.167.175 as permitted sender) smtp.mailfrom=elver@google.com X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: A3DE86001990 X-HE-Tag: 1638774983-150065 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 Mon, 6 Dec 2021 at 06:04, Boqun Feng wrote: > > Hi, > > On Tue, Nov 30, 2021 at 12:44:16PM +0100, Marco Elver wrote: > > Also show the location the access was reordered to. An example report: > > > > | ================================================================== > > | BUG: KCSAN: data-race in test_kernel_wrong_memorder / test_kernel_wrong_memorder > > | > > | read-write to 0xffffffffc01e61a8 of 8 bytes by task 2311 on cpu 5: > > | test_kernel_wrong_memorder+0x57/0x90 > > | access_thread+0x99/0xe0 > > | kthread+0x2ba/0x2f0 > > | ret_from_fork+0x22/0x30 > > | > > | read-write (reordered) to 0xffffffffc01e61a8 of 8 bytes by task 2310 on cpu 7: > > | test_kernel_wrong_memorder+0x57/0x90 > > | access_thread+0x99/0xe0 > > | kthread+0x2ba/0x2f0 > > | ret_from_fork+0x22/0x30 > > | | > > | +-> reordered to: test_kernel_wrong_memorder+0x80/0x90 > > | > > Should this be "reordered from" instead of "reordered to"? For example, > if the following case needs a smp_mb() between write to A and write to > B, I think currently it will report as follow: > > foo() { > WRITE_ONCE(A, 1); // let's say A's address is 0xaaaa > bar() { > WRITE_ONCE(B, 1); // Assume B's address is 0xbbbb > // KCSAN find the problem here > } > } > > > | write (reordered) to 0xaaaa of ...: > | bar+0x... // address of the write to B > | foo+0x... // address of the callsite to bar() > | ... > | | > | +-> reordered to: foo+0x... // address of the write to A > > But since the access reported here is the write to A, so it's a > "reordered from" instead of "reordered to"? Perhaps I could have commented on this in the commit message to avoid the confusion, but per its updated comment replace_stack_entry() "skips to the first entry that matches the function of @ip, and then replaces that entry with @ip, returning the entries to skip with @replaced containing the replaced entry." When a reorder_access is set up, the ip to it is stored, which is what's passed to @ip of replace_stack_entry(). It effectively swaps the top frame where the race occurred with where the original access happened. This all works because the runtime is careful to only keep reorder_accesses valid until the original function where it occurred is left. So in your above example you need to swap "reordered to" and the top frame of the stack trace. The implementation is a little trickier of course, but I really wanted the main stack trace to look like any other non-reordered access, which starts from the original access, and only have the "reordered to" location be secondary information. The foundation for doing this this was put in place here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6c65eb75686f Thanks, -- Marco