[PATCH 0/1][Oneiric][SRU] eCryptfs: Revert to a writethrough cache model

Colin King colin.king at canonical.com
Mon Aug 20 11:59:57 UTC 2012

From: Colin Ian King <colin.king at canonical.com>

BugLink: http://bugs.launchpad.net/bugs/1034012

SRU justification:


A change was made about a year ago to get eCryptfs to better utilize its
page cache during writes. The idea was to do the page encryption
operations during page writeback, rather than doing them when initially
writing into the page cache, to reduce the number of page encryption
operations during sequential writes. This meant that the encrypted page
would only be written to the lower filesystem during page writeback,
which was a change from how eCryptfs had previously wrote to the lower
filesystem in ecryptfs_write_end().

The change caused a few eCryptfs-internal bugs that were shook out.
Unfortunately, more grave side effects have been identified that will
force changes outside of eCryptfs. Because the lower filesystem isn't
consulted until page writeback, eCryptfs has no way to pass lower write
errors (ENOSPC, mainly) back to userspace. Additionaly, it was reported
that quotas could be bypassed because of the way eCryptfs may sometimes
open the lower filesystem using a privileged kthread.


Backport of upstream commit 821f7494a77627fb1ab539591c57b22cdca702d6

This reverts:
32001d6f "eCryptfs: Flush file in vma close"
5be79de2 "eCryptfs: Flush dirty pages in setattr"
57db4e8d "ecryptfs: modify write path to encrypt page in writepage"


(test enospc.sh)

sudo mkdir /lower /upper /tmp/image
sudo ./tests/run_tests.sh -K -c safe -b 100000 -D /tmp/image -l /lower -u /upper -t enospc.sh

Without the fix, this test fails. With the fix, it passes.

Colin Ian King (1):
  eCryptfs: Revert to a writethrough cache model

 fs/ecryptfs/file.c  |   32 ++------------------------------
 fs/ecryptfs/inode.c |    6 ------
 fs/ecryptfs/mmap.c  |   39 +++++++++++++--------------------------
 3 files changed, 15 insertions(+), 62 deletions(-)


More information about the kernel-team mailing list