Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...? | Date | Wed, 11 Jul 2007 20:15:53 -0700 |
| |
On Wednesday 11 July 2007 15:09, Neil Brown wrote: > > > Has anyone fixed the infrequent crashes with 4K stacks and ext3 > > > -> LVM snapshot -> LVM -> DM mirror -> libata? > > > > Ahem: ext3 -> LVM snapshot -> LVM -> DM mirror -> DM crypt -> md -> > > libata, or worse. > > > > No, it's not fixed. The model is wrong. Virtual block drivers > > should not be callling submit_bio. The recursive IO submissions > > should be handled on a dedicated stack, most probably allocated as > > part of the request queue. This could be done easily in device > > mapper and md, or better, in submit_bio. > > Maybe you should read that latest kernel source code. Particularly > generic_make_request in block/ll_rw_blk.c.
And plus you've had that one sitting around since 2005, hats off for nailing the issue from way out. Sorry for missing the action, I was elsewhere. Niggles begin here.
I'm not sure I like the additional task_struct encumbrance when the functions themselves could sort it out, albeit with an API change affecting a gaggle of md and dm drivers.
Hopefully there are other users of the bio list fields, otherwise I would point out that a per-queue stack is less memory than two per-bio fields. I didn't go delving that far.
The pointer to the description of the barrier deadlock is not right, it points to the problem report when it really out to point to the definitive analysis and include a subject line, because list archives come and go:
[PATCH] block: always requeue !fs requests at the front http://thread.gmane.org/gmane.linux.kernel/537473
Is there a good reason why we should not just put the whole analysis from Tejun Heo in as a comment? It is terse enough.
In other words, looks good to me :)
Regards,
Daniel - 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/
| |