Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp3801855ybt; Tue, 23 Jun 2020 11:03:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwdjyt1YNF7F3h05s4MwykHTBaDGC1DbqvyN8xksfoL+6dYuT8GcUFCFUC9fbLA0ru/FI+P X-Received: by 2002:a17:906:d8bc:: with SMTP id qc28mr22637701ejb.167.1592935385436; Tue, 23 Jun 2020 11:03:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592935385; cv=none; d=google.com; s=arc-20160816; b=V0rwY9Ky0fcuj7kOaPtHzrE5/qin6y+YhyqGPZdF7CMFwf4qtMtyTsHuIquNcP7Y8B J6UtH7dMQ58YqQF94aa6tTLImTg8BNII+TmjRmYiMoKEHLxJvYbg+FDWW6QaPkXp0q2j fkmtUG6CugBONFiDwZAYWaNXyHkpk47mxA+hC+J5/ieUskd9KMz3QrpgmGE9HK2YBlAR IQ6AkN7t3jPHVrj838zEUzOjziGuxCm/HNGTSruzIthQ4lXNFm8wLHZp1jVNpSacbHD2 LiLy/cLsxauTffNG2XgFFAF80oAGAMXEUAb0UaA+k+oHgsC5Wx2h1Jez9alTubMWljK1 EbQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Wcyp7xJ9VH6Ce5YmoH+01qglUFlPRs0bPBHrFHPBGrU=; b=FN0Kc0AG7FXd8oUFRC0NR+XDkl87TcZDIqXNwde6UHUigdNM7KIFH0J4OsAY8mAWtw QRQ8+Kob6yT/m7TU0OqhbB6FYI6Zl2wsLAQUIG72H8AfjSz3kZvH9Ul7eyIah+MgjP1r 7+dWf/Lsi1j0t6xlOtO2C4ys5+XdwE4IqsBzrlFXUZfh5+JtAFUJ9ez7H2Es8rPS946S YJJv4cSKJBQ4ipSCZ6FJumhy+KV6WRumFEee5rYx0GtI2HHN12LIzZiCVrRwhvtx6Y3G R5xob6RqwzIBPSpVymm/BwnOP61ZlMqL9ez2nvm3GwJOVDuBJAJjsmQEwmi2lMtUmNvo KHMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=b0gWdjg9; 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 r25si6887135eja.340.2020.06.23.11.02.36; Tue, 23 Jun 2020 11:03:05 -0700 (PDT) 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=b0gWdjg9; 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 S1733149AbgFWSAG (ORCPT + 99 others); Tue, 23 Jun 2020 14:00:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58850 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733061AbgFWSAF (ORCPT ); Tue, 23 Jun 2020 14:00:05 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63EC9C061795 for ; Tue, 23 Jun 2020 11:00:05 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id o8so2042306wmh.4 for ; Tue, 23 Jun 2020 11:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Wcyp7xJ9VH6Ce5YmoH+01qglUFlPRs0bPBHrFHPBGrU=; b=b0gWdjg9shIjXDAXSuaxcUf0kvXH4yOK4YqHK+9dT9MEpAkVd6umkpXAERDfyobiWl iXYdhTzGdCZyETgQEnsKBMRw2uD1/6EG+a2gNOJxd+k6D/sDEhaX6N+anOTYiE5UTlEW 9guLzwsJbj9ourTGn7rQyP3RVBIwQBwAZ/LZZzmAPQobTh1G7a54oM7BKIaUVWVU7sYR 92sTnOH08HPqyhu7XVR11xnX2duZHFm8vCQNLqhX6EcurG9VD3S0w6GR/Cq7XgDKoDq9 1VJ29HZZZHA+0Um8K2+yTGYbKt5FDsWkltk1RndhkdGr1x6j4EAOX4DINZmI1bfl6Cvx oAyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Wcyp7xJ9VH6Ce5YmoH+01qglUFlPRs0bPBHrFHPBGrU=; b=kHTfJ2EVy/y0mo4/leTh8hfhoLbq+F7ofqT5PJ53DzJw+AARaATPMQrpfZDBRiZ7N0 ECWEZN2eF8QqHywSekhfdjYo15FK/OdPekLzIIa3HCWdGGZGIwdC3ix2jTyl+BxWZ+zx W+uK3vVaoFn/r+tBBMw6tjb0jkm78lU74wk1RjHhCjzCksCXlqHD5Gvo4HSykKhdSED7 Dl4UsGfrRhMhZmA4KVfaD+TqNn3rb8YqjkEaoTwdewotezV+iCEEoYqRv4YCVVHRRPGY 4BSE5ft0aa1Tts3x9wCaXE1UqbgZKC+KZF7Iy3idABGX/ElxEXgGShp4VDOOcvnhLKpF qNkA== X-Gm-Message-State: AOAM532NyueJgt9NEFlA5XYJEFzzT3W4WA8Z7MCva7u/UG81FSuTXXrw Vu0q9bCmuh7d2TcWJriEaifEAvKJt6CeOA== X-Received: by 2002:a7b:cb11:: with SMTP id u17mr25343911wmj.84.1592935203860; Tue, 23 Jun 2020 11:00:03 -0700 (PDT) Received: from elver.google.com ([100.105.32.75]) by smtp.gmail.com with ESMTPSA id r1sm22986260wrn.29.2020.06.23.11.00.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2020 11:00:03 -0700 (PDT) Date: Tue, 23 Jun 2020 19:59:57 +0200 From: Marco Elver To: Peter Zijlstra Cc: "Ahmed S. Darwish" , mingo@kernel.org, will@kernel.org, tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org, rostedt@goodmis.org, bigeasy@linutronix.de, davem@davemloft.net, sparclinux@vger.kernel.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, heiko.carstens@de.ibm.com, linux-s390@vger.kernel.org, linux@armlinux.org.uk Subject: Re: [PATCH v4 7/8] lockdep: Change hardirq{s_enabled,_context} to per-cpu variables Message-ID: <20200623175957.GA106514@elver.google.com> References: <20200623083645.277342609@infradead.org> <20200623083721.512673481@infradead.org> <20200623150031.GA2986783@debian-buster-darwi.lab.linutronix.de> <20200623152450.GM4817@hirez.programming.kicks-ass.net> <20200623161320.GA2996373@debian-buster-darwi.lab.linutronix.de> <20200623163730.GA4800@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200623163730.GA4800@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.13.2 (2019-12-18) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 23, 2020 at 06:37PM +0200, Peter Zijlstra wrote: > On Tue, Jun 23, 2020 at 06:13:21PM +0200, Ahmed S. Darwish wrote: > > Well, freshly merged code is using it. For example, KCSAN: > > > > => f1bc96210c6a ("kcsan: Make KCSAN compatible with lockdep") > > => kernel/kcsan/report.c: > > > > void kcsan_report(...) > > { > > ... > > /* > > * With TRACE_IRQFLAGS, lockdep's IRQ trace state becomes corrupted if > > * we do not turn off lockdep here; this could happen due to recursion > > * into lockdep via KCSAN if we detect a race in utilities used by > > * lockdep. > > */ > > lockdep_off(); > > ... > > } > > Marco, do you remember what exactly happened there? Because I'm about to > wreck that. That is, I'm going to make TRACE_IRQFLAGS ignore > lockdep_off(). Yeah, I was trying to squash any kind of recursion: lockdep -> other libs -> -> KCSAN -> print report -> dump stack, printk and friends -> lockdep -> other libs -> KCSAN ... Some history: * Initial patch to fix: https://lore.kernel.org/lkml/20200115162512.70807-1-elver@google.com/ * KCSAN+lockdep+ftrace: https://lore.kernel.org/lkml/20200214211035.209972-1-elver@google.com/ lockdep now has KCSAN_SANITIZE := n, but we still need to ensure that there are no paths out of lockdep, or the IRQ flags tracing code, that might lead through other libs, through KCSAN, libs used to generate a report, and back to lockdep. I never quite figured out the exact trace that led to corruption, but avoiding any kind of potential for recursion was the only thing that would avoid the check_flags() warnings. Thanks, -- Marco