linux-kernel - Re: Kernel crash in icq_free_icq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Jan 2012 20:07:31 +0100
From:	Jens Axboe <axboe@...nel.dk>
To:	Tejun Heo <tj@...nel.org>
CC:	Vivek Goyal <vgoyal@...hat.com>, Shaohua Li <shaohua.li@...el.com>,
	linux kernel mailing list <linux-kernel@...r.kernel.org>,
	koverstreet@...gle.com, Neil Brown <neilb@...e.de>
Subject: Re: Kernel crash in icq_free_icq_rcu

On 2012-01-18 18:10, Tejun Heo wrote:
> 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.

In the longer term, plugging and merging should be much less needed.
Most file systems should have done this upfront already, so the need for
it should be much smaller. For the eventual multiqueue setup, I don't
plan on doing much work around merging at all. Perhaps some basic
merging for when it hits the final queue, but not at submit time.

-- 
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/