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.jpoim...@redhat.com: -- Josh
