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  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:	Tue, 6 Oct 2015 09:04:22 -0700
From:	Dan Williams <>
To:	Ming Lei <>
Cc:	Jens Axboe <>, Keith Busch <>,
	Ross Zwisler <>,
	"" <>,
	Christoph Hellwig <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH 1/2] block: generic request_queue reference counting

On Tue, Oct 6, 2015 at 3:46 AM, Ming Lei <> wrote:
> On Tue, Oct 6, 2015 at 7:23 AM, Dan Williams <> wrote:
>> On Sun, Oct 4, 2015 at 12:52 AM, Ming Lei <> wrote:
>>> On Wed, Sep 30, 2015 at 8:41 AM, Dan Williams <> wrote:
>>>> Allow pmem, and other synchronous/bio-based block drivers, to fallback
>>> Just a bit curious, why not extend it for all(both synchronous and
>>> asynchrounous) bio-based drivers? As you mentioned in introductory
>>> message, all bio based drivers may have this kind of problem.
>>> One idea I thought of is to hold the usage counter in bio life time,
>>> instead of request's life time like in blk-mq.
>>>> on a per-cpu reference count managed by the core for tracking queue
>>>> live/dead state.
>>>> The existing per-cpu reference count for the blk_mq case is promoted to
>>>> be used in all block i/o scenarios.  This involves initializing it by
>>>> default, waiting for it to drop to zero at exit, and holding a live
>>>> reference over the invocation of q->make_request_fn() in
>>> It isn't enough for asynchrounous bio drivers.
>> True, but I think that support is a follow on extension of the
>> mechanism.  It seems to me not as straightforward as holding a
>> per-request reference or a reference over the submission path.
> Given it is a general problem for all bio based drivers, it seems
> better to figure out one general solution instead of the partial fix
> only for synchrounous bio based drivers.
> IMO, it should work by holding the usage counter in BIO's lifetime,
> for example, getting it before calling q->make_request_fn(q, bio), and
> putting it after bio's completion(in bio_endio()).  Even though there is
> still a small window between all bio's completion and all request's
> completion, and it should have been addressed easily for both
> !mq_ops and mq_ops.

I'm not convinced it is that simple, i.e. that all bio_endio()
invocations are guaranteed to have a 1:1 matching invocation through
generic_make_request().  If you want to help with that audit I'd be
appreciative and open to putting together a follow-on patch.  In the
meantime this starting point already makes things better for pmem,
nd_blk, brd, etc...
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists