Re: [PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto
On Tue, Nov 17, 2020 at 12:15:26PM -0500, Theodore Y. Ts'o wrote: > What is the expected use case for Direct I/O using fscrypt? This > isn't a problem which is unique to fscrypt, but one of the really > unfortunate aspects of the DIO interface is the silent fallback to > buffered I/O. We've lived with this because DIO goes back decades, > and the original use case was to keep enterprise databases happy, and > the rules around what is necessary for DIO to work was relatively well > understood. > > But with fscrypt, there's going to be some additional requirements > (e.g., using inline crypto) required or else DIO silently fall back to > buffered I/O for encrypted files. Depending on the intended use case > of DIO with fscrypt, this caveat might or might not be unfortunately > surprising for applications. > > I wonder if we should have some kind of interface so we can more > explicitly allow applications to query exactly what the requirements > might be for a particular file vis-a-vis Direct I/O. What are the > memory alignment requirements, what are the file offset alignment > requirements, what are the write size requirements, for a particular > file. > (Credit to Eric for the description of use cases that I'm copying/summarizing here). The primary motivation for this patch series is Android - some devices use zram with cold page writeback enabled to an encrypted swap file, so direct I/O is needed to avoid double-caching the data in the swap file. In general, this patch is useful for avoiding double caching any time a loopback device is created in an encrypted directory. We also expect this to be useful for databases that want to use direct I/O but also want to encrypt data at the FS level. I do think having a good way to tell userspace about the DIO requirements would be great to have. Userspace does have ways to access to most, but not all, of the information it needs to figure out the DIO requirements (I don't think userspace has any way of figuring out if inline encryption hardware is available right now), so it would be nice if there was a good/unified API for getting those requirements. Do you think we'll need that before these patches can go in though? I do think the patches as is are useful for their primary use case even without the ability to explicitly query for the DIO requirements, because Android devices are predictable w.r.t inline encryption support (devices ship with either blk-crypto-fallback or have inline encryption hardware, and the patchset's requirements are met in either case). And even when used on machines without such predictability, this patch is at worst the same as the current situation, and at best an improvement. > - Ted
Re: [PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto
On Tue, Nov 17, 2020 at 02:07:00PM +, Satya Tangirala wrote: > This patch series was tested by running xfstests with test_dummy_encryption > with and without the 'inlinecrypt' mount option, and there were no > meaningful regressions. One regression was for generic/587 on ext4, > but that test isn't compatible with test_dummy_encryption in the first > place, and the test "incorrectly" passes without the 'inlinecrypt' mount > option - a patch will be sent out to exclude that test when > test_dummy_encryption is turned on with ext4 (like the other quota related > tests that use user visible quota files). It would be helpful to have some more testing results that show that the direct I/O support is really working as intended, especially in the new case where logical_block_size < data_unit_size and buffers are only logical_block_size aligned --- both with real hardware and with blk-crypto-fallback. Using my patchset https://lkml.kernel.org/r/20201112194011.103774-1-ebigg...@kernel.org it should be possible to test with real eMMC inline encryption hardware on Snapdragon 630; it has logical_block_size=512. Also note, generic/587 was already added to the ext4/encrypt and ext4/encrypt_1k exclusion lists by xfstests-bld commit 02e4bfe628b4. - Eric
Re: [PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto
On Tue, Nov 17, 2020 at 12:15:26PM -0500, Theodore Y. Ts'o wrote: > What is the expected use case for Direct I/O using fscrypt? This > isn't a problem which is unique to fscrypt, but one of the really > unfortunate aspects of the DIO interface is the silent fallback to > buffered I/O. We've lived with this because DIO goes back decades, > and the original use case was to keep enterprise databases happy, and > the rules around what is necessary for DIO to work was relatively well > understood. > > But with fscrypt, there's going to be some additional requirements > (e.g., using inline crypto) required or else DIO silently fall back to > buffered I/O for encrypted files. Depending on the intended use case > of DIO with fscrypt, this caveat might or might not be unfortunately > surprising for applications. > > I wonder if we should have some kind of interface so we can more > explicitly allow applications to query exactly what the requirements > might be for a particular file vis-a-vis Direct I/O. What are the > memory alignment requirements, what are the file offset alignment > requirements, what are the write size requirements, for a particular > file. In Ye Olde days there was XFS_IOC_DIOINFO to communicate all that (xfs hardcodes 512b file offset alignment), but in this modern era perhaps it's time to shovel that into statx... --D > > - Ted
Re: [PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto
What is the expected use case for Direct I/O using fscrypt? This isn't a problem which is unique to fscrypt, but one of the really unfortunate aspects of the DIO interface is the silent fallback to buffered I/O. We've lived with this because DIO goes back decades, and the original use case was to keep enterprise databases happy, and the rules around what is necessary for DIO to work was relatively well understood. But with fscrypt, there's going to be some additional requirements (e.g., using inline crypto) required or else DIO silently fall back to buffered I/O for encrypted files. Depending on the intended use case of DIO with fscrypt, this caveat might or might not be unfortunately surprising for applications. I wonder if we should have some kind of interface so we can more explicitly allow applications to query exactly what the requirements might be for a particular file vis-a-vis Direct I/O. What are the memory alignment requirements, what are the file offset alignment requirements, what are the write size requirements, for a particular file. - Ted
[PATCH v7 0/8] add support for direct I/O with fscrypt using blk-crypto
This patch series adds support for direct I/O with fscrypt using blk-crypto. It has been rebased on fscrypt/master (i.e. the "master" branch of the fscrypt tree at https://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git) Patch 1 ensures that bios are not split in the middle of a crypto data unit. Till now, blk-crypto expected the offset and length of each bvec in a bio to be aligned to the crypto data unit size. Patch 2 enables blk-crypto-fallback to work without this requirement. It also relaxes the alignment requirement that blk-crypto checks for - now, blk-crypto only requires that the length of the I/O is aligned to the crypto data unit size. Patch 3 adds two functions to fscrypt that need to be called to determine if direct I/O is supported for a request. Patches 4 and 5 modify direct-io and iomap respectively to set bio crypt contexts on bios when appropriate by calling into fscrypt. Patches 6 and 7 allow ext4 and f2fs direct I/O to support fscrypt without falling back to buffered I/O. Patch 8 updates the fscrypt documentation for direct I/O support. The documentation now notes the required conditions for inline encryption and direct I/O on encrypted files. This patch series was tested by running xfstests with test_dummy_encryption with and without the 'inlinecrypt' mount option, and there were no meaningful regressions. One regression was for generic/587 on ext4, but that test isn't compatible with test_dummy_encryption in the first place, and the test "incorrectly" passes without the 'inlinecrypt' mount option - a patch will be sent out to exclude that test when test_dummy_encryption is turned on with ext4 (like the other quota related tests that use user visible quota files). Changes v6 => v7: - add patches 1 and 2 to allow blk-crypto to work with user buffers not aligned to crypto data unit size, so that direct I/O doesn't require that alignment either. - some cleanups Changes v5 => v6: - fix bug with fscrypt_limit_io_blocks() and make it ready for 64 bit block numbers. - remove Reviewed-by for Patch 1 due to significant changes from when the Reviewed-by was given. Changes v4 => v5: - replace fscrypt_limit_io_pages() with fscrypt_limit_io_block(), which is now called by individual filesystems (currently only ext4) instead of the iomap code. This new function serves the same end purpose as the one it replaces (ensuring that DUNs within a bio are contiguous) but operates purely with blocks instead of with pages. - make iomap_dio_zero() set bio_crypt_ctx's again, instead of just a WARN_ON() since some folks prefer that instead. - add Reviewed-by's Changes v3 => v4: - Fix bug in iomap_dio_bio_actor() where fscrypt_limit_io_pages() was being called too early (thanks Eric!) - Improve comments and fix formatting in documentation - iomap_dio_zero() is only called to zero out partial blocks, but direct I/O is only supported on encrypted files when I/O is blocksize aligned, so it doesn't need to set encryption contexts on bios. Replace setting the encryption context with a WARN_ON(). (Eric) Changes v2 => v3: - add changelog to coverletter Changes v1 => v2: - Fix bug in f2fs caused by replacing f2fs_post_read_required() with !fscrypt_dio_supported() since the latter doesn't check for compressed inodes unlike the former. - Add patches 6 and 7 for fscrypt documentation - cleanups and comments Eric Biggers (5): fscrypt: add functions for direct I/O support direct-io: add support for fscrypt using blk-crypto iomap: support direct I/O with fscrypt using blk-crypto ext4: support direct I/O with fscrypt using blk-crypto f2fs: support direct I/O with fscrypt using blk-crypto Satya Tangirala (3): block: ensure bios are not split in middle of crypto data unit blk-crypto: don't require user buffer alignment fscrypt: update documentation for direct I/O support Documentation/filesystems/fscrypt.rst | 21 ++- block/bio.c | 1 + block/blk-crypto-fallback.c | 212 +++--- block/blk-crypto-internal.h | 18 +++ block/blk-crypto.c| 19 +-- block/blk-merge.c | 96 ++-- block/blk-mq.c| 3 + block/bounce.c| 4 + fs/crypto/crypto.c| 8 + fs/crypto/inline_crypt.c | 74 + fs/direct-io.c| 15 +- fs/ext4/file.c| 10 +- fs/ext4/inode.c | 7 + fs/f2fs/f2fs.h| 6 +- fs/iomap/direct-io.c | 6 + include/linux/fscrypt.h | 18 +++ 16 files changed, 431 insertions(+), 87 deletions(-) -- 2.29.2.299.gdc1121823c-goog