linux-block.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <damien.lemoal@wdc.com>
To: dm-devel@redhat.com, Mike Snitzer <snitzer@redhat.com>,
	linux-block@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	linux-nvme@lists.infradead.org, Christoph Hellwig <hch@lst.de>,
	linux-scsi@vger.kernel.org,
	"Martin K . Petersen" <martin.petersen@oracle.com>,
	linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org,
	David Sterba <dsterba@suse.com>,
	Josef Bacik <josef@toxicpanda.com>
Cc: Johannes Thumshirn <johannes.thumshirn@wdc.com>,
	Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	Naohiro Aota <naohiro.aota@wdc.com>
Subject: [PATCH 0/4] Fix dm-crypt zoned block device support
Date: Fri, 16 Apr 2021 12:05:24 +0900	[thread overview]
Message-ID: <20210416030528.757513-1-damien.lemoal@wdc.com> (raw)

Mike,

Zone append BIOs (REQ_OP_ZONE_APPEND) always specify the start sector
of the zone to be written instead of the actual location sector to
write. The write location is determined by the device and returned to
the host upon completion of the operation.

This interface, while simple and efficient for writing into sequential
zones of a zoned block device, is incompatible with the use of sector
values to calculate a cypher block IV. All data written in a zone is
encrypted using an IV calculated from the first sectors of the zone,
but read operation will specify any sector within the zone, resulting
in an IV mismatch between encryption and decryption. Reads fail in that
case.

Using a single sector value (e.g. the zone start sector) for all read
and writes into a zone can solve this problem, but at the cost of
weakening the cypher chosen by the user. Emulating zone append using
regular writes would be another potential solution, but it is complex
and would add a lot of overhead.

Instead, to solve this problem, explicitly disable support for zone
append operations in dm-crypt if the target was setup using a cypher IV
mode using sector values. The null and random IV modes can still be used
with zone append operations. This lack of support for zone append is
exposed to the user by setting the dm-crypt target queue limit
max_zone_append_sectors to 0. This change is done in patch 1 and 2.

Patch 3 addresses btrfs-zoned case. Zone append write are used for all
file data blocks write. The change introduced fails mounting a zoned
btrfs volume if the underlying device max_zone_append_sectors limit is
0.

Patch 4 fixes zonefs to fall back to using regular write when
max_zone_append_sectors is 0.

Overall, these changes do not break user space:
1) There is no interface allowing a user to use zone append write
without a file system. So applications using directly a raw dm-crypt
device will continue working using regular write operations.
2) btrfs zoned support was added in 5.12. Anybody trying btrfs-zoned on
top of dm-crypt would have faced the read failures already. So there
are no existing deployments to preserve. Same for zonefs.

For file systems, using zone append with encryption will need to be
supported within the file system (e.g. fscrypt). In this case, cypher IV
calculation can rely for instance on file block offsets as these are
known before a zone append operation write these blocks to disk at
unknown locations.

Reviews and comments are very much welcome.

Damien Le Moal (3):
  dm: Introduce zone append support control
  dm crypt: Fix zoned block device support
  zonefs: fix synchronous write to sequential zone files

Johannes Thumshirn (1):
  btrfs: zoned: fail mount if the device does not support zone append

 drivers/md/dm-crypt.c         | 48 ++++++++++++++++++++++++++++-------
 drivers/md/dm-table.c         | 41 ++++++++++++++++++++++++++++++
 fs/btrfs/zoned.c              |  7 +++++
 fs/zonefs/super.c             | 16 +++++++++---
 fs/zonefs/zonefs.h            |  2 ++
 include/linux/device-mapper.h |  6 +++++
 6 files changed, 107 insertions(+), 13 deletions(-)

-- 
2.30.2


             reply	other threads:[~2021-04-16  3:05 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16  3:05 Damien Le Moal [this message]
2021-04-16  3:05 ` [PATCH 1/4] dm: Introduce zone append support control Damien Le Moal
2021-04-16  6:51   ` Johannes Thumshirn
2021-04-16  3:05 ` [PATCH 2/4] dm crypt: Fix zoned block device support Damien Le Moal
2021-04-16  7:13   ` Johannes Thumshirn
2021-04-16  7:30     ` Damien Le Moal
2021-04-16  9:10       ` Johannes Thumshirn
2021-04-16  3:05 ` [PATCH 3/4] btrfs: zoned: fail mount if the device does not support zone append Damien Le Moal
2021-04-16 16:17   ` David Sterba
2021-04-19  9:28     ` Christoph Hellwig
2021-04-19  9:35       ` Damien Le Moal
2021-04-19  9:39         ` hch
2021-04-19  9:46           ` Damien Le Moal
2021-04-19 16:48             ` David Sterba
2021-04-19  9:39       ` Johannes Thumshirn
2021-04-16  3:05 ` [PATCH 4/4] zonefs: fix synchronous write to sequential zone files Damien Le Moal
2021-04-16  6:50   ` Johannes Thumshirn

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=20210416030528.757513-1-damien.lemoal@wdc.com \
    --to=damien.lemoal@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=dsterba@suse.com \
    --cc=hch@lst.de \
    --cc=johannes.thumshirn@wdc.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=naohiro.aota@wdc.com \
    --cc=shinichiro.kawasaki@wdc.com \
    --cc=snitzer@redhat.com \
    /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).