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:
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:
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...
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 738e1e11bc90d6e 2cf9c6e20e 4c986cbdf7d2713 0e0545f02c
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/ vm/drop_ caches && hexdump -C foo
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...