Re: Kernel crash in icq_free_icq_rcu

[Tejun Heo]

Hello, Vivek.

On Wed, Jan 18, 2012 at 11:36:38AM -0500, Vivek Goyal wrote:
> Not calling ioscheduler during plug merge will allow merging of sync/async
> requests together. I guess we wouldn't want that. The only check we can
> skip in case of plug merge, is whether bio and rq beong to same task/cfqq
> or not.
> 
> May be separate elevator functions for plug merge (without lock) and
> elevator merge (with lock) will do?

I don't think so.  As I wrote before, plugging is about issuing, not
scheduling.  In a sense, it's a block layer service to upper layers to
make building larger request easier such that block layer users can do
"plug - issue multiple bios of whatever size - flush" instead of
having to manually build series of maximum sized bios.  As such, bios
submitted during a single plugging fare naturally expected to be for
the same purpose.  They all belong to single IO unit after all.

Note that although request is involved in plug merging, the request
isn't known to elevator (other than set_request(), that is).  The only
reason we go half-way through request issuing, stash request, do plug
merging and then do the rest on flush is because block layer doesn't
have a way to deal with arbitrarily sized bios.  We're piggy backing
on request merge logic because that's the only way we know how to
group bios.

In the long run, I think plugging should be done with bios.  There's
no reason to care about requests at that level.  We're just collecting
bios issued as a unit and are likely to be close to each other.  If
request_queue can deal with arbitrarily sized bios (and list of them),
we can simply collect bios and flush down on unplug.  This would be
much cleaner, make plugging useable for bio based drivers and allow
simplifying stacking drivers.

Thanks.

-- 
tejun
--
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/