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 for Android: free password hash cracker in your pocket

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

Message-ID: <20120118171029.GD30664@google.com>
Date:	Wed, 18 Jan 2012 09:10:29 -0800
From:	Tejun Heo <tj@...nel.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Jens Axboe <axboe@...nel.dk>, 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

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