lkml.org 
[lkml]   [2002]   [Jun]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC] 4KB stack + irq stack for x86
    From
    Date
    "David S. Miller" <davem@redhat.com> writes:

    > I agree with Ben, if things explode due to stack overflow with his
    > changes they are almost certain to explode before his changes.

    Things can explode anyways as handle_irq_event does __sti even when you have
    zero stack left. And there can be always another interrupts. But it doesn't
    happen that often in practice as you suggest.

    So either fix it completely which would be adding stack checking to
    do_IRQ (and not __sti when you have less than a few hundred bytes left) or
    ignore the case as it doesn't seem to happen in practice regularly
    (at least I've never seen it and I see quite a lot of crashes)

    Interrupt stack doesn't fix the fundamental problem. It only makes it less
    likely to hit. Crippling user context code for this doesn't seem to be helpful
    at least for i386 (although I would prefer it for x86-64 because the 8K
    stack even without interrupts is rather tight for 64bit). But still I would
    likely prefer to enlarge the x86-64 stack than to see useful software
    not working because of this.

    The scenario Steve outlined was rather optimistic - more pessimistic
    case would be e.g:
    you run NBD which calls the network stack with an complex file system on top
    of it called by something else complex that does a GFP_KERNEL alloc and VM
    wants to flush a page via the NBD file system - I don't see how you'll ever
    manage to fit that into 4K.

    -Andi

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:26    [W:2.544 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site