linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Petr Mladek <pmladek@suse.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Jessica Yu <jeyu@redhat.com>, Jiri Kosina <jikos@kernel.org>,
	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 14:40:42 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LSU.2.20.1705111436420.20501@pobox.suse.cz> (raw)
In-Reply-To: <20170510175831.avyrvguhi3zewnaq@treble>


Being somewhat late to the party I missed all the fun...

On Wed, 10 May 2017, Josh Poimboeuf wrote:

> On Wed, May 10, 2017 at 06:04:23PM +0200, Petr Mladek wrote:
> 
> > IMHO, the point is that RCU must be aware when we call
> > rcu_read_lock()/unlock().
> > 
> > My understanding is that rcu_irq_enter() tries to make RCU watching
> > when it was not. Then rcu_is_watching() reports if we are on
> > the safe side.
> > 
> > But it is possible that I miss something. One question is if
> > rcu_irq_enter()/exit() calls can be nested.
> > 
> > I still need to think about it.
> 
> The code looks ok to me now, except for a few minor issues:
> 
> - The warning message should be more specific.
> 
> - The documentation should probably mention the name of the specific RCU
>   function which shouldn't be patched.
> 
> - The documentation might also mention that the warning could also be
>   triggered in early NMI or exception code, e.g. if there are any calls
>   to functions with fentry calls which have been patched.
> 
> - The code comment should probably refer to the documentation, otherwise
>   nobody will ever read it ;-)

Agreed.

Petr, could you also improve the changelog a bit? Certain parts confuse 
me and I think that your changes to the documentation describe it better.

I mean these two paragraphs:

"Unfortunately, the ftrace handler might be called when the problematic
patch has already been removed from ops->func stack. In this case,
it is not able to read the immediate flag. It makes the check
unreliable. We rather avoid it and report the problem even when
the system stability is not affected.

It would be possible to add some more complex logic to avoid
warnings when RCU infrastructure is modified using immediate
patches. But let's keep it simple until real life experience
forces us to do the opposite."

I'm still not sure if we know for 100 percent what we're doing :)

Miroslav

  reply	other threads:[~2017-05-11 12:40 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 [this message]
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
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=alpine.LSU.2.20.1705111436420.20501@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --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=paulmck@linux.vnet.ibm.com \
    --cc=pmladek@suse.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).