Hi Jaegeuk, On Fri, Apr 21, 2017 at 10:35:03AM -0700, Jaegeuk Kim wrote: > > > In any case, I guess that unless there are other ideas we can do these patches: > > > > 1.) f2fs patch to start checking the name, as above > > 2.) patch to start encoding last 32 bytes of the name (or second-to-last CTS > > block, I haven't decided yet) rather than last 16 bytes, changing > > fs/crypto/, fs/ext4/, and fs/f2fs/ > > 3.) cleanup patches to introduce helper function and switch ext4 and f2fs to it > > IMO, it'd better to do 3.) followed by 2.), since 2.) already needs to change > fs/crypto which does not give much backporting effort. > That would be ideal, but unfortunately the main users of filesystem encryption are using old kernel versions which don't have fs/crypto/, usually 4.4 at latest. So it would be nice for it to be easier to backport the "use different bytes from the encrypted filename" change to 4.4-stable, as I've been doing for some of the other filesystem encryption fixes. And people do need it, it seems, as it causes real problems like undeletable files; Gwendal is even already trying to merge a fix into some Chrome OS kernel. > > I found one issue in my patch and modified it in f2fs tree [1]. Given next merge > window probable starting next week, let me upstream this modified one first > through f2fs. Then, you can see it in 4.12-rc1 two weeks later, so fscrypt > patches can be easily integrated after then. If you have any concern, I'm also > okay to push this patch through fscrypt. Let me know. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs.git/commit/?h=dev-test&id=1585cfbbb269be6a112e0629a52123c0f9eaf4fa > I think the series through fscrypt makes more sense, though if I don't have it ready soon please go ahead and take the f2fs portion through the f2fs tree. Thanks! - Eric
