lkml.org 
[lkml]   [2009]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: irq-disabled vs vmap vs text_poke
    From
    Date
    On Fri, 2009-02-13 at 13:55 +0100, Nick Piggin wrote:
    > On Fri, Feb 13, 2009 at 01:50:07PM +0100, Peter Zijlstra wrote:
    > > Hi,
    > >
    > > Ingo got the following splat:

    <snip splat>

    > > Which points to vunmap() being called with interrupts disabled.
    > >
    > > Which made me look at the vmap/vunmap calls, and they appear to not be
    > > irq-safe, therefore this would be a bug in text_poke().
    > >
    > > [ that is, vmap() can end up calling get_vm_area_caller() which in turn
    > > calls __get_vm_area_node() with GFP_KERNEL, ergo, don't do this from
    > > an atomic context. ]
    > >
    > > Now text_poke() uses local_irq_save/restore(), which conveys that it can
    > > be called with IRQs disabled, which is exactly what happens in the trace
    > > above, however we just established that vmap/vunmap() are not irq-safe.
    > >
    > > Anybody got an idea on how to fix this?
    >
    > Oh, I thought the consensus was not to use vmap for this?

    Seems like a sensible consensus, still that means text_poke() needs some
    TLC.

    > With a bit of work, we can make vunmap irq-safe with the lazy vunmapping
    > infrastructure (vmap could also be irq-safe, but would be subject to
    > spurious failures due to being unable to flush lazy vunmaps.

    *nod*

    > I think I got a mostly working patch cobbled together sitting here
    > somewhere. I was waiting for some _really_ good use case before spending
    > more time on it. I would prefer if at all possible to do vmap operations
    > in sleepable, process context.

    Agreed, I think we want to fix text_poke() and make the vmap/vunmap()
    ops yell louder at violations of these rules.

    I'm just totally clueless wrt text_poke() hence this email ;-)


    \
     
     \ /
      Last update: 2009-02-13 14:03    [W:2.237 / U:0.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site