lkml.org 
[lkml]   [2016]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH v1.9 00/14] livepatch: hybrid consistency model
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

\
 
 \ /
  Last update: 2016-04-07 20:41    [W:0.076 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site