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

Groups > linux.kernel > #1373343 > unrolled thread

Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Petr Mladek <pmladek@suse.com> - 2016-04-07 14:20 +0200
    Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-07 17:10 +0200
      Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Jiri Kosina <jikos@kernel.org> - 2016-04-07 17:50 +0200
        Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Josh Poimboeuf <jpoimboe@redhat.com> - 2016-04-07 20:10 +0200
          Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model Jiri Kosina <jikos@kernel.org> - 2016-04-07 20:40 +0200

#1373343 — Re: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model

On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> TODO:
> - try ftrace handler switching idea from v1 cover letter

I have had a discussion about it with Mirek. This would help with
kthreads. If they are sleeping in a patched function, we wake
them up, this will help to migrate them before they get asleep again.

But it might be quite tricky. We must make sure to avoid a deadlock.
We probably should not check the stack in atomic context or
in time sensitive functions.

An alternative would be to check the stack and try migration
when the process goes into a sleep. It is a location where
we should not be afraid of any deadlocks or slight delay.
There should be high changes for a successful migration with
a minimal impact on the system throughput.

Best Regards,
Petr

[toc] | [next] | [standalone]

#1373466

On Thu, Apr 07, 2016 at 02:10:30PM +0200, Petr Mladek wrote:
> On Fri 2016-03-25 14:34:47, Josh Poimboeuf wrote:
> > TODO:
> > - try ftrace handler switching idea from v1 cover letter
> 
> I have had a discussion about it with Mirek. This would help with
> kthreads. If they are sleeping in a patched function, we wake
> them up, this will help to migrate them before they get asleep again.
> 
> But it might be quite tricky. We must make sure to avoid a deadlock.

I assume a deadlock could only occur if the function is changing locking
semantics, and it's up to the patch author to be careful?  Or did I miss
the point?

> We probably should not check the stack in atomic context

Can you elaborate why not?

Regardless, this might be fine, if the only goal of this approach is to
transition kthreads (which I think it is).

> or in time sensitive functions.

Would it be up to the patch author to make this judgement?

> An alternative would be to check the stack and try migration
> when the process goes into a sleep. It is a location where
> we should not be afraid of any deadlocks or slight delay.
> There should be high changes for a successful migration with
> a minimal impact on the system throughput.

But if it's sleeping on a patched function as postulated above, that
doesn't solve the stated problem :-)

-- 
Josh

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

#1373491

On Thu, 7 Apr 2016, Josh Poimboeuf wrote:

> > > - try ftrace handler switching idea from v1 cover letter
[ ... ]
> > We probably should not check the stack in atomic context
> 
> Can you elaborate why not?

I admittedly forgot what the "ftrace handler switching idea" is, and am 
not sure where exactly to look for it (could you please point it to me so 
that I can refresh my memory), but generally we can't assume that a memory 
holding stack of a sleeping task hasn't been reclaimed and wouldn't need 
to have been paged in again.

-- 
Jiri Kosina
SUSE Labs

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

#1373626

On Thu, Apr 07, 2016 at 05:47:00PM +0200, Jiri Kosina wrote:
> On Thu, 7 Apr 2016, Josh Poimboeuf wrote:
> 
> > > > - try ftrace handler switching idea from v1 cover letter
> [ ... ]
> > > We probably should not check the stack in atomic context
> > 
> > Can you elaborate why not?
> 
> I admittedly forgot what the "ftrace handler switching idea" is, and am 
> not sure where exactly to look for it (could you please point it to me so 
> that I can refresh my memory)

Here's where I originally described it [1]:

| 2) As mentioned above, kthreads which are always sleeping on a patched function
|    will never transition to the new universe.  This is really a minor issue
|    (less than 1% of patches).  It's not necessarily something that needs to be
|    resolved with this patch set, but it would be good to have some discussion
|    about it regardless.
|    
|    To overcome this issue, I have 1/2 an idea: we could add some stack checking
|    code to the ftrace handler itself to transition the kthread to the new
|    universe after it re-enters the function it was originally sleeping on, if
|    the stack doesn't already have have any other to-be-patched functions.
|    Combined with the klp_transition_work_fn()'s periodic stack checking of
|    sleeping tasks, that would handle most of the cases (except when trying to
|    patch the high-level thread_fn itself).

> but generally we can't assume that a memory holding stack of a
> sleeping task hasn't been reclaimed and wouldn't need to have been
> paged in again.

Hm, we're talking about kernel stacks, right?  Are they not always
resident in memory?


[1] https://lkml.kernel.org/r/cover.1423499826.git.jpoimboe@redhat.com:

-- 
Josh

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

#1373644

On Thu, 7 Apr 2016, Josh Poimboeuf wrote:

> > I admittedly forgot what the "ftrace handler switching idea" is, and am 
> > not sure where exactly to look for it (could you please point it to me so 
> > that I can refresh my memory)
> 
> Here's where I originally described it [1]:

Thanks!

> | 2) As mentioned above, kthreads which are always sleeping on a patched function
> |    will never transition to the new universe.  This is really a minor issue
> |    (less than 1% of patches).  It's not necessarily something that needs to be
> |    resolved with this patch set, but it would be good to have some discussion
> |    about it regardless.
> |    
> |    To overcome this issue, I have 1/2 an idea: we could add some stack checking
> |    code to the ftrace handler itself to transition the kthread to the new
> |    universe after it re-enters the function it was originally sleeping on, if
> |    the stack doesn't already have have any other to-be-patched functions.
> |    Combined with the klp_transition_work_fn()'s periodic stack checking of
> |    sleeping tasks, that would handle most of the cases (except when trying to
> |    patch the high-level thread_fn itself).
> 
> > but generally we can't assume that a memory holding stack of a
> > sleeping task hasn't been reclaimed and wouldn't need to have been
> > paged in again.
> 
> Hm, we're talking about kernel stacks, right?  Are they not always
> resident in memory?

Sure they are, excuse my evening braindamage.

Thanks,

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web