ecryptfs_create leaves empty file in lower directory upon failure

[Tyler Hicks]

ecryptfs_initialize_file() takes an empty file in the lower mount and turns it into an eCryptfs file by writing out the eCryptfs metadata. If ecryptfs_initialize_file() fails, ecryptfs_create() will also fail, but the empty file will remain around. We should be doing better cleanup to get rid of the empty file upon failure.

To reproduce:
---
gentoo-virt mnt # mount -it ecryptfs /mnt/.ecryptfs-ext3 /mnt/ecryptfs-ext3/ -o \
ecryptfs_sig=7fa06f4b66fcde02,ecryptfs_cipher=camellia,ecryptfs_key_bytes=16,rw,noauto
gentoo-virt ecryptfs-ext3 # echo "camellia cipher test" > /mnt/ecryptfs-ext3/test
-bash: /mnt/ecryptfs-ext3/test: Invalid argument
---

Relevant log entries:
---
Mar 6 10:15:57 gentoo-virt kernel: write_tag_3_packet: Unable to generate code for cipher [camellia]
Mar 6 10:15:57 gentoo-virt kernel: ecryptfs_generate_key_packet_set: Error writing tag 3 packet
Mar 6 10:15:57 gentoo-virt kernel: ecryptfs_write_headers_virt: Error generating key packet set; rc = [-22]
Mar 6 10:15:57 gentoo-virt kernel: ecryptfs_write_metadata: Error whilst writing headers; rc = [-22]
Mar 6 10:15:57 gentoo-virt kernel: Error writing headers; rc = [-22]
---

Note that the steps to reproduce are taking advantage of another bug that allows invalid ciphers to be specified at mount time. I should probably open another bug for proper cipher support in eCryptfs at mount.

[Tyler Hicks (tyhicks)]

Oops, forgot to show that the empty file was still there after the echo failed:
---
gentoo-virt mnt # du -h /mnt/ecryptfs-ext3/test /mnt/.ecryptfs-ext3/test
0 /mnt/ecryptfs-ext3/test
0 /mnt/.ecryptfs-ext3/test
---

Here's the expected output after a successful create in an eCryptfs mount:
---
gentoo-virt mnt # du -h /mnt/ecryptfs-ext3/test /mnt/.ecryptfs-ext3/test
0 /mnt/ecryptfs-ext3/test
12K /mnt/.ecryptfs-ext3/test
---

[Lasse Kärkkäinen (tronic+mb48)]

Problems observed when running out of disk space:

- Corrupted file being created, causes these messages when reading:

[20487.078883] Valid eCryptfs headers not found in file header region or xattr region
[20487.078888] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

(sorry, don't have a log of the messages given when actually writing)

- Several minutes of I/O blocking for applications trying to write:

[20521.101463] INFO: task transmission:7651 blocked for more than 120 seconds.
[20521.101467] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[20521.101469] transmission D 00000000ffffffff 0 7651 1 0x00000000
[20521.101474] ffff8800c098dc38 0000000000000086 0000000000000000 0000000000015880
[20521.101478] ffff8801add2c7c0 0000000000015880 0000000000015880 0000000000015880
[20521.101482] 0000000000015880 ffff8801add2c7c0 0000000000015880 0000000000015880
[20521.101486] Call Trace:
[20521.101494] [<ffffffff810da710>] ? sync_page+0x0/0x50
[20521.101498] [<ffffffff81527458>] io_schedule+0x28/0x40
[20521.101501] [<ffffffff810da74d>] sync_page+0x3d/0x50
[20521.101504] [<ffffffff81527a42>] __wait_on_bit_lock+0x52/0xb0
[20521.101507] [<ffffffff810da6f2>] __lock_page+0x62/0x70
[20521.101511] [<ffffffff81078b70>] ? wake_bit_function+0x0/0x40
[20521.101515] [<ffffffff810e4c6d>] ? pagevec_lookup+0x1d/0x30
[20521.101518] [<ffffffff810e6510>] truncate_inode_pages_range+0x3e0/0x3f0
[20521.101523] [<ffffffff81276c02>] ? radix_tree_gang_lookup_slot+0x72/0xb0
[20521.101526] [<ffffffff810e6530>] truncate_inode_pages+0x10/0x20
[20521.101529] [<ffffffff8113535e>] generic_delete_inode+0x16e/0x1a0
[20521.101532] [<ffffffff8113418d>] iput+0x5d/0x70
[20521.101535] [<ffffffff81130fb8>] dentry_iput+0x88/0x100
[20521.101537] [<ffffffff8113112f>] d_kill+0x3f/0x70
[20521.101540] [<ffffffff81132a2b>] dput+0x9b/0x190
[20521.101543] [<ffffffff8112078c>] __fput+0x17c/0x210
[20521.101545] [<ffffffff8112083d>] fput+0x1d/0x30
[20521.101548] [<ffffffff8111cab8>] filp_close+0x58/0x90
[20521.101551] [<ffffffff8111cba9>] sys_close+0xb9/0x110
[20521.101555] [<ffffffff81012002>] system_call_fastpath+0x16/0x1b

- The application does not get reported ENOSPC as it should

[Tim Sally (tsally)]

Taking a look at this today.

[Tyler Hicks (tyhicks)]

Hey Tim - I fixed this bug and the patch is sitting in the eCryptfs next branch, waiting for the 3.6 merge window.

I didn't tag the patch with this bug, but with a newer bug for the same problem. Here's where the patch went out to the mailing list:

http://thread.gmane.org/gmane.comp.file-systems.ecryptfs.general/230