From: Satya Tangirala <satyat@google.com>
To: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>, Eric Biggers <ebiggers@google.com>,
Satya Tangirala <satyat@google.com>
Subject: [PATCH v3 09/10] blk-merge: Ensure bios aren't split in middle of a crypto data unit
Date: Fri, 4 Jun 2021 19:58:59 +0000 [thread overview]
Message-ID: <20210604195900.2096121-10-satyat@google.com> (raw)
In-Reply-To: <20210604195900.2096121-1-satyat@google.com>
Update get_max_io_size() to return a value aligned to
bio_required_sector_alignment(). With this change, and the changes
to blk_ksm_register() that restrict the supported data unit sizes
based on the queue's limits, blk_bio_segment_split() won't split bios in
the middle of a data unit anymore
Signed-off-by: Satya Tangirala <satyat@google.com>
---
block/blk-merge.c | 49 ++++++++++++++++++++++++++++++-----------------
1 file changed, 31 insertions(+), 18 deletions(-)
diff --git a/block/blk-merge.c b/block/blk-merge.c
index 4d97fb6dd226..00266e4ab05f 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -135,27 +135,39 @@ static struct bio *blk_bio_write_same_split(struct request_queue *q,
/*
* Return the maximum number of sectors from the start of a bio that may be
- * submitted as a single request to a block device. If enough sectors remain,
- * align the end to the physical block size. Otherwise align the end to the
- * logical block size. This approach minimizes the number of non-aligned
- * requests that are submitted to a block device if the start of a bio is not
- * aligned to a physical block boundary.
+ * submitted as a single request to a block device. Tries to align the end to
+ * the physical block size, while also aligning the returned number of sectors
+ * to bio_required_sector_alignment(). This approach minimizes the number of
+ * non-aligned requests that are submitted to a block device if the start of a
+ * bio is not aligned to a physical block boundary.
+ *
+ * More clearly, there are two conditions we're interested in satisfying.
+ *
+ * Condition 1) We absolutely must have @return divisible by the
+ * bio_required_sector_alignment(bio).
+ *
+ * Condition 2) *If possible*, while still satisfying Condition 1, we would like
+ * to have start_offset + @return divisible by physical block size in sectors
+ * (pbs).
*/
static inline unsigned get_max_io_size(struct request_queue *q,
struct bio *bio)
{
- unsigned sectors = blk_max_size_offset(q, bio->bi_iter.bi_sector, 0);
- unsigned max_sectors = sectors;
- unsigned pbs = queue_physical_block_size(q) >> SECTOR_SHIFT;
- unsigned lbs = queue_logical_block_size(q) >> SECTOR_SHIFT;
- unsigned start_offset = bio->bi_iter.bi_sector & (pbs - 1);
-
- max_sectors += start_offset;
- max_sectors &= ~(pbs - 1);
- if (max_sectors > start_offset)
- return max_sectors - start_offset;
-
- return sectors & ~(lbs - 1);
+ unsigned int start_offset = bio->bi_iter.bi_sector;
+ unsigned int sectors = blk_max_size_offset(q, start_offset, 0);
+ unsigned int pbs = queue_physical_block_size(q) >> SECTOR_SHIFT;
+ unsigned int req_sector_align = bio_required_sector_alignment(bio);
+ unsigned int pbs_aligned_sector = round_down(start_offset + sectors, pbs);
+
+ /*
+ * If we can return a pbs aligned endpoint while satisfying Condition 1,
+ * then do so.
+ */
+ if (pbs_aligned_sector > start_offset &&
+ IS_ALIGNED(pbs_aligned_sector - start_offset, req_sector_align))
+ return pbs_aligned_sector - start_offset;
+
+ return round_down(sectors, req_sector_align);
}
static inline unsigned get_max_segment_size(const struct request_queue *q,
@@ -235,6 +247,7 @@ static bool bvec_split_segs(const struct request_queue *q,
* following is guaranteed for the cloned bio:
* - That it has at most get_max_io_size(@q, @bio) sectors.
* - That it has at most queue_max_segments(@q) segments.
+ * - That the number of sectors is aligned to bio_required_sector_alignment(@bio).
*
* Except for discard requests the cloned bio will point at the bi_io_vec of
* the original bio. It is the responsibility of the caller to ensure that the
@@ -286,7 +299,7 @@ static struct bio *blk_bio_segment_split(struct request_queue *q,
* big IO can be trival, disable iopoll when split needed.
*/
bio->bi_opf &= ~REQ_HIPRI;
-
+ sectors = round_down(sectors, bio_required_sector_alignment(bio));
return bio_split(bio, sectors, GFP_NOIO, bs);
}
--
2.32.0.rc1.229.g3e70b5a671-goog
next prev parent reply other threads:[~2021-06-04 19:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-04 19:58 [PATCH v3 00/10] ensure bios aren't split in middle of crypto data unit Satya Tangirala
2021-06-04 19:58 ` [PATCH v3 01/10] block: introduce blk_ksm_is_empty() Satya Tangirala
2021-06-16 23:47 ` Eric Biggers
2021-06-04 19:58 ` [PATCH v3 02/10] block: blk-crypto: introduce blk_crypto_bio_sectors_alignment() Satya Tangirala
2021-06-17 0:29 ` Eric Biggers
2021-06-04 19:58 ` [PATCH v3 03/10] block: introduce bio_required_sector_alignment() Satya Tangirala
2021-06-17 0:37 ` Eric Biggers
2021-06-04 19:58 ` [PATCH v3 04/10] block: respect bio_required_sector_alignment() in blk-crypto-fallback Satya Tangirala
2021-06-17 0:39 ` Eric Biggers
2021-06-17 4:34 ` Eric Biggers
2021-06-04 19:58 ` [PATCH v3 05/10] block: keyslot-manager: introduce blk_ksm_restrict_dus_to_queue_limits() Satya Tangirala
2021-06-17 1:58 ` Eric Biggers
2021-06-04 19:58 ` [PATCH v3 06/10] ufshcd: handle error from blk_ksm_register() Satya Tangirala
2021-06-04 19:58 ` [PATCH v3 07/10] mmc: " Satya Tangirala
2021-06-17 3:25 ` Eric Biggers
2021-06-24 10:04 ` Satya Tangirala
2021-06-04 19:58 ` [PATCH v3 08/10] dm: " Satya Tangirala
2021-06-17 3:23 ` Eric Biggers
2021-06-04 19:58 ` Satya Tangirala [this message]
2021-06-04 19:59 ` [PATCH v3 10/10] block: add WARN_ON_ONCE() to bio_split() for sector alignment Satya Tangirala
2021-06-17 2:46 ` Eric Biggers
2021-06-17 3:51 ` [PATCH v3 00/10] ensure bios aren't split in middle of crypto data unit Eric Biggers
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=20210604195900.2096121-10-satyat@google.com \
--to=satyat@google.com \
--cc=axboe@kernel.dk \
--cc=ebiggers@google.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.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).