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 X-Spam-Level: X-Spam-Status: No, score=-7.4 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08A4BC07E9C for ; Tue, 6 Jul 2021 14:39:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DA9F161380 for ; Tue, 6 Jul 2021 14:39:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232598AbhGFOmI (ORCPT ); Tue, 6 Jul 2021 10:42:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:34470 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232569AbhGFOmC (ORCPT ); Tue, 6 Jul 2021 10:42:02 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 6EDBB619B4; Tue, 6 Jul 2021 14:03:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1625580217; bh=SlVNiPbVwivuijrsvG9rmj7KMdvuRpGvNZME7KtyPLE=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=dWfAm7VKcJ8uQmZAof7gx5Uelo11PLuriPZYcIK4GYL5p1y5TioA4vtoBMx5nsz+m oN0cZelDqlNppqjqvLvsbfgavFhe/YQUlMBypxvww9q1ZQa+Mknon43OETnZ3wlZil mmDihmTprS+HqDQpz2n0KPrud4LIFF11CmGeOsXKAgwgk+evnNlbFblPezDSR47cG3 8v6xBdikj8t2p7BljGrdDMKZarxDV8RdQ665zqiUd/CHF0+lHwD07u3/Q8HgnJyn4s 3rdV7B7c37CYkKfjQyGrsPZvtOV0yiZF/O+pzXKS6TBMOy45EtJxovKtTCSTPrlkJz 8TotspibDvbRQ== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 3E6EC5C034D; Tue, 6 Jul 2021 07:03:37 -0700 (PDT) Date: Tue, 6 Jul 2021 07:03:37 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: Marco Elver , linux-kernel@vger.kernel.org Subject: Re: RCU vs data_race() Message-ID: <20210706140337.GZ4397@paulmck-ThinkPad-P17-Gen-1> Reply-To: paulmck@kernel.org References: <20210618204800.GK4397@paulmck-ThinkPad-P17-Gen-1> <20210620210127.GR4397@paulmck-ThinkPad-P17-Gen-1> <20210621133757.GS4397@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 06, 2021 at 12:33:04PM +0200, Peter Zijlstra wrote: > On Tue, Jul 06, 2021 at 10:44:46AM +0200, Marco Elver wrote: > > On Tue, 6 Jul 2021 at 10:00, Peter Zijlstra wrote: > > [...] > > > In that case, would not an explicit: data_debug(addr) call (implemented > > > by KASAN/KCSAN/whoever), which would report whatever knowledge they have > > > about that address, be even more useful? > > > > KCSAN/KASAN report data-races/memory errors as soon as they encounter > > them, but before they do, cannot give you any more than that (metadata > > if it exists, but not sure it can be interpreted in any useful way > > before an error occurs). > > > > But maybe I misunderstood. Is data_debug() meant to not return > > anything and instead just be a "fake access"? > > Mostly just print any meta data that you might have. Like who allocated > it, or which code touched it. I'm thinking KASAN/KCSAN need to keep > track of such stuff for when a violation is detected. > > If I understand Paul right; and there's a fair chance I didn't; I tihnk > the issue is that when RCU finds a double call_rcu() (or some other > fail), it has very little clue how we got there, and any addition > information might be useful. If it is a current reference, we know that reference is relevant. After all, if the structure is being passed to call_rcu(), then there better not not be something else referencing it right now. But the historical data you are (I think?) asking for might be completely irrelevant due to its having happened too long ago. Thanx, Paul