From: "Theodore Ts'o" <tytso@mit.edu>
To: Eric Biggers <ebiggers@google.com>
Cc: Richard Weinberger <richard@nod.at>,
adilger.kernel@dilger.ca, linux-kernel@vger.kernel.org,
linux-ext4@vger.kernel.org, david@sigma-star.at,
jaegeuk@kernel.org
Subject: Re: [PATCH] ext4: Check for encryption feature before fscrypt_process_policy()
Date: Thu, 22 Sep 2016 18:38:03 -0400 [thread overview]
Message-ID: <20160922223803.ggz2qodtqtht7oot@thunk.org> (raw)
In-Reply-To: <20160922194931.GA53380@google.com>
On Thu, Sep 22, 2016 at 12:49:31PM -0700, Eric Biggers wrote:
>
> Ted had actually pointed out that the reason this hasn't already been fixed is
> that some users, e.g. Android, do not set the feature flag but still expect the
> filesystem encryption code to work. Maybe he can chime in with regards to when
> (if ever) it would make sense to make this change.
I think it's fine to fix it now in upstream. It might cause some
problems for Cyanogen developers if they want to try to use an
upstream kernel and also enable the ext4 encryption feature, but the
fix to make_ext4fs isn't all that hard.
> Also, it seems the default block size for mkfs.ext4 is determined by a heuristic
> and isn't guaranteed to be 1 KiB. So the commit message probably should say
> something more general like "filesystems created with a block size other than
> PAGE_SIZE".
In fact mke2fs only uses 1k block sizes for filessystems smaller than
512M. If you were take a census of all ext4 file systems out there,
the most common block size you would see is 4k.
Cheers,
- Ted
next prev parent reply other threads:[~2016-09-22 22:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-22 6:50 Richard Weinberger
2016-09-22 19:49 ` Eric Biggers
2016-09-22 20:17 ` Richard Weinberger
2016-09-22 22:38 ` Theodore Ts'o [this message]
2016-09-23 21:56 ` Eric Biggers
2016-09-30 5:53 ` Theodore Ts'o
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=20160922223803.ggz2qodtqtht7oot@thunk.org \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=david@sigma-star.at \
--cc=ebiggers@google.com \
--cc=jaegeuk@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=richard@nod.at \
/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
all inboxes | Powered by JetHome®