Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1635637 > unrolled thread

[PATCH 0/3] livepatch/rcu: Handle some subtle issues between livepatching and RCU

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/3] livepatch/rcu: Handle some subtle issues between livepatching and RCU Petr Mladek <pmladek@suse.com> - 2017-05-04 13:00 +0200
    [PATCH 1/3] livepatch/rcu: Guarantee consistency when patching idle kthreads Petr Mladek <pmladek@suse.com> - 2017-05-04 13:00 +0200
    [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code Petr Mladek <pmladek@suse.com> - 2017-05-04 13:00 +0200
      Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Josh Poimboeuf <jpoimboe@redhat.com> - 2017-05-08 19:00 +0200
        Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Steven Rostedt <rostedt@goodmis.org> - 2017-05-08 21:20 +0200
          Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Josh Poimboeuf <jpoimboe@redhat.com> - 2017-05-08 21:50 +0200
            Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-08 22:20 +0200
              Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Josh Poimboeuf <jpoimboe@redhat.com> - 2017-05-08 22:50 +0200
                Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Josh Poimboeuf <jpoimboe@redhat.com> - 2017-05-08 23:00 +0200
                  Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-08 23:10 +0200
                Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-08 23:10 +0200
                  Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Steven Rostedt <rostedt@goodmis.org> - 2017-05-08 23:20 +0200
                    Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-08 23:40 +0200
                  Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Josh Poimboeuf <jpoimboe@redhat.com> - 2017-05-09 00:20 +0200
                    Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-09 00:40 +0200
                      Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Josh Poimboeuf <jpoimboe@redhat.com> - 2017-05-09 18:20 +0200
                        Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-09 18:40 +0200
                        Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Petr Mladek <pmladek@suse.com> - 2017-05-10 18:10 +0200
                          Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-10 18:50 +0200
                          Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Josh Poimboeuf <jpoimboe@redhat.com> - 2017-05-10 20:00 +0200
                            Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken  in RCU code Miroslav Benes <mbenes@suse.cz> - 2017-05-11 14:50 +0200
                              Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Josh Poimboeuf <jpoimboe@redhat.com> - 2017-05-11 17:10 +0200
                Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Steven Rostedt <rostedt@goodmis.org> - 2017-05-08 23:20 +0200
            Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Steven Rostedt <rostedt@goodmis.org> - 2017-05-08 22:20 +0200
              Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken  in RCU code Miroslav Benes <mbenes@suse.cz> - 2017-05-11 15:00 +0200
          Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Petr Mladek <pmladek@suse.com> - 2017-05-11 16:00 +0200
            Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-11 17:00 +0200
            Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Josh Poimboeuf <jpoimboe@redhat.com> - 2017-05-11 17:30 +0200
        Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is  broken in RCU code Petr Mladek <pmladek@suse.com> - 2017-05-11 14:50 +0200
    Re: [PATCH 0/3] livepatch/rcu: Handle some subtle issues between  livepatching and RCU "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2017-05-04 19:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1639371 — Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

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

[toc] | [prev] | [next] | [standalone]

#1639674 — Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

On Thu, May 11, 2017 at 02:40:42PM +0200, Miroslav Benes wrote:
> I'm still not sure if we know for 100 percent what we're doing :)

At least we know that we don't know!

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1637732 — Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

On Mon, 8 May 2017 15:43:33 -0500
Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> Ok, so just to clarify.  Is there a bug in the ftrace stack tracer in
> the following situation?
> 
> 1. RCU isn't watching
> 2. An NMI hits
> 3. ist_enter() calls into the ftrace stack tracer, before
>    rcu_nmi_enter() is called, so RCU isn't watching yet

No, because in the ftrace stack tracer there's:

	if (in_nmi())
		return;

At the very beginning.

-- Steve

> 4. The ftrace stack tracer calls rcu_irq_enter(), which has no effect,
>    so RCU still isn't watching
> 5. Hilarity ensues in the ftrace stack tracer
> 

[toc] | [prev] | [next] | [standalone]

#1637696 — Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

On Mon, 8 May 2017 14:47:29 -0500
Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> > Although you should have:
> > 
> > 	if (WARN_ONCE(!rcu_is_watching,
> > 			"Livepatch ..."))
> > 		return;
> > 
> > or something to not cause any damage.  
> 
> My understanding is that returning would be more dangerous than
> continuing here.
> 
> By continuing to run, there's only a small chance that it will get stale
> data, which would break the consistency model by executing an old
> version of the function and possibly crashing the system.
> 
> On the other hand, returning would unconditionally break the consistency
> model by *always* executing an old version of the function.  So that
> greatly increases the risk of a crash.

I was being oversimplified by saying 'return', perhaps go into a
critical mode that can try again, or perhaps even back out the patch.
As in a transaction style. Yes, this will need to be thought through to
know how to get out. My comment wasn't meant to be simple.

