Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp1430526ybd; Wed, 26 Jun 2019 17:50:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqxoBqZcXq9uPk7u8dGv7PlTj/dJ9PYYstHWP1gSs6bRa9TBui/86GFgIfQocND75IYjTD0N X-Received: by 2002:a17:90a:cb01:: with SMTP id z1mr2381236pjt.93.1561596601573; Wed, 26 Jun 2019 17:50:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561596601; cv=none; d=google.com; s=arc-20160816; b=s5dm4kdrN00UkDOCnOmRpCQtcqbZJZn0XmOh6POpYpZ+37zm24iIWOK0xIFYh44uhN /rnwsQrqe8Nxk65ESajvVOGQDVU5qfbm7nmzFMIm9s54ozGTgY+dbtw4dILO3KDFZ8/v olZ8CckJ2ZduBfum0groAIFIqe87bQYPvpdh/JnU94MmFNDFY7sRUg3Ard/Vr2jtzOZa PJ0SwC4WHlm8nYIC4yri++Zx0ZYNjV9CNg98FXw+PENWP0LKxrDpzvZF9WxQ33fpvUlB RyOOl5tGKtYVSTEK/oPtXf9TyMhSHnzt/qa0AHIn2xUaQp8hIt1KFgiqdQdI3+oko3cC 7t1g== 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; bh=QWHMCCxbMGRJxiNRO7qg9rm4h7VUE2TAGd9KVax+eBQ=; b=I/5Kj23+3E0iZCYsIp1Ee3L0SSjMePmIZwheJ+eMv98/Z5ciqIdGsMR1UnvIbVQc2l 2Mfv7l1zQSGfGZt6Sbb9VLMvrUa0kBcz11SlubgBxz8s0cIsNH84hfy8jl+L1Tw7aRGR 0sKq7eZCyD/5CI4x0k0nYIhy0kyc0QY3Kg9UMkKUFH0z//+XV1upJiQVc4uCekh5ZAK/ sD2mFBBQc0OjU/p0nrBHUwfImBjb4yK+UfOevianoJUHE7HR5JQMrLf/an9yDBalsPGw TbB2/dtKUIHm0KHpwNiEHgm9wQUUN7ctdDDxAdkt2L4n5MKnmPLmqX1wc7i6+184XufU V2dg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d7si531456pgq.211.2019.06.26.17.49.45; Wed, 26 Jun 2019 17:50:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728090AbfF0AtA (ORCPT + 99 others); Wed, 26 Jun 2019 20:49:00 -0400 Received: from lgeamrelo13.lge.com ([156.147.23.53]:55510 "EHLO lgeamrelo11.lge.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726862AbfF0As7 (ORCPT ); Wed, 26 Jun 2019 20:48:59 -0400 Received: from unknown (HELO lgeamrelo01.lge.com) (156.147.1.125) by 156.147.23.53 with ESMTP; 27 Jun 2019 09:48:56 +0900 X-Original-SENDERIP: 156.147.1.125 X-Original-MAILFROM: byungchul.park@lge.com Received: from unknown (HELO X58A-UD3R) (10.177.222.33) by 156.147.1.125 with ESMTP; 27 Jun 2019 09:48:56 +0900 X-Original-SENDERIP: 10.177.222.33 X-Original-MAILFROM: byungchul.park@lge.com Date: Thu, 27 Jun 2019 09:48:16 +0900 From: Byungchul Park To: "Paul E. McKenney" Cc: Joel Fernandes , josh@joshtriplett.org, rostedt@goodmis.org, mathieu.desnoyers@efficios.com, jiangshanlai@gmail.com, rcu@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@lge.com Subject: Re: [RFC] rcu: Warn that rcu ktheads cannot be spawned Message-ID: <20190627004816.GA7427@X58A-UD3R> References: <1561364852-5113-1-git-send-email-byungchul.park@lge.com> <20190624164624.GA41314@google.com> <20190624172551.GI26519@linux.ibm.com> <20190625024100.GA10912@X58A-UD3R> <20190625133115.GV26519@linux.ibm.com> <20190626025120.GA3452@X58A-UD3R> <20190626163045.GB26519@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190626163045.GB26519@linux.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 26, 2019 at 09:30:45AM -0700, Paul E. McKenney wrote: > On Wed, Jun 26, 2019 at 11:51:20AM +0900, Byungchul Park wrote: > > On Tue, Jun 25, 2019 at 06:31:15AM -0700, Paul E. McKenney wrote: > > > On Tue, Jun 25, 2019 at 11:41:00AM +0900, Byungchul Park wrote: > > > > On Mon, Jun 24, 2019 at 10:25:51AM -0700, Paul E. McKenney wrote: > > > > > On Mon, Jun 24, 2019 at 12:46:24PM -0400, Joel Fernandes wrote: > > > > > > On Mon, Jun 24, 2019 at 05:27:32PM +0900, Byungchul Park wrote: > > > > > > > Hello rcu folks, > > > > > > > > > > > > > > I thought it'd better to announce it if those spawnings fail because of > > > > > > > !rcu_scheduler_fully_active. > > > > > > > > > > > > > > Of course, with the current code, it never happens though. > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > It seems in the right spirit, but with your patch a warning always fires. > > > > > > rcu_prepare_cpu() is called multiple times, once from rcu_init() and then > > > > > > from hotplug paths. > > > > > > > > > > > > Warning splat stack looks like: > > > > > > > > > > > > [ 0.398767] Call Trace: > > > > > > [ 0.398775] rcu_init+0x6aa/0x724 > > > > > > [ 0.398779] start_kernel+0x220/0x4a2 > > > > > > [ 0.398780] ? copy_bootdata+0x12/0xac > > > > > > [ 0.398782] secondary_startup_64+0xa4/0xb0 > > > > > > > > > > Thank you both, and I will remove this from my testing queue. > > > > > > > > > > As Joel says, this is called at various points in the boot sequence, not > > > > > all of which are far enough along to support spawning kthreads. > > > > > > > > > > The real question here is "What types of bugs are we trying to defend > > > > > against?" But keeping in mind existing diagnostics. For example, are > > > > > there any kthreads for which a persistent failure to spawn would not > > > > > emit any error message. My belief is that any such persistent failure > > > > > would result in either an in-kernel diagnostic or an rcutorture failure, > > > > > but I might well be missing something. > > > > > > > > > > Thoughts? Or, more to the point, tests demonstrating silence in face > > > > > of such a persistent failure? > > > > > > > > You are right. There wouldn't be a persistent failure because the path > > > > turning cpus on always tries to spawn them, *even* in case that the > > > > booting sequence is wrong. The current code anyway goes right though. > > > > > > > > I thought a hole can be there if the code changes so that those kthreads > > > > cannot be spawned until the cpu being up, which is the case I was > > > > interested in. Again, it's gonna never happen with the current code > > > > because it spawns them after setting rcu_scheduler_fully_active to 1 in > > > > rcu_spawn_gp_kthead(). > > > > > > > > And I wrongly thought you placed the rcu_scheduler_fully_active check on > > > > spawning just in case. But it seems to be not the case. > > > > > > > > So I'd better stop working on the warning patch. :) Instead, please > > > > check the following trivial fix. > > > > > > > > Thanks, > > > > Byungchul > > > > > > > > ---8<--- > > > > >From 1293d19bb7abf7553d656c81182118eff54e7dc9 Mon Sep 17 00:00:00 2001 > > > > From: Byungchul Park > > > > Date: Mon, 24 Jun 2019 16:22:11 +0900 > > > > Subject: [PATCH] rcu: Make rcu_spawn_one_boost_kthread() return void > > > > > > > > The return value of rcu_spawn_one_boost_kthread() is not used any > > > > longer. Change the return type from int to void. > > > > > > > > Signed-off-by: Byungchul Park > > > > > > Looks pretty good, just one comment below. Plus could you please tell > > > me what you are developing this against? > > > > Only for removing out-dated code. Not for funcational change. > > I was actually expecting an answer of the form "current mainline", > "v5.2-rc3", "-rcu branch dev", or some such. If need be, I will ask > again for your next version. ;-) OMG. It was linux-rcu.git rcu/next. :( Thank you! Byungchul > > And simple answer below... > > > > > > > > Thanx, Paul > > > > > > > --- > > > > kernel/rcu/tree_plugin.h | 15 +++++++-------- > > > > 1 file changed, 7 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h > > > > index 1102765..4e11aa4 100644 > > > > --- a/kernel/rcu/tree_plugin.h > > > > +++ b/kernel/rcu/tree_plugin.h > > > > @@ -1131,7 +1131,7 @@ static void rcu_preempt_boost_start_gp(struct rcu_node *rnp) > > > > * already exist. We only create this kthread for preemptible RCU. > > > > * Returns zero if all is well, a negated errno otherwise. > > > > */ > > > > -static int rcu_spawn_one_boost_kthread(struct rcu_node *rnp) > > > > +static void rcu_spawn_one_boost_kthread(struct rcu_node *rnp) > > > > { > > > > int rnp_index = rnp - rcu_get_root(); > > > > unsigned long flags; > > > > @@ -1139,25 +1139,24 @@ static int rcu_spawn_one_boost_kthread(struct rcu_node *rnp) > > > > struct task_struct *t; > > > > > > > > if (!IS_ENABLED(CONFIG_PREEMPT_RCU)) > > > > - return 0; > > > > + return; > > > > > > > > if (!rcu_scheduler_fully_active || rcu_rnp_online_cpus(rnp) == 0) > > > > - return 0; > > > > + return; > > > > > > > > rcu_state.boost = 1; > > > > if (rnp->boost_kthread_task != NULL) > > > > - return 0; > > > > + return; > > > > t = kthread_create(rcu_boost_kthread, (void *)rnp, > > > > "rcub/%d", rnp_index); > > > > if (IS_ERR(t)) > > > > > > This would be a change in behavior, but it might be good to have a > > > WARN_ON_ONCE() above. Assuming that it doesn't splat on every boot. ;-) > > > > Yes. Normally it shouldn't. Right? I will resend this after testing with > > my machine. :) > > My guess is that it will not splat, but if it does, it would not be the > first time that RCU has surprised me. ;-) > > Thanx, Paul > > > Thanks, > > Byungchul > > > > > > > > > - return PTR_ERR(t); > > > > + return; > > > > raw_spin_lock_irqsave_rcu_node(rnp, flags); > > > > rnp->boost_kthread_task = t; > > > > raw_spin_unlock_irqrestore_rcu_node(rnp, flags); > > > > sp.sched_priority = kthread_prio; > > > > sched_setscheduler_nocheck(t, SCHED_FIFO, &sp); > > > > wake_up_process(t); /* get to TASK_INTERRUPTIBLE quickly. */ > > > > - return 0; > > > > } > > > > > > > > static void rcu_cpu_kthread_setup(unsigned int cpu) > > > > @@ -1265,7 +1264,7 @@ static void __init rcu_spawn_boost_kthreads(void) > > > > if (WARN_ONCE(smpboot_register_percpu_thread(&rcu_cpu_thread_spec), "%s: Could not start rcub kthread, OOM is now expected behavior\n", __func__)) > > > > return; > > > > rcu_for_each_leaf_node(rnp) > > > > - (void)rcu_spawn_one_boost_kthread(rnp); > > > > + rcu_spawn_one_boost_kthread(rnp); > > > > } > > > > > > > > static void rcu_prepare_kthreads(int cpu) > > > > @@ -1275,7 +1274,7 @@ static void rcu_prepare_kthreads(int cpu) > > > > > > > > /* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */ > > > > if (rcu_scheduler_fully_active) > > > > - (void)rcu_spawn_one_boost_kthread(rnp); > > > > + rcu_spawn_one_boost_kthread(rnp); > > > > } > > > > > > > > #else /* #ifdef CONFIG_RCU_BOOST */ > > > > -- > > > > 1.9.1 > > > > > >