Re: [PATCH 2/2] rcu-tasks: add RCU-tasks self tests

From: Masami Hiramatsu <mhiramat@kernel.org>
To: Uladzislau Rezki <urezki@gmail.com>
Cc: paulmck@kernel.org,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>, RCU <rcu@vger.kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Andrew Morton <akpm@linux-foundation.org>,
	Daniel Axtens <dja@axtens.net>,
	Frederic Weisbecker <frederic@kernel.org>,
	Neeraj Upadhyay <neeraju@codeaurora.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Michal Hocko <mhocko@suse.com>,
	"Theodore Y . Ts'o" <tytso@mit.edu>,
	Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>,
	rostedt@goodmis.org
Subject: Re: [PATCH 2/2] rcu-tasks: add RCU-tasks self tests
Date: Thu, 18 Feb 2021 23:29:36 +0900	[thread overview]
Message-ID: <20210218232936.c3158cc304e13151484de3c2@kernel.org> (raw)
In-Reply-To: <20210218083636.GA2030@pc638.lan>

On Thu, 18 Feb 2021 09:36:36 +0100
Uladzislau Rezki <urezki@gmail.com> wrote:

> On Thu, Feb 18, 2021 at 02:03:07PM +0900, Masami Hiramatsu wrote:
> > On Wed, 17 Feb 2021 10:17:38 -0800
> > "Paul E. McKenney" <paulmck@kernel.org> wrote:
> > 
> > > > > 1.	Spawn ksoftirqd earlier.
> > > > > 
> > > > > 2.	Suppress attempts to awaken ksoftirqd before it exists,
> > > > > 	forcing all ksoftirq execution on the back of interrupts.
> > > > > 
> > > > > Uladzislau and I each produced patches for #1, and I produced a patch
> > > > > for #2.
> > > > > 
> > > > > The only other option I know of is to push the call to init_kprobes()
> > > > > later in the boot sequence, perhaps to its original subsys_initcall(),
> > > > > or maybe only as late as core_initcall().  I added Masami and Steve on
> > > > > CC for their thoughts on this.
> > > > > 
> > > > > Is there some other proper fix that I am missing?
> > > > 
> > > > Oh, I missed that the synchronize_rcu_tasks() will be involved the kprobes
> > > > in early stage. Does the problem only exist in the synchronize_rcu_tasks()
> > > > instead of synchronize_rcu()? If so I can just stop optimizer in early stage
> > > > because I just want to enable kprobes in early stage, but not optprobes.
> > > > 
> > > > Does the following patch help?
> > > 
> > > It does look to me like it would!  I clearly should have asked you about
> > > this a couple of months ago.  ;-)
> > > 
> > > The proof of the pudding would be whether the powerpc guys can apply
> > > this to v5.10-rc7 and have their kernel come up without hanging at boot.
> > 
> > Who could I ask for testing this patch, Uladzislau?
> > I think the test machine which enough slow or the kernel has much initcall
> > to run optimization thread while booting.
> > In my environment, I could not reproduce that issue because the optimizer
> > was sheduled after some tick passed. At that point, ksoftirqd has already
> > been initialized.
> > 
> From my end i did some simulation and had a look at your change. So the
> patch works on my setup. I see that optimization of kprobes is deferred
> and can be initiated only from the subsys_initcall() phase. So the sequence
> should be correct for v5.10-rc7:
> 
> 1. ksoftirq is setup early_initcall();

    also kprobe framework is initialized in early_initcall() and
    kprobes smoketest (register/unregister probes) executed.

> 2. rcu_spawn_tasks_* are setup in the core_initcall();

    and kprobe events are setup in core_initcall_sync() (via trace_boot);

> 3. an optimization of kprobes are invoked from subsys_initcall().

   At this point, all kprobes which can be optimized will be actually
   optimized.

> For real test on power-pc you can ask Daniel Axtens <dja@axtens.net> for help. 

OK, I'll CC to Daniel.

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>