© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
67d34a1
(Get the code!)
This turned out to be a tricky one. It is definitely an eCryptfs bug. The upstream fix that I thought would solve this issue ended up not being the right fix. Instead, it turned out to be the following two commits:
bd4f0fe8bb7c73c
fed8859b3ab9427
However, I didn't write those patches as bug fixes. I was simply cleaning out some crufty looking code. It turned out to be buggy code, too.
Creating a file, extending that file, the file's pages being reclaimed, finally followed by reading the file is what triggers this. In the case of this bug report, the system being under memory pressure is what forced the file's pages out of the page cache.
The easiest way to reproduce the bug is with the following shell commands:
$ touch foo && truncate -s 4096 foo && sync && echo 1 | sudo tee /proc/sys/
hexdump should show a file filled with zeroes, but it doesn't.
Data corruption is a possibility if the file is written to before the eCryptfs directory is unmounted.
It looks like all kernels before 2.6.39 are affected, possibly all the way back to the beginning of eCryptfs being merged upstream. Patch, with all the technical eCryptfs details in the commit message, to follow...