Ted, Eric, Am 23.06.2017 um 19:18 schrieb Eric Biggers: > 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 Alright, I'll carry them. :-) The plan is that the fscrypt tree will just contain fscrypt "core" patches and global changes/cleanups go thought the individual filesystem trees, right? Thanks, //richard
