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 89F27C433EF for ; Mon, 29 Nov 2021 14:43:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E495B6B00A2; Mon, 29 Nov 2021 09:43:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E20C96B00A4; Mon, 29 Nov 2021 09:43:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CC1D56B00A5; Mon, 29 Nov 2021 09:43:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay030.a.hostedemail.com [64.99.140.30]) by kanga.kvack.org (Postfix) with ESMTP id BDC846B00A2 for ; Mon, 29 Nov 2021 09:43:27 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 91C602033A for ; Mon, 29 Nov 2021 14:43:16 +0000 (UTC) X-FDA: 78862235382.01.526CF05 Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) by imf11.hostedemail.com (Postfix) with ESMTP id 4F215F0000BE for ; Mon, 29 Nov 2021 14:43:12 +0000 (UTC) Received: by mail-oi1-f179.google.com with SMTP id o4so34963217oia.10 for ; Mon, 29 Nov 2021 06:43:12 -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=3mz1HPmHbMNrW+p+9eQAxOprfgUAji2Y3fPOhA732u0=; b=UYFA5+Kj7tvA2GXd53dZLzAwlSi6l7w/hTEzJ3H8A+QSaBrwkIe8WweXjIbXj3BELl eEBahNbVY5hxEA+m1Zsm/zHAH7vuo7iO9Gl/UAaFYO0N+uctB9MXeGvMxWld668gE72X ZpkrPa3wLVOeRFpp9PUS3nuus8d3b2MdtaCDRllfNTF1MiJRcjnyweEdXOB+gejWKaba rstv4lNGXUjQ1y0SH14O3YJdiUm9YqCn1bXP5QKKI+H7z3Pivs8/wkzEzplwbBGSVRfD q6IFlC/cNjnDA+eV1n9jQaWwaWtoxvLRocDUtogezJf9caNQXvpLif2bT2/FBaAkE/GO 4eeg== 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=3mz1HPmHbMNrW+p+9eQAxOprfgUAji2Y3fPOhA732u0=; b=m8kFcumGYnOpUrcV6i39uC+bouqlpCipNm3bM1xQr14Fw6FPQoInhb92XkDMPM6fY7 tDFKePqr8SOK1z8VDCV6kEvpzuw3Uxl/M6h3vFXW5ZPzaZ6D7Rrzp9Vo2ZjkQzeFEH2M A4BiK2xpNf7zhhrUJCpA5pcIIuMz/YaDIIa975mEYXddM4U+kyBXmvdmsYTcckcQefsT 6qbdbCBbzUvJWhWtH5NlpmT80Az1I33xmNVojW+XD+qPYizxRs2Kil+70Tm0zaWZHnoj rFmdu6UOqf+7/SewkCQmYzy+dNmq1BcXJnFujp7idTJCyiCXh1fGWRGvCImLfz2KFJnI 1f4Q== X-Gm-Message-State: AOAM530sOPuomCLaAz1oXERmUGgo1ObhvqXHvHM+3iH3BzfEkeXEIyHA 1WAQRTWoC5si/W7sKIRHbJfgDu9/SYYIpOUtXdrcow== X-Google-Smtp-Source: ABdhPJxzBms38b97VrAR+iOn0cM/VBioe+AWcYnISh3nXwb94CqvfvGOQZiwp9KrhWts1M5WTIvE6H8tN6RT2BjBeuQ= X-Received: by 2002:a05:6808:1903:: with SMTP id bf3mr41684658oib.7.1638196991401; Mon, 29 Nov 2021 06:43:11 -0800 (PST) MIME-Version: 1.0 References: <20211118081027.3175699-1-elver@google.com> <20211118081027.3175699-4-elver@google.com> In-Reply-To: From: Marco Elver Date: Mon, 29 Nov 2021 15:42:59 +0100 Message-ID: Subject: Re: [PATCH v2 03/23] kcsan: Avoid checking scoped accesses from nested contexts To: Boqun Feng Cc: "Paul E. McKenney" , Alexander Potapenko , Borislav Petkov , Dmitry Vyukov , Ingo Molnar , Josh Poimboeuf , 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, x86@kernel.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 4F215F0000BE X-Stat-Signature: jxgh6473879tbwjr4jrwypqjte69ppo5 Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UYFA5+Kj; spf=pass (imf11.hostedemail.com: domain of elver@google.com designates 209.85.167.179 as permitted sender) smtp.mailfrom=elver@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1638196992-626815 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, 29 Nov 2021 at 15:27, Boqun Feng wrote: [...] > > This case is also possible: > > > > static int v; > > static int x; > > int foo(..) > > { > > ASSERT_EXCLUSIVE_ACCESS_SCOPED(v); > > x++; // preempted during watchpoint for 'v' after checking x++ > > } > > > > Here, all we need is for the scoped access to be checked after x++, end > > up with a watchpoint for it, then enter scheduler code, which then > > checked 'v', sees the conflicting watchpoint, and reports a nonsensical > > race again. > > > > Just to be clear, in both examples, the assumption is that 'v' is a > variable that scheduler code doesn't access, right? Because if scheduler > code does access 'v', then it's a problem that KCSAN should report. Yes, > I don't know any variable that scheduler exports, just to make sure > here. Right. We might miss such cases where an ASSERT_EXCLUSIVE*_SCOPED() could have pointed out a legitimate race with a nested context that share ctx, like in scheduler, where the only time to detect it is if some state change later in the scope makes a concurrent access possible from that point in the scope. I'm willing to bet that there's an extremely small chance we'll ever encounter such a case (famous last words ;-)), i.e. the initial check_access() in kcsan_begin_scoped_access() wouldn't detect it nor would the problem manifest as a regular data race. Thanks, -- Marco