From: Chandan Rajendra <chandan@linux.ibm.com>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-ext4@vger.kernel.org, linux-fscrypt@vger.kernel.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 0/2] ext4: support encryption with blocksize != PAGE_SIZE
Date: Fri, 25 Oct 2019 19:00:29 +0530 [thread overview]
Message-ID: <17874972.D0pmjP8EC8@localhost.localdomain> (raw)
In-Reply-To: <20191023033312.361355-1-ebiggers@kernel.org>
On Wednesday, October 23, 2019 9:03 AM Eric Biggers wrote:
> Hello,
>
> This patchset makes ext4 support encryption on filesystems where the
> filesystem block size is not equal to PAGE_SIZE. This allows e.g.
> PowerPC systems to use ext4 encryption.
>
> Most of the work for this was already done in prior kernel releases; now
> the only part missing is decryption support in block_read_full_page().
> Chandan Rajendra has proposed a patchset "Consolidate FS read I/O
> callbacks code" [1] to address this and do various other things like
> make ext4 use mpage_readpages() again, and make ext4 and f2fs share more
> code. But it doesn't seem to be going anywhere.
>
> Therefore, I propose we simply add decryption support to
> block_read_full_page() for now. This is a fairly small change, and it
> gets ext4 encryption with subpage-sized blocks working.
>
> Note: to keep things simple I'm just allocating the work object from the
> bi_end_io function with GFP_ATOMIC. But if people think it's necessary,
> it could be changed to use preallocation like the page-based read path.
>
> Tested with 'gce-xfstests -c ext4/encrypt_1k -g auto', using the new
> "encrypt_1k" config I created. All tests pass except for those that
> already fail or are excluded with the encrypt or 1k configs, and 2 tests
> that try to create 1023-byte symlinks which fails since encrypted
> symlinks are limited to blocksize-3 bytes. Also ran the dedicated
> encryption tests using 'kvm-xfstests -c ext4/1k -g encrypt'; all pass,
> including the on-disk ciphertext verification tests.
I have tested this patchset on ppc64le with both 4k and 64k block size. There
were no regressions. Hence,
Tested-by: Chandan Rajendra <chandan@linux.ibm.com>
--
chandan
next prev parent reply other threads:[~2019-10-25 13:28 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-23 3:33 [PATCH v2 0/2] ext4: support encryption with blocksize != PAGE_SIZE Eric Biggers
2019-10-23 3:33 ` [PATCH v2 1/2] fs/buffer.c: support fscrypt in block_read_full_page() Eric Biggers
2019-10-23 3:33 ` [PATCH v2 2/2] ext4: Enable encryption for subpage-sized blocks Eric Biggers
2019-10-25 13:30 ` Chandan Rajendra [this message]
2019-11-06 21:54 ` [PATCH v2 0/2] ext4: support encryption with blocksize != PAGE_SIZE Eric Biggers
2019-11-11 20:28 ` Eric Biggers
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=17874972.D0pmjP8EC8@localhost.localdomain \
--to=chandan@linux.ibm.com \
--cc=ebiggers@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-fsdevel@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.