Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp2347361pxu; Mon, 7 Dec 2020 04:27:33 -0800 (PST) X-Google-Smtp-Source: ABdhPJy6GNCrK9Dg1LlIOO1GGV2EKVkAtzb7328oTvbfKlU5p8atyDtowoNtsdWOBg6LC9g9jkn5 X-Received: by 2002:aa7:dac5:: with SMTP id x5mr20072852eds.198.1607344053003; Mon, 07 Dec 2020 04:27:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607344052; cv=none; d=google.com; s=arc-20160816; b=egTtXlGzALclRioHbHBpdcRoaUpToWCNNU+luMb63+QMh3hXjjeJvmyIKYVq8erS3p 0pyih8CiNRZdDiGqalmyH+HR+G7BSys8EdN3eW+MM1b+oWLT7ebAUuOSQ8bGTQBo/HD2 WeJ1QAKimwZ6m7ICVMhQnjxrgWxOxh1dyGsOu3JAd09eeC7ixqgNZk4nX624yLppVOHy Gn8KQKOYs8/24/Am2XYGN6rdkMR47GUt2EI5j+pkqgpUs3HHRzcuNP5GRwuV+Tb6ddH3 ge+5Xr0amypunuM104t8EGIwMwGEv5/BkVtIwnZObHF8/GZ6QcyomIEZFL4ynZ/CggCd Bnaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=E6pk4jhfaBDxagsrjqdb98OOZTNvh3pSgPws7wibwpo=; b=dAlcknp3hdPVb+J5unTRvVvGwW1lZ1YdtO01Pt9d9dD0rCJjRkEsrGPIl+5JHrEqBv bVtPp0XNLlNT+JDKq6qLkLKOjI+hHjP1S7dCITnuhsGRbkoHZYrzcvDfaehXrv+fOau/ jVLoL18GsggdsYhbzgqJJpzvCaVtERSMsfd81WZFc7tKUKNiV3RwWD0JDPIR4TewXK1F EiUDaPtcEPSEMKzuTwLTkczVPSkmWQ7DN2BnwgwWaNgSUXcwLoOuN/I+0J8H9WL3k1Om QP8m09wOiV5E0fm3ZhCl3PiUB8BPAwQmCRL24LmetIKdBKcfXrHMJKecxxUf0wnngJGc By9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="b/Javx/Y"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z6si6073325ejw.244.2020.12.07.04.27.09; Mon, 07 Dec 2020 04:27:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="b/Javx/Y"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727553AbgLGMYY (ORCPT + 99 others); Mon, 7 Dec 2020 07:24:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48770 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727505AbgLGMYY (ORCPT ); Mon, 7 Dec 2020 07:24:24 -0500 Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD440C0613D1 for ; Mon, 7 Dec 2020 04:23:37 -0800 (PST) Received: by mail-ot1-x341.google.com with SMTP id o11so9557917ote.4 for ; Mon, 07 Dec 2020 04:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E6pk4jhfaBDxagsrjqdb98OOZTNvh3pSgPws7wibwpo=; b=b/Javx/Yso5ETEG1DyHBm95cEnc1pUIgVv1H2AJva36lbgk43gZb16ZvdcRcUTnLud b5iEOhXaTFCR3ZSOlhZLS0yhJdJy3zyssHm9MiqV67y1moqxd8392AB3tUo3GSropJ0g XepIRQyg03EgSZlWraWQgMFWab4oIeEpD8LyMhT9tazpjWTeqn6NJPUs7am/MPWZYL7A QPV0Nd8CfztiThSkiKTUbVtfcN2ZY1WWOxTIuiSFdeaenOUFuujh7/ujtDmbi6PH1WBL jtnwjjRnEwl0LIKdI6TfbKxQAQET9iKeEgH1+HkQilE7H0XkdFMnXCPTSoyJ6+eGx9c/ wO0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E6pk4jhfaBDxagsrjqdb98OOZTNvh3pSgPws7wibwpo=; b=d4U9QE5EkN2/tQtPxV/qDYP9/2raHc4clZ1irHOaYLrsInzWGcJzOM7secTVjZA9So BFwVrSLMtSzQgoRypNFYZBFnAA7yHmCghjo0pcngBywfom8UR5rzRpHRQUA7BI8swJF5 JUK1z0987RqXxVLI873v3AJkPK3iClBIwZenR05EiMkcQs37bBlAZJgyyzyN5I1Hm2g2 1mPi8Koa3SmhOV7IBdxbJ8yQu5QK/hoW+fqmdU43NJDocZMXYZhUcdWlY+Sk47ZJftfn Ln/W7rX2PsKPSLpT6/YSukBWFFEURjT1xZYU19GdNi8oC8yaUzTnPatobGRvmlQTe61e WxNQ== X-Gm-Message-State: AOAM533AJd7W6mrPSpEJK1sphw3Iusc/fYdJE3oaiJZl5eQ/jvoQbtzt 6TnvXD4TK1CsyyoKSTDGM5HF30B34KuQHSXoXioXOA== X-Received: by 2002:a9d:6317:: with SMTP id q23mr13034529otk.251.1607343816907; Mon, 07 Dec 2020 04:23:36 -0800 (PST) MIME-Version: 1.0 References: <87wnxw86bv.fsf@nanos.tec.linutronix.de> <87eek395oe.fsf@nanos.tec.linutronix.de> In-Reply-To: <87eek395oe.fsf@nanos.tec.linutronix.de> From: Marco Elver Date: Mon, 7 Dec 2020 13:23:25 +0100 Message-ID: Subject: Re: BUG: KCSAN: data-race in tick_nohz_next_event / tick_nohz_stop_tick To: Thomas Gleixner Cc: Naresh Kamboju , open list , kasan-dev , rcu@vger.kernel.org, lkft-triage@lists.linaro.org, Peter Zijlstra , "Paul E. McKenney" , Ingo Molnar , fweisbec@gmail.com, Arnd Bergmann , Dmitry Vyukov , linux-toolchains@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 6 Dec 2020 at 00:47, Thomas Gleixner wrote: > On Sat, Dec 05 2020 at 19:18, Thomas Gleixner wrote: > > On Fri, Dec 04 2020 at 20:53, Marco Elver wrote: > > It might be useful to find the actual variable, data member or whatever > > which is involved in the various reports and if there is a match then > > the reports could be aggregated. The 3 patterns here are not even the > > complete possible picture. > > > > So if you sum them up: 58 + 148 + 205 instances then their weight > > becomes more significant as well. > > I just looked into the moderation queue and picked stuff which I'm > familiar with from the subject line. We managed to push (almost) everything that was still in private moderation to public moderation, so now there's even more to look at: https://syzkaller.appspot.com/upstream?manager=ci2-upstream-kcsan-gce :-) > There are quite some reports which have a different trigger scenario, > but are all related to the same issue. > > https://syzkaller.appspot.com/bug?id=f5a5ed5b2b6c3e92bc1a9dadc934c44ee3ba4ec5 > https://syzkaller.appspot.com/bug?id=36fc4ad4cac8b8fc8a40713f38818488faa9e9f4 > > are just variations of the same problem timer_base->running_timer being > set to NULL without holding the base lock. Safe, but insanely hard to > explain why :) > > Next: > > https://syzkaller.appspot.com/bug?id=e613fc2458de1c8a544738baf46286a99e8e7460 > https://syzkaller.appspot.com/bug?id=55bc81ed3b2f620f64fa6209000f40ace4469bc0 > https://syzkaller.appspot.com/bug?id=972894de81731fc8f62b8220e7cd5153d3e0d383 > ..... > > That's just the ones which caught my eye and all are related to > task->flags usage. There are tons more judging from the subject > lines. > > So you really want to look at them as classes of problems and not as > individual scenarios. Regarding auto-dedup: as you suggest, it'd make this straightforward if we had the variable name -- it turns out that's not so trivial. I think we need compiler support for that, or is there some existing infrastructure that can just tell us the canonical variable name if it points into a struct or global? For globals it's fine, but for arbitrary pointers that point into structs, I don't see how we could do it without compiler support e.g. mapping PC->variable name (we need to map instructions back to the variable names they access). Any precedence for this? [+Cc linux-toolchains@vger.kernel.org] Thanks, -- Marco