CHROMIUM: ecryptfs: sync before truncating lower inode

If the updated ecryptfs header data is not written to disk before
the lower file is truncated, a crash may leave the filesystem
in the state when the lower file truncation is journaled, while
the changes to the ecryptfs header are lost (if the underlying
filesystem is ext4 in data=ordered mode, for example). As a result,
upon remounting and repairing the file may have a pre-truncation
length and garbage data after the post-truncation end.

TEST=Make the snapshots of the underlying ext4 filesystem mounted
     with data=ordered while asynchronously truncating to zero a
     group of files in ecryptfs mounted on top. Mount ecryptfs for
     each of the snapshots and verify thatthey all contain files
     in the consistent state: either with original pre-truncation
     data, or empty. And none of them contains garbage.
     (A more detailed procedure is in the BUG)

Change-Id: If7c05165ea28945fde9072d980e2dfa88133087b
Signed-off-by: Andrey Pronin <>
Reviewed-by: Gwendal Grignou <>
Commit-Queue: Gwendal Grignou <>
Tested-by: Gwendal Grignou <>
3 files changed