Ted + Richard, On Fri, Jun 23, 2017 at 12:09:07PM -0400, Theodore Ts'o wrote: > On Tue, May 23, 2017 at 04:14:20PM +0200, Richard Weinberger wrote: > > On Tue, May 23, 2017 at 2:39 AM, Eric Biggers <ebiggers3@xxxxxxxxx> wrote: > > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > > > Since only an open file can be mmap'ed, and we only allow open()ing an > > > encrypted file when its key is available, there is no need to check for > > > the key again before permitting each mmap(). > > > > > > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > Acked-by: Richard Weinberger <richard@xxxxxx> > > There are some patches that were sent to linux-fscrypt (including this > one) that are specific to ubifs that don't appear to be in linux-next > as of this writing. > > I can include them in the fscrypt tree (which I am updating somewhat > belatedly; sorry, crazy travel schedule has made me be late attending > to fscrypt), but it probably makes more sense for the change to go in > via the ubifs tree. The f2fs version of the "don't bother checking > for encryption key" is already in linux-next, via the f2fs tree, for > example. > > So I'm planning on NOT taking the ubifs-specific patches that are in > the linux-fscrypto patch queue; unless Richard, you want to > specifically ask me to do so. > The mmap and truncate patches were basically the same for each filesystem, but yes it's fine for them to go in separately. Richard, can you take for ubifs: ubifs: don't bother checking for encryption key in ->mmap() ubifs: require key for truncate(2) of encrypted file and Ted can you take for ext4: ext4: don't bother checking for encryption key in ->mmap() ext4: require key for truncate(2) of encrypted file - Eric