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]
Message-ID: <CACVXFVO0v5nAbzY_h72P8vHWvtnw3ctRt8TKhgxRPeK1nGKonA@mail.gmail.com>
Date:	Tue, 6 Oct 2015 18:46:52 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	Jens Axboe <axboe@...nel.dk>, Keith Busch <keith.busch@...el.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Christoph Hellwig <hch@....de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] block: generic request_queue reference counting

On Tue, Oct 6, 2015 at 7:23 AM, Dan Williams <dan.j.williams@...el.com> wrote:
> On Sun, Oct 4, 2015 at 12:52 AM, Ming Lei <tom.leiming@...il.com> wrote:
>> On Wed, Sep 30, 2015 at 8:41 AM, Dan Williams <dan.j.williams@...el.com> 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.

thanks,
Ming Lei
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