linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Jessica Yu <jeyu@redhat.com>, Jiri Kosina <jikos@kernel.org>,
	Miroslav Benes <mbenes@suse.cz>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code
Date: Thu, 11 May 2017 15:52:46 +0200	[thread overview]
Message-ID: <20170511135246.GN3452@pathway.suse.cz> (raw)
In-Reply-To: <20170508151322.76e8e9db@gandalf.local.home>

On Mon 2017-05-08 15:13:22, Steven Rostedt wrote:
> On Mon, 8 May 2017 11:51:08 -0500
> Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
> > Another idea would be to figure out a way to stop using RCU in
> > klp_ftrace_handler() altogether.
> > 
> 
> That may work if rcu_enter_irq() doesn't. But that's how NMIs use rcu.

I am a bit confused by the above. Does it mean that RCU could not be
used in NMI handlers?


Anyway, a crazy idea is to use the livepatch consistency model instead
of RCU to protect the function stack. The model makes sure that all
tasks, including the idle ones, were not running any patched function
(and their ftrace handlers) at some point. It should be safe
but I am not sure if it is worth it.

Alternatively, it might be enough to use the probably more lightwight
solution that is used when ftrace handlers are deregistered, I mean:

	/*
	 * We need to do a hard force of sched synchronization.
	 * This is because we use preempt_disable() to do RCU, but
	 * the function tracers can be called where RCU is not watching
	 * (like before user_exit()). We can not rely on the RCU
	 * infrastructure to do the synchronization, thus we must do it
	 * ourselves.
	 */
	schedule_on_each_cpu(ftrace_sync);

	/*
	 * When the kernel is preeptive, tasks can be preempted
	 * while on a ftrace trampoline. Just scheduling a task on
	 * a CPU is not good enough to flush them. Calling
	 * synchornize_rcu_tasks() will wait for those tasks to
	 * execute and either schedule voluntarily or enter user space.
	 */
	if (IS_ENABLED(CONFIG_PREEMPT))
		synchronize_rcu_tasks();



Best  Regards,
Petr

  parent reply	other threads:[~2017-05-11 13:53 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04 10:55 [PATCH 0/3] livepatch/rcu: Handle some subtle issues between livepatching and RCU Petr Mladek
2017-05-04 10:55 ` [PATCH 1/3] livepatch/rcu: Guarantee consistency when patching idle kthreads Petr Mladek
2017-05-04 10:55 ` [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code Petr Mladek
2017-05-08 16:51   ` Josh Poimboeuf
2017-05-08 19:13     ` Steven Rostedt
2017-05-08 19:47       ` Josh Poimboeuf
2017-05-08 20:15         ` Paul E. McKenney
2017-05-08 20:43           ` Josh Poimboeuf
2017-05-08 20:51             ` Josh Poimboeuf
2017-05-08 21:08               ` Paul E. McKenney
2017-05-08 21:07             ` Paul E. McKenney
2017-05-08 21:18               ` Steven Rostedt
2017-05-08 21:30                 ` Paul E. McKenney
2017-05-08 22:16               ` Josh Poimboeuf
2017-05-08 22:36                 ` Paul E. McKenney
2017-05-09 16:18                   ` Josh Poimboeuf
2017-05-09 16:36                     ` Paul E. McKenney
2017-05-10 16:04                     ` Petr Mladek
2017-05-10 16:45                       ` Paul E. McKenney
2017-05-10 17:58                       ` Josh Poimboeuf
2017-05-11 12:40                         ` Miroslav Benes
2017-05-11 15:03                           ` Josh Poimboeuf
2017-05-08 21:16             ` Steven Rostedt
2017-05-08 20:18         ` Steven Rostedt
2017-05-11 12:50           ` Miroslav Benes
2017-05-11 13:52       ` Petr Mladek [this message]
2017-05-11 14:50         ` Paul E. McKenney
2017-05-11 15:27         ` Josh Poimboeuf
2017-05-11 12:44     ` Petr Mladek
2017-05-04 10:55 ` [PATCH 3/3] livepatch/rcu: Disable livepatch removal when safety is not guaranteed Petr Mladek
2017-05-04 16:55 ` [PATCH 0/3] livepatch/rcu: Handle some subtle issues between livepatching and RCU Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170511135246.GN3452@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=jeyu@redhat.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).