linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 v2 7/8] blk-merge: Ensure bios aren't split in middle of a crypto data unit
Date: Thu, 25 Mar 2021 21:26:08 +0000	[thread overview]
Message-ID: <20210325212609.492188-8-satyat@google.com> (raw)
In-Reply-To: <20210325212609.492188-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 ffb4aa0ea68b..2903de62aaca 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.31.0.291.g576ba9dcdaf-goog


  parent reply	other threads:[~2021-03-25 21:28 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-25 21:26 [PATCH v2 0/8] ensure bios aren't split in middle of crypto data unit Satya Tangirala
2021-03-25 21:26 ` [PATCH v2 1/8] block: introduce blk_ksm_is_empty() Satya Tangirala
2021-03-30 18:04   ` Christoph Hellwig
2021-04-15 19:21   ` Eric Biggers
2021-03-25 21:26 ` [PATCH v2 2/8] dm,mmc,ufshcd: handle error from blk_ksm_register() Satya Tangirala
2021-04-15 19:27   ` Eric Biggers
2021-03-25 21:26 ` [PATCH v2 3/8] block: blk-crypto: introduce blk_crypto_bio_sectors_alignment() Satya Tangirala
2021-04-15 19:33   ` Eric Biggers
2021-03-25 21:26 ` [PATCH v2 4/8] block: introduce bio_required_sector_alignment() Satya Tangirala
2021-03-30 18:06   ` Christoph Hellwig
2021-04-15 19:37     ` Eric Biggers
2021-04-15 19:44   ` Eric Biggers
2021-03-25 21:26 ` [PATCH v2 5/8] block: respect bio_required_sector_alignment() in blk-crypto-fallback Satya Tangirala
2021-04-15 19:45   ` Eric Biggers
2021-03-25 21:26 ` [PATCH v2 6/8] block: keyslot-manager: introduce blk_ksm_restrict_dus_to_queue_limits() Satya Tangirala
2021-03-26  3:50   ` kernel test robot
2021-03-26  6:28   ` kernel test robot
2021-04-15 19:55   ` Eric Biggers
2021-03-25 21:26 ` Satya Tangirala [this message]
2021-03-25 21:26 ` [PATCH v2 8/8] block: add WARN() in bio_split() for sector alignment Satya Tangirala
2021-03-26  3:47   ` Bart Van Assche
2021-04-15 20:00   ` Eric Biggers
2021-03-25 21:51 ` [PATCH v2 0/8] ensure bios aren't split in middle of crypto data unit Bart Van Assche
2021-03-26  1:39   ` Satya Tangirala
2021-03-26  3:46     ` Bart Van Assche
2021-03-26  7:56       ` Satya Tangirala

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=20210325212609.492188-8-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).