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 -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
