Ack'd and applied to master-next for Quantal, Precise, and Oneiric.
On 09/15/2012 12:10 PM, Colin King wrote:
> From: Colin Ian King <firstname.lastname@example.org>
> BugLink: http://launchpad.net/bugs/561129
> SRU for Oneiric and Precise, and please apply to Quantal too.
> == SRU Justification ==
> == Impact ==
> This bug is the result of existing eCryptfs inodes not
> being evicted when they are the target of a rename()
> syscall. The existing inodes are left around, meaning
> that the lower inodes are also left around, until the
> eCryptfs filesystem in unmounted. This means that disk
> space is not properly freed when mv'ing a file on top
> of another file.
> This can be triggered for example by:
> 1 - Try to download some Ubuntu DVD versions with bit
> torrent (so it reserves space).
> 2 - Fill your disk to the maximum and leave something
> like 5GB.
> 3 - Wait
> 4 - Disk space will go to 0 (it doesn't make any sense
> since space has already been reserved)
> 5 - Ctrl+Alt+F1
> There we can see some messages about ecryptfs :
> ecryptfs_write_lower: octets_written [-28]; expected 
> ecryptfs_encrypt_page: Error Attempting to write lower page; rc = [-22
> == Fix ==
> Apply commit 8335eafc2859e1a26282bef7c3d19f3d68868b8a
> == Test Case ==
> Can be tested on various file systems using the ecryptfs tests (from
> sudo mkdir /tmp/image /lower /upper
> sudo ./tests/run_tests.sh -K -c safe -b 1000000 -D /tmp/image
> -l /lower -u /upper -f ext2,ext3,ext4,xfs,btrfs -t lp-561129.sh
> Without the fix, this fails, with the fix it passes.
> Tyler Hicks (1):
> eCryptfs: Copy up attributes of the lower target inode after rename
> fs/ecryptfs/inode.c | 5 +++++
> 1 file changed, 5 insertions(+)
kernel-team mailing list