Messages in this thread | | | Date | Thu, 25 Nov 2004 08:11:14 +0100 | From | Jens Axboe <> | Subject | Re: oops with dual xeon 2.8ghz 4gb ram +smp, software raid, lvm, and xfs |
| |
On Wed, Nov 24 2004, Andrew Morton wrote: > Jens Axboe <axboe@suse.de> wrote: > > > > On Thu, Nov 25 2004, Neil Brown wrote: > > > On Wednesday November 24, akpm@osdl.org wrote: > > > > Neil Brown <neilb@cse.unsw.edu.au> wrote: > > > > > > > > > > Would the following (untested-but-seems-to-compile - > > > > > explanation-of-concept) patch be at all reasonable to avoid stack > > > > > depth problems with stacked block devices, or is adding stuff to > > > > > task_struct frowned upon? > > > > > > > > It's always a tradeoff - we've put things in task_struct before to get > > > > around sticky situations. Certainly, removing potentially unbounded stack > > > > utilisation is a worthwhile thing to do. > > > > > > > > The patch bends my brain a bit. > > > > > > Recursion is like that (... like recursion, that is :-). > > > > Pardon my ignorance, but where is the bug that called for something like > > this? > > Well there was an xfs-on-raid-on-lvm stack overrun reported, but the > general problem we're addressing here is that stacking drivers can cause > arbitrary amounts of kernel stack windup.
Ok. Without b[] on the stack locally, I don't think it's an issue.
> > I can't say I love the idea of adding a bio list structure to the > > tasklist, it feels pretty hacky. generic_make_request() doesn't really > > use that much stack, if you just kill the BDEVNAME_SIZE struct. > > Looks like a sensible thing to do, although it would be tidier to move the > whole thing into a separate function, no?
Yep, works for me.
-- Jens Axboe
- 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/
| |