> "Leonard N. Zubkoff": "Kernel Stack Overflows" (Feb 18, 1:40):
> > I'm becoming quite concerned about this whole issue of kernel stack overflows.
> > Is there any specification for how much stack space an interrupt handler is
> > allowed to use?
>
> Thanks to some good testing and debugging by Gerard Roudier we seem to
> have a handle on this problem. It wasn't an interrupt overflow at all,
> but a recursion in get_more_buffer_heads().
I tried Gerard's patch and it stopped the one kernel segmentation fault
from occurring, but it caused another one to occur. I came to the sudden
realization last night as to what might be causing my problems. I have
two 16 megabyte swap files on my root partition; I'm using the BSD NCR
driver, and I have 32 megs of RAM. The problems seem to come up when the
kernel tries to swap out memory. Things go like this:
1) BSD/NCR driver or buffer code calls get_free_page
2) get_free_page calls try_to_free_page because part of the free memory
pool has been used
3) try_to_free_page calls shrink_mmap, shm_swap, and/or swap_out
4) swap_out (or possibly one of the other calls) tries to swap back into
the file system
5) any calls to get_free_page from within the file system and/or buffer
code may send us back to #2
I'm not sure where things would go from here but it seems that there is a
pretty high chance the stack could overflow given this situation...
I'm sorta getting the "driving without a clue" feeling, so any or all of
my theory above about what is going on may be wrong, but...I hope I'm
headed in the right direction and I'd REALLY like to get this problem
fixed. I'll post some of my crashes here as soon as I get to it...our
router has been broked over the weekend so I have some catching up to do.
Jason Duerstock
jduersto@kendall.mdcc.edu