Re: [PATCH][RFC] 4K stacks default, not a debug thing any more...?

[Daniel Phillips]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/