All of lore.kernel.org
 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 0/7] ensure bios aren't split in middle of crypto data unit
Date: Thu, 14 Jan 2021 15:47:16 +0000	[thread overview]
Message-ID: <20210114154723.2495814-1-satyat@google.com> (raw)

When a bio has an encryption context, its size must be aligned to its
crypto data unit size. A bio must not be split in the middle of a data
unit. Currently, bios are split at logical block boundaries, but a crypto
data unit size might be larger than the logical block size - e.g. a machine
could be using fscrypt (which uses 4K crypto data units) with an eMMC block
device with inline encryption hardware that has a logical block size of
512 bytes. So we need to support cases where the data unit size is larger
than the logical block size.

Patch 1 allows blk_bio_segment_split() in blk-merge.c to fail and return an
error code. This functionality is used by later patches in this series.
Patch 1 also updates all callers to handle/propagate any returned error.

Patch 2 introduces blk_crypto_bio_sectors_alignment() which returns the
required alignment for the number of sectors in any bio.

Patches 3, 4 and 5 update bounce.c, blk-crypto-fallback.c and blk-merge.c
respectively to respect blk_crypto_bio_sectors_alignment() when calling
bio_split(), so that any split bio's size has the required alignment.
Patch 5 (the patch updating blk-merge.c) updates blk_bio_segment_split() by
rounding down the number of sectors to the required alignment (aligned
sectors) just before the call to bio_split(). It may be the case that due
to the other restrictions on aligned sectors by blk_bio_segment_split(),
aligned sectors ends up being rounded down to 0. An error is returned in
that case, using the functionality introduced in Patch 1.

Since all callers to bio_split() should have been updated by the previous
patches, Patch 6 adds a WARN_ON() to bio_split() when sectors isn't aligned
to blk_crypto_bio_sectors_alignment().

As a result of the simplistic rounding down in Patch 5, it might also be
the case that nsegs in blk_bio_segment_split() is overestimated. Patch 7
calculates nsegs accurately, while being a lot more complicated than Patch
5. If the accuracy isn't really necessary, Patch 7 can be dropped
completely.

This patch series was tested by running android xfstests on the SDM630
chipset (which has eMMC inline encryption hardware with logical block size
512 bytes) with test_dummy_encryption with and without the 'inlinecrypt'
mount option.

Satya Tangirala (7):
  block: make blk_bio_segment_split() able to fail and return error
  block: blk-crypto: Introduce blk_crypto_bio_sectors_alignment()
  block: respect blk_crypto_bio_sectors_alignment() in bounce.c
  block: respect blk_crypto_bio_sectors_alignment() in
    blk-crypto-fallback
  block: respect blk_crypto_bio_sectors_alignment() in blk-merge
  block: add WARN() in bio_split() for sector alignment
  block: compute nsegs more accurately in blk_bio_segment_split()

 block/bio.c                   |   1 +
 block/blk-crypto-fallback.c   |   2 +
 block/blk-crypto-internal.h   |  18 +++++
 block/blk-merge.c             | 132 +++++++++++++++++++++++++++-------
 block/blk-mq.c                |   5 +-
 block/blk.h                   |   2 +-
 block/bounce.c                |   3 +
 drivers/block/drbd/drbd_req.c |   5 +-
 drivers/block/pktcdvd.c       |   3 +-
 drivers/block/ps3vram.c       |   5 +-
 drivers/block/rsxx/dev.c      |   3 +-
 drivers/block/umem.c          |   5 +-
 drivers/lightnvm/pblk-init.c  |  13 +++-
 drivers/md/dm.c               |   8 ++-
 drivers/md/md.c               |   5 +-
 drivers/nvme/host/multipath.c |   5 +-
 drivers/s390/block/dcssblk.c  |   3 +-
 drivers/s390/block/xpram.c    |   3 +-
 include/linux/blkdev.h        |   2 +-
 19 files changed, 182 insertions(+), 41 deletions(-)

-- 
2.30.0.284.gd98b1dd5eaa7-goog


             reply	other threads:[~2021-01-14 15:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 15:47 Satya Tangirala [this message]
2021-01-14 15:47 ` [PATCH 1/7] block: make blk_bio_segment_split() able to fail and return error Satya Tangirala
2021-01-14 15:47 ` [PATCH 2/7] block: blk-crypto: Introduce blk_crypto_bio_sectors_alignment() Satya Tangirala
2021-01-14 15:47 ` [PATCH 3/7] block: respect blk_crypto_bio_sectors_alignment() in bounce.c Satya Tangirala
2021-01-21 17:13   ` Christoph Hellwig
2021-01-14 15:47 ` [PATCH 4/7] block: respect blk_crypto_bio_sectors_alignment() in blk-crypto-fallback Satya Tangirala
2021-01-14 15:47 ` [PATCH 5/7] block: respect blk_crypto_bio_sectors_alignment() in blk-merge Satya Tangirala
2021-01-14 15:47 ` [PATCH 6/7] block: add WARN() in bio_split() for sector alignment Satya Tangirala
2021-01-14 15:47 ` [PATCH 7/7] block: compute nsegs more accurately in blk_bio_segment_split() Satya Tangirala
2021-01-21 17:11 ` [PATCH 0/7] ensure bios aren't split in middle of crypto data unit Christoph Hellwig
2021-03-25 21:41   ` 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=20210114154723.2495814-1-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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.