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 PHC | |
Open Source and information security mailing list archives
| ||
|
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