Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp343352pxa; Fri, 21 Aug 2020 08:39:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzPjjC1AFYPupxAuDkhpoyCqCj6wIkgE+HQ9IJ32iqkNr7d0ixXDlKCBMDaYOBIe5O+4ikU X-Received: by 2002:aa7:c383:: with SMTP id k3mr3326813edq.164.1598024389202; Fri, 21 Aug 2020 08:39:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598024389; cv=none; d=google.com; s=arc-20160816; b=LR06DapVk7Ipjy93gejnzV4Y9foK6gLFeL9/XWndQnB6OfiBHqOysCHZ71a1Hb249G dmenau8qHQHzcEk3P25LJhCARU0u6dc9EUSjdTK78Kjy6tTVNXSwE2Tuz25H9nCcJnSh isDjuvdjgCbTVbBnAgSQ5ryChLvcGBtvyWJ9Bkj5RKA9nFtWXtpoM1uoBrSAA5LdFnZk qdw94pVj/A8B/qgZ6ehIkXg2kgmWivP/vpQZPVgE5mcklGbKRD7Y6OqczKBsmy0VZtLn 6zRIbQHspEIZxLv08ONnphWcE4lFl3ilLlZcS2I8SW15aCPmDUvjiQk9Kd/BYcqMmt7x QFbg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=+op96vDhjKN40iSpPOmu2wdLswFos3i2LMwSmwn2Zg8=; b=PIwxqLCBNIErFti2Dsu+Rk3QCC413gVP6YX4rEtyRUhM7IH6CWygSHWN12dZiHm7OC xSjtUSFr2ZHcosAhnOtoMyQogYq//rFLcan61msAGM+SNqlyV0W1x6fqwOyhmnfNxFK3 Uad3eB9EMQBYeUQKblNK12goPJoLRZIQlmrZfVHtTanCHYi+RiRMdJ3h8c0cIHqvulXK eP3PWOlK/WTE3/Oa0ni89yLCGDd8As6tRkiq7CVLOqD48JRu/vJeHDA8VSnhZVQi1PKX f3U9/I2mu5MBIs4vMIkv5iRnqlDSTBOqRsvwa5Gj5j5TSqfnqxhaZfBxQ3VyWLSqo519 1+Wg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t22si1431486ejy.433.2020.08.21.08.39.25; Fri, 21 Aug 2020 08:39:49 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728121AbgHUPij (ORCPT + 99 others); Fri, 21 Aug 2020 11:38:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:45392 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727829AbgHUPie (ORCPT ); Fri, 21 Aug 2020 11:38:34 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5EC872063A; Fri, 21 Aug 2020 15:38:33 +0000 (UTC) Date: Fri, 21 Aug 2020 11:38:31 -0400 From: Steven Rostedt To: Eric Dumazet Cc: Peter Zijlstra , Marco Elver , LKML , David Miller , Jakub Kicinski , netdev Subject: Re: [PATCH] random32: Use rcuidle variant for tracepoint Message-ID: <20200821113831.340ba051@oasis.local.home> In-Reply-To: References: <20200821063043.1949509-1-elver@google.com> <20200821085907.GJ1362448@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 21 Aug 2020 08:06:49 -0700 Eric Dumazet wrote: > On Fri, Aug 21, 2020 at 1:59 AM wrote: > > > > On Fri, Aug 21, 2020 at 08:30:43AM +0200, Marco Elver wrote: > > > With KCSAN enabled, prandom_u32() may be called from any context, > > > including idle CPUs. > > > > > > Therefore, switch to using trace_prandom_u32_rcuidle(), to avoid various > > > issues due to recursion and lockdep warnings when KCSAN and tracing is > > > enabled. > > > > At some point we're going to have to introduce noinstr to idle as well. > > But until that time this should indeed cure things. > > I do not understand what the issue is. This _rcuidle() is kind of opaque ;) kasan can be called when RCU is not "watching". That is, in the idle code, RCU will stop bothering idle CPUs by checking on them to move along the grace period. Just before going to idle, RCU will just set that its in a quiescent state. The issue is, after RCU has basically shutdown, and before getting to where the CPU is "sleeping", kasan is called, and kasan call a tracepoint. The problem is that tracepoints are protected by RCU. If RCU has shutdown, then it loses the protection. There's code to detect this and give a warning. All tracepoints have a _rcuidle() version. What this does is adds a little bit more overhead to the tracepoint when enabled to check if RCU is watching or not. If it is not watching, it tells RCU to start watching again while it runs the tracepoint, and afterward it lets RCU know that it can go back to not watching. > > Would this alternative patch work, or is it something more fundamental ? As I hope the above explained. The answer is "no". -- Steve > > Thanks ! > > diff --git a/lib/random32.c b/lib/random32.c > index 932345323af092a93fc2690b0ebbf4f7485ae4f3..17af2d1631e5ab6e02ad1e9288af7e007bed6d5f > 100644 > --- a/lib/random32.c > +++ b/lib/random32.c > @@ -83,9 +83,10 @@ u32 prandom_u32(void) > u32 res; > > res = prandom_u32_state(state); > - trace_prandom_u32(res); > put_cpu_var(net_rand_state); > > + trace_prandom_u32(res); > + > return res; > } > EXPORT_SYMBOL(prandom_u32);