From: Eric Biggers <ebiggers@kernel.org> To: linux-fscrypt@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, Christoph Hellwig <hch@infradead.org>, Dave Chinner <david@fromorbit.com>, "Darrick J . Wong" <djwong@kernel.org>, Theodore Ts'o <tytso@mit.edu>, Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org>, Satya Tangirala <satyat@google.com> Subject: [PATCH v10 2/5] iomap: support direct I/O with fscrypt using blk-crypto Date: Wed, 19 Jan 2022 23:12:12 -0800 [thread overview] Message-ID: <20220120071215.123274-3-ebiggers@kernel.org> (raw) In-Reply-To: <20220120071215.123274-1-ebiggers@kernel.org> From: Eric Biggers <ebiggers@google.com> Encrypted files traditionally haven't supported DIO, due to the need to encrypt/decrypt the data. However, when the encryption is implemented using inline encryption (blk-crypto) instead of the traditional filesystem-layer encryption, it is straightforward to support DIO. Add support for this to the iomap DIO implementation by calling fscrypt_set_bio_crypt_ctx() to set encryption contexts on the bios. Don't check for the rare case where a DUN (crypto data unit number) discontiguity creates a boundary that bios must not cross. Instead, filesystems are expected to handle this in ->iomap_begin() by limiting the length of the mapping so that iomap doesn't have to worry about it. Co-developed-by: Satya Tangirala <satyat@google.com> Signed-off-by: Satya Tangirala <satyat@google.com> Acked-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Eric Biggers <ebiggers@google.com> --- fs/iomap/direct-io.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index 03ea367df19a4..20325b3926fa3 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -6,6 +6,7 @@ #include <linux/module.h> #include <linux/compiler.h> #include <linux/fs.h> +#include <linux/fscrypt.h> #include <linux/pagemap.h> #include <linux/iomap.h> #include <linux/backing-dev.h> @@ -179,11 +180,14 @@ static void iomap_dio_bio_end_io(struct bio *bio) static void iomap_dio_zero(const struct iomap_iter *iter, struct iomap_dio *dio, loff_t pos, unsigned len) { + struct inode *inode = file_inode(dio->iocb->ki_filp); struct page *page = ZERO_PAGE(0); int flags = REQ_SYNC | REQ_IDLE; struct bio *bio; bio = bio_alloc(GFP_KERNEL, 1); + fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits, + GFP_KERNEL); bio_set_dev(bio, iter->iomap.bdev); bio->bi_iter.bi_sector = iomap_sector(&iter->iomap, pos); bio->bi_private = dio; @@ -310,6 +314,8 @@ static loff_t iomap_dio_bio_iter(const struct iomap_iter *iter, } bio = bio_alloc(GFP_KERNEL, nr_pages); + fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits, + GFP_KERNEL); bio_set_dev(bio, iomap->bdev); bio->bi_iter.bi_sector = iomap_sector(iomap, pos); bio->bi_write_hint = dio->iocb->ki_hint; -- 2.34.1
WARNING: multiple messages have this Message-ID (diff)
From: Eric Biggers <ebiggers@kernel.org> To: linux-fscrypt@vger.kernel.org Cc: Christoph Hellwig <hch@infradead.org>, Theodore Ts'o <tytso@mit.edu>, "Darrick J . Wong" <djwong@kernel.org>, Dave Chinner <david@fromorbit.com>, linux-f2fs-devel@lists.sourceforge.net, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jaegeuk Kim <jaegeuk@kernel.org>, Satya Tangirala <satyat@google.com>, linux-ext4@vger.kernel.org Subject: [f2fs-dev] [PATCH v10 2/5] iomap: support direct I/O with fscrypt using blk-crypto Date: Wed, 19 Jan 2022 23:12:12 -0800 [thread overview] Message-ID: <20220120071215.123274-3-ebiggers@kernel.org> (raw) In-Reply-To: <20220120071215.123274-1-ebiggers@kernel.org> From: Eric Biggers <ebiggers@google.com> Encrypted files traditionally haven't supported DIO, due to the need to encrypt/decrypt the data. However, when the encryption is implemented using inline encryption (blk-crypto) instead of the traditional filesystem-layer encryption, it is straightforward to support DIO. Add support for this to the iomap DIO implementation by calling fscrypt_set_bio_crypt_ctx() to set encryption contexts on the bios. Don't check for the rare case where a DUN (crypto data unit number) discontiguity creates a boundary that bios must not cross. Instead, filesystems are expected to handle this in ->iomap_begin() by limiting the length of the mapping so that iomap doesn't have to worry about it. Co-developed-by: Satya Tangirala <satyat@google.com> Signed-off-by: Satya Tangirala <satyat@google.com> Acked-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Eric Biggers <ebiggers@google.com> --- fs/iomap/direct-io.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c index 03ea367df19a4..20325b3926fa3 100644 --- a/fs/iomap/direct-io.c +++ b/fs/iomap/direct-io.c @@ -6,6 +6,7 @@ #include <linux/module.h> #include <linux/compiler.h> #include <linux/fs.h> +#include <linux/fscrypt.h> #include <linux/pagemap.h> #include <linux/iomap.h> #include <linux/backing-dev.h> @@ -179,11 +180,14 @@ static void iomap_dio_bio_end_io(struct bio *bio) static void iomap_dio_zero(const struct iomap_iter *iter, struct iomap_dio *dio, loff_t pos, unsigned len) { + struct inode *inode = file_inode(dio->iocb->ki_filp); struct page *page = ZERO_PAGE(0); int flags = REQ_SYNC | REQ_IDLE; struct bio *bio; bio = bio_alloc(GFP_KERNEL, 1); + fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits, + GFP_KERNEL); bio_set_dev(bio, iter->iomap.bdev); bio->bi_iter.bi_sector = iomap_sector(&iter->iomap, pos); bio->bi_private = dio; @@ -310,6 +314,8 @@ static loff_t iomap_dio_bio_iter(const struct iomap_iter *iter, } bio = bio_alloc(GFP_KERNEL, nr_pages); + fscrypt_set_bio_crypt_ctx(bio, inode, pos >> inode->i_blkbits, + GFP_KERNEL); bio_set_dev(bio, iomap->bdev); bio->bi_iter.bi_sector = iomap_sector(iomap, pos); bio->bi_write_hint = dio->iocb->ki_hint; -- 2.34.1 _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2022-01-20 7:16 UTC|newest] Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-20 7:12 [PATCH v10 0/5] add support for direct I/O with fscrypt using blk-crypto Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 7:12 ` [PATCH v10 1/5] fscrypt: add functions for direct I/O support Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 8:27 ` Christoph Hellwig 2022-01-20 8:27 ` [f2fs-dev] " Christoph Hellwig 2022-01-20 9:04 ` Eric Biggers 2022-01-20 9:04 ` [f2fs-dev] " Eric Biggers 2022-01-21 7:10 ` Christoph Hellwig 2022-01-21 7:10 ` [f2fs-dev] " Christoph Hellwig 2022-01-20 7:12 ` Eric Biggers [this message] 2022-01-20 7:12 ` [f2fs-dev] [PATCH v10 2/5] iomap: support direct I/O with fscrypt using blk-crypto Eric Biggers 2022-01-20 8:28 ` Christoph Hellwig 2022-01-20 8:28 ` [f2fs-dev] " Christoph Hellwig 2022-01-20 7:12 ` [PATCH v10 3/5] ext4: " Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 7:12 ` [PATCH v10 4/5] f2fs: " Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 7:12 ` [PATCH v10 5/5] fscrypt: update documentation for direct I/O support Eric Biggers 2022-01-20 7:12 ` [f2fs-dev] " Eric Biggers 2022-01-20 8:30 ` [f2fs-dev] [PATCH v10 0/5] add support for direct I/O with fscrypt using blk-crypto Christoph Hellwig 2022-01-20 8:30 ` Christoph Hellwig 2022-01-20 17:10 ` Darrick J. Wong 2022-01-20 17:10 ` [f2fs-dev] " Darrick J. Wong 2022-01-20 20:39 ` Eric Biggers 2022-01-20 20:39 ` [f2fs-dev] " Eric Biggers 2022-01-20 21:00 ` Darrick J. Wong 2022-01-20 21:00 ` [f2fs-dev] " Darrick J. Wong 2022-01-20 22:04 ` Dave Chinner 2022-01-20 22:04 ` [f2fs-dev] " Dave Chinner 2022-01-20 22:48 ` Eric Biggers 2022-01-20 22:48 ` [f2fs-dev] " Eric Biggers 2022-01-20 23:57 ` Dave Chinner 2022-01-20 23:57 ` [f2fs-dev] " Dave Chinner 2022-01-21 2:36 ` Darrick J. Wong 2022-01-21 2:36 ` [f2fs-dev] " Darrick J. Wong 2022-01-21 7:12 ` Christoph Hellwig 2022-01-21 7:12 ` [f2fs-dev] " Christoph Hellwig 2022-01-23 23:03 ` Dave Chinner 2022-01-23 23:03 ` [f2fs-dev] " Dave Chinner 2022-02-09 1:10 ` Eric Biggers 2022-02-09 1:10 ` Eric Biggers 2022-02-10 4:03 ` Dave Chinner 2022-02-10 4:03 ` [f2fs-dev] " Dave Chinner
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=20220120071215.123274-3-ebiggers@kernel.org \ --to=ebiggers@kernel.org \ --cc=chao@kernel.org \ --cc=david@fromorbit.com \ --cc=djwong@kernel.org \ --cc=hch@infradead.org \ --cc=jaegeuk@kernel.org \ --cc=linux-ext4@vger.kernel.org \ --cc=linux-f2fs-devel@lists.sourceforge.net \ --cc=linux-fscrypt@vger.kernel.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-xfs@vger.kernel.org \ --cc=satyat@google.com \ --cc=tytso@mit.edu \ /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: linkBe 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.