> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/