From: Mike Snitzer <snitzer@redhat.com>
To: Baolin Wang <baolin.wang@linaro.org>
Cc: axboe@kernel.dk, agk@redhat.com, dm-devel@redhat.com,
neilb@suse.com, linux-raid@vger.kernel.org, jack@suse.cz,
arnd@arndb.de, linux-kernel@vger.kernel.org,
keith.busch@intel.com, jmoyer@redhat.com, broonie@kernel.org,
tj@kernel.org, bart.vanassche@sandisk.com, dineshg@quicinc.com
Subject: Re: [PATCH 1/2] block: Introduce BIO_ENDIO_FREE for bio flags
Date: Wed, 11 Nov 2015 12:54:11 -0500 [thread overview]
Message-ID: <20151111175411.GC12236@redhat.com> (raw)
In-Reply-To: <2bd3cc769530061501af545c7949dcc832263930.1447233227.git.baolin.wang@linaro.org>
On Wed, Nov 11 2015 at 4:31am -0500,
Baolin Wang <baolin.wang@linaro.org> wrote:
> When we use dm-crypt to decrypt block data, it will decrypt the block data
> in endio() when one IO is completed. In this situation we don't want the
> cloned bios is freed before calling the endio().
>
> Thus introduce 'BIO_ENDIO_FREE' flag to support the request handling for dm-crypt,
> this flag will ensure that blk layer does not complete the cloned bios before
> completing the request. When the crypt endio is called, post-processsing is
> done and then the dm layer will complete the bios (clones) and free them.
Not following why request-based DM's partial completion handling
(drivers/md/dm.c:end_clone_bio) isn't a sufficient hook -- no need to
add block complexity.
But that aside, I'm not liking the idea of a request-based dm-crypt.
> diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
> index 76d23fa..f636c50 100644
> --- a/include/linux/device-mapper.h
> +++ b/include/linux/device-mapper.h
> @@ -407,6 +407,11 @@ union map_info *dm_get_rq_mapinfo(struct request *rq);
>
> struct queue_limits *dm_get_queue_limits(struct mapped_device *md);
>
> +void dm_end_request(struct request *clone, int error);
> +void dm_kill_unmapped_request(struct request *rq, int error);
> +void dm_dispatch_clone_request(struct request *clone, struct request *rq);
> +struct request *dm_get_orig_rq(struct request *clone);
> +
> /*
> * Geometry functions.
> */
I have no interest in seeing any request-based DM interfaces exported.
next prev parent reply other threads:[~2015-11-11 17:54 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-11 9:31 [PATCH 0/2] Introduce the request handling for dm-crypt Baolin Wang
2015-11-11 9:31 ` [PATCH 1/2] block: Introduce BIO_ENDIO_FREE for bio flags Baolin Wang
2015-11-11 17:54 ` Mike Snitzer [this message]
2015-11-12 4:05 ` Baolin Wang
2015-11-11 9:31 ` [PATCH 2/2] md: dm-crypt: Introduce the request handling for dm-crypt Baolin Wang
2015-11-11 9:48 ` [PATCH 0/2] " Christoph Hellwig
2015-11-12 2:15 ` Baolin Wang
2015-11-12 9:17 ` Jan Kara
2015-11-12 9:40 ` Baolin Wang
2015-11-12 11:06 ` Jan Kara
2015-11-12 11:46 ` Baolin Wang
2015-11-12 12:24 ` Jan Kara
2015-11-12 12:51 ` Baolin Wang
2015-11-12 12:57 ` Arnd Bergmann
2015-11-12 15:02 ` Mark Brown
2015-11-13 3:27 ` Baolin Wang
2015-11-13 3:25 ` Baolin Wang
2015-11-12 12:59 ` Jan Kara
2015-11-13 2:05 ` Baolin Wang
2015-11-13 9:05 ` Arnd Bergmann
2015-11-13 11:37 ` Baolin Wang
2015-11-11 18:18 ` Mike Snitzer
2015-11-12 2:36 ` Baolin Wang
2015-11-12 9:06 ` [dm-devel] " Christoph Hellwig
2015-11-12 8:20 ` Baolin Wang
2015-11-12 10:04 ` Mark Brown
2015-11-12 15:26 ` Jens Axboe
2015-11-13 2:07 ` Baolin Wang
2015-11-13 11:51 ` Mark Brown
2015-12-02 12:46 ` Baolin Wang
2015-12-02 19:56 ` [dm-devel] " Alasdair G Kergon
2015-12-03 2:56 ` Baolin Wang
2015-12-03 10:36 ` Baolin Wang
2015-12-03 11:07 ` Zdenek Kabelac
2015-12-03 11:27 ` Baolin Wang
2015-12-03 15:49 ` Mikulas Patocka
2015-12-04 4:58 ` Baolin Wang
2015-12-03 15:47 ` Mikulas Patocka
2015-12-04 4:57 ` Baolin Wang
2015-11-12 9:05 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151111175411.GC12236@redhat.com \
--to=snitzer@redhat.com \
--cc=agk@redhat.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=baolin.wang@linaro.org \
--cc=bart.vanassche@sandisk.com \
--cc=broonie@kernel.org \
--cc=dineshg@quicinc.com \
--cc=dm-devel@redhat.com \
--cc=jack@suse.cz \
--cc=jmoyer@redhat.com \
--cc=keith.busch@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).