From: Eric Biggers <ebiggers@kernel.org>
To: Sergei Shtepa <sergei.shtepa@linux.dev>
Cc: axboe@kernel.dk, hch@infradead.org, corbet@lwn.net,
snitzer@kernel.org, mingo@redhat.com, peterz@infradead.org,
juri.lelli@redhat.com, viro@zeniv.linux.org.uk,
brauner@kernel.org, linux-block@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
Sergei Shtepa <sergei.shtepa@veeam.com>
Subject: Re: [PATCH v6 11/11] blksnap: prevents using devices with data integrity or inline encryption
Date: Tue, 28 Nov 2023 09:18:23 -0800 [thread overview]
Message-ID: <20231128171823.GA1148@sol.localdomain> (raw)
In-Reply-To: <6cabaa42-c366-4928-8294-ad261dae0043@linux.dev>
On Tue, Nov 28, 2023 at 12:00:17PM +0100, Sergei Shtepa wrote:
> But I haven't tested the code on a device where hardware inline encryption is
> available. I would be glad if anyone could help with this.
> >
> > Anyway, this patch is better than ignoring the problem. It's worth noting,
> > though, that this patch does not prevent blksnap from being set up on a block
> > device on which blk-crypto-fallback is already being used (or will be used).
> > When that happens, I/O will suddenly start failing. For usability reasons,
> > ideally that would be prevented somehow.
>
> I didn't observe any failures during testing. It's just that the snapshot
> image shows files with encrypted names and data. Backup in this case is
> useless. Unfortunately, there is no way to detect a blk-crypto-fallback on
> the block device filter level.
Huh, I thought that this patch is supposed to exclude blk-crypto-fallback too.
__submit_bio() calls bio->bi_bdev->bd_filter->ops->submit_bio(bio) before
blk_crypto_bio_prep(), so doesn't your check of ->bi_crypt_context exclude
blk-crypto-fallback?
I think you're right that it might actually be fine to use blksnap with
blk-crypto-fallback, provided that the encryption is done first. I would like
to see a proper explanation of that, though. And we still have this patch which
claims that it doesn't work, which is confusing.
- Eric
next prev parent reply other threads:[~2023-11-28 17:18 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-24 16:59 [PATCH v6 00/11] blksnap - block devices snapshots module Sergei Shtepa
2023-11-24 16:59 ` [PATCH v6 01/11] documentation: Block Device Filtering Mechanism Sergei Shtepa
2023-11-24 16:59 ` [PATCH v6 02/11] block: " Sergei Shtepa
2023-12-07 7:44 ` Christoph Hellwig
2023-12-07 11:22 ` Sergei Shtepa
2023-11-24 16:59 ` [PATCH v6 03/11] documentation: Block Devices Snapshots Module Sergei Shtepa
2023-11-24 16:59 ` [PATCH v6 04/11] blksnap: header file of the module interface Sergei Shtepa
2023-11-24 16:59 ` [PATCH v6 05/11] blksnap: module management interface functions Sergei Shtepa
2023-11-24 16:59 ` [PATCH v6 06/11] blksnap: handling and tracking I/O units Sergei Shtepa
2023-12-07 8:23 ` Christoph Hellwig
2023-11-24 16:59 ` [PATCH v6 07/11] blksnap: difference storage and chunk Sergei Shtepa
2023-12-07 8:36 ` Christoph Hellwig
2023-11-24 16:59 ` [PATCH v6 08/11] blksnap: event queue from the difference storage Sergei Shtepa
2023-11-24 16:59 ` [PATCH v6 09/11] blksnap: snapshot and snapshot image block device Sergei Shtepa
2023-11-24 16:59 ` [PATCH v6 10/11] blksnap: Kconfig and Makefile Sergei Shtepa
2023-12-07 7:47 ` Christoph Hellwig
2023-11-24 16:59 ` [PATCH v6 11/11] blksnap: prevents using devices with data integrity or inline encryption Sergei Shtepa
2023-11-27 22:47 ` Eric Biggers
2023-11-28 11:00 ` Sergei Shtepa
2023-11-28 17:18 ` Eric Biggers [this message]
2023-11-29 15:15 ` Sergei Shtepa
2023-11-24 17:03 ` [PATCH v6 00/11] blksnap - block devices snapshots module Jens Axboe
2023-11-24 17:12 ` Sergei Shtepa
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=20231128171823.GA1148@sol.localdomain \
--to=ebiggers@kernel.org \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=corbet@lwn.net \
--cc=hch@infradead.org \
--cc=juri.lelli@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sergei.shtepa@linux.dev \
--cc=sergei.shtepa@veeam.com \
--cc=snitzer@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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.