> 
> > > The warning would be more helpful if it printed a little more
> > > information, like the ip and the parent_ip.  And it should probably
> > > mention that RCU is broken.  
> > 
> > Well, the warning would also print a stack trace. How is RCU broken? It
> > could simply be that you are patching a function that is in a place
> > that RCU doesn't "watch". Like going to idle or userspace. Or even in
> > RCU itself.  
> 
> As I understand it, RCU would be "broken" because this ftrace handler
> has an RCU read critical section.  And in the case where RCU isn't
> watching, rcu_read_lock() will not function as advertised, right?

Well, it's not RCU that's broken. It's the users ;-)

> 
> > > Also I wonder if we can constrain the warning somehow.  I think the
> > > warning only applies if a patch is in progress, right?  In that case, if
> > > RCU is broken, would it be feasible to mutex_trylock() the klp mutex to
> > > try to ensure that no patches are being applied while the ftrace handler
> > > is running?  Then it wouldn't matter if RCU were broken because the func
> > > stack wouldn't be changing anyway.  Then it could only warn if it failed
> > > to get the mutex.  
> > 
> > How would RCU be broken?
> >   
> > > 
> > > Stepping back a bit, the documentation and comments describe patches to
> > > functions inside the RCU infrastructure.  As far as I can tell, only a
> > > single function would be affected: rcu_dynticks_eqs_enter().  Because
> > > it's the only function called after the "Breaks tracing momentarily"
> > > comment in rcu_eqs_enter_common().  Any reason why we couldn't just
> > > annotate rcu_dynticks_eqs_enter() with notrace?  
> > 
> > Note, there's places in the kernel (on the way to idle and userspace)
> > that rcu is not watching. Ftrace handles this differently than most
> > places. But anything that requires calling rcu_read_lock(), well, you
> > need to beware.
> >   
> > > 
> > > Stepping back even further, if I'm understanding this issue correctly,
> > > this warning can also affect patches to functions which are called from
> > > NMI context.  If the NMI occurs in the part of rcu_eqs_enter_common()
> > > where rcu_irq_enter() doesn't work, then RCU won't work here, right?  If
> > > so, that worries me because there are a lot of functions which can be
> > > called (and patched) from NMI context.  
> > 
> > Note, the "rcu_dynticks_eqs_enter()" is the only place that can't make
> > rcu "watch" again.  
> 
> So would it make sense to annotate it with 'notrace'?

No. Because ftrace doesn't require that and works fine. The strack
tracer is the only thing that has issues in the ftrace code.

If we were to start slapping in notrace for each user of ftrace that
has issues, then we would have nothing left to trace ;-)


> 
> > If rcu is not watching, calling rcu_enter_irq() will have it watch
> > again. Even in NMI context I believe.  
> 
> What if you get an NMI while running in rcu_dynticks_eqs_enter() before
> it increments rdtp->dynticks?  Will rcu_enter_irq() still work from the
> NMI?

Good question. Paul?

> 
> I'm just trying to understand what are the cases where rcu_enter_irq()
> *doesn't* work from an ftrace handler.

I think the only place is that one function. But you are right. What
happens if an NMI comes in?

> 
> > > I wonder if there's some way to solve this by changing RCU code, but I'm
> > > not familiar enough with RCU to have any ideas there.  
> > 
> > You don't want to go there.  
> 
> I believe you :-)
> 

-- Steve

[toc] | [prev] | [next] | [standalone]

#1639377 — Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

On Mon, 8 May 2017, Steven Rostedt wrote:

> On Mon, 8 May 2017 14:47:29 -0500
> Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
> > > Although you should have:
> > > 
> > > 	if (WARN_ONCE(!rcu_is_watching,
> > > 			"Livepatch ..."))
> > > 		return;
> > > 
> > > or something to not cause any damage.  
> > 
> > My understanding is that returning would be more dangerous than
> > continuing here.
> > 
> > By continuing to run, there's only a small chance that it will get stale
> > data, which would break the consistency model by executing an old
> > version of the function and possibly crashing the system.
> > 
> > On the other hand, returning would unconditionally break the consistency
> > model by *always* executing an old version of the function.  So that
> > greatly increases the risk of a crash.
> 
> I was being oversimplified by saying 'return', perhaps go into a
> critical mode that can try again, or perhaps even back out the patch.
> As in a transaction style. Yes, this will need to be thought through to
> know how to get out. My comment wasn't meant to be simple.

Well, live patching is in fact transactional. To some extent. If we fail 
during ftrace registration we abort the action gracefully. After the 
registration it gets more interesting because the whole system is 
"asynchronously" migrated to a final patched state. Even during this stage 
we can reverse the process (klp_reverse_transition()), but it was not easy 
to get it right...

... and to implement or start this logic from the handler sends shivers 
down my spine.

We still can try.

Thanks,
Miroslav

[toc] | [prev] | [next] | [standalone]

#1639465 — Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

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

[toc] | [prev] | [next] | [standalone]

#1639650 — Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

On Thu, May 11, 2017 at 03:52:46PM +0200, Petr Mladek wrote:
> 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?

Only RCU readers can be used in NMI handlers, that is, rcu_read_lock(),
rcu_read_unlock(), rcu_dereference(), and so on.

							Thanx, Paul

> 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
> 

[toc] | [prev] | [next] | [standalone]

#1639746 — Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

On Thu, May 11, 2017 at 03:52:46PM +0200, Petr Mladek wrote:
> 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.

http://i3.kym-cdn.com/photos/images/original/000/173/580/Wat.jpg

> 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();

I couldn't grok the first idea, but this one sounds promising...

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1639369 — Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code

On Mon 2017-05-08 11:51:08, Josh Poimboeuf wrote:
> On Thu, May 04, 2017 at 12:55:15PM +0200, Petr Mladek wrote:
> > RCU is not watching inside some RCU code. As a result, the livepatch
> > ftrace handler might see ops->func_stack and some other flags in
> > a wrong state. Then a livepatch might make the system unstable.
> > 
> > diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c
> > index 4c4fbe409008..ffdf5fa8005b 100644
> > --- a/kernel/livepatch/patch.c
> > +++ b/kernel/livepatch/patch.c
> > @@ -62,6 +62,14 @@ static void notrace klp_ftrace_handler(unsigned long ip,
> >  	/* RCU may not be watching, make it see us. */
> >  	rcu_irq_enter_irqson();
> >  
> > +	/*
> > +	 * RCU still might not see us if we patch a function inside
> > +	 * the RCU infrastructure. Then we might see wrong state of
> > +	 * func->stack and other flags.
> > +	 */
> > +	if (unlikely(!rcu_is_watching()))
> > +		WARN_ONCE(1, "Livepatch modified a function that can not be handled a safe way.!");
> > +
> >  	rcu_read_lock();
> >  
> >  	func = list_first_or_null_rcu(&ops->func_stack, struct klp_func,
> 
> Also I wonder if we can constrain the warning somehow.  I think the
> warning only applies if a patch is in progress, right?

I think that this was not addressed in the other mails.

I wanted to add some constrains but all my attempts have failed
so far. For example, I wanted to avoid the warning when the function
was patched with the immediate flag set. We would be on the safe side.
Such a patch could not be removed. And the consistency model is week
enough.

The problem is that the transaction might finish too early when a
patched function cannot be watched by RCU. It means that the finished
transaction does not mean that we are safe. Also a finished transaction
allows to start a new one. Then the ftrace handler might see an
outdated function stack. Therefore it is not sure if the previously
used patch was immediate ("safely" handled) ...

Fortunately, this situation is a real corner case. It might actually be
good that the problem is always reported. It helps to detect it during
testing and avoid sending such a patch to users.


> In that case, if RCU is broken, would it be feasible to
> mutex_trylock() the klp mutex to try to ensure that no patches are
> being applied while the ftrace handler is running?  Then it wouldn't
> matter if RCU were broken because the func stack wouldn't be
> changing anyway.  Then it could only warn if it failed to get the
> mutex.

If we could not guarantee that a function might be patched a safe way,
we should not allow the patching in the first place.

The problem here is that this situation is detected at runtime.
We should do our best to avoid a damage if this happens. The 3rd patch
is from this category. But we should make it as easy as possible
to catch potential problems during patch creation or testing.

Best Regards,
Petr

[toc] | [prev] | [next] | [standalone]

#1635899 — Re: [PATCH 0/3] livepatch/rcu: Handle some subtle issues between livepatching and RCU

On Thu, May 04, 2017 at 12:55:13PM +0200, Petr Mladek wrote:
> Steven and Paul recently discussed some issues when using RCU
> functionality in ftrace handlers. A good summary can be found at
> https://lkml.kernel.org/r/20170412115304.3077dbc8@gandalf.local.home
> 
> This discussion made us to revisit the ftrace handler used by
> the livepatches. Some changes seem to be needed. A perfect solution
> looks rather complicated. I have implemented a sub-optimal
> one and split it into three patches for easier review.
> 
> Please, note that we were on the safe side before introducing
> the hybrid consistency model. The ftrace handler worked correctly
> with empty function stack. Also the patch removal was not possible.
> But we need to be more careful now.

I don't know enough to say much about the live patching, but the
characterization of how RCU works is correct.

						Thanx, Paul

> Petr Mladek (3):
>   livepatch/rcu: Guarantee consistency when patching idle kthreads
>   livepatch/rcu: Warn when system consistency is broken in RCU code
>   livepatch/rcu: Disable livepatch removal when safety is not guaranteed
> 
>  Documentation/livepatch/livepatch.txt | 19 +++++++++++++++++++
>  kernel/livepatch/patch.c              | 14 ++++++++++++++
>  kernel/livepatch/transition.c         |  7 ++++++-
>  kernel/livepatch/transition.h         |  2 ++
>  4 files changed, 41 insertions(+), 1 deletion(-)
> 
> -- 
> 1.8.5.6
> 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web