removing file causes kernel bug trace
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eCryptfs |
New
|
Undecided
|
Unassigned |
Bug Description
I have an ecryptfs encrypted folder in my Dropbox folder. It is mounted as such:
/home/orf/Dropbox/e /home/orf/e ecryptfs rw,ecryptfs_
I've xxxx'ed out the actual sigs.
I also have the same folder mounted in the same exact way on other Linux (Fedora 17) machines that are also running Dropbox. I did this by installing ecryptfs-utils and attempting to mount it after putting the above line in /etc/fstab, and following the usual prompts and entering the password that it was encrypted with on the first machine. And then files are available, and I can view them etc.
Today the following happened. I "touched" a file (call it foo) on one machine (the machine the share was created on). It appeared shortly thereafter on another machine via the Dropbox sync. Shortly thereafter when I attempted to remove the empty file on the second machine (rm foo), it segfaulted and the following appeared in /var/log/messages:
[2720931.218807] ------------[ cut here ]------------
[2720931.218812] kernel BUG at fs/namei.c:2186!
[2720931.218814] invalid opcode: 0000 [#1] SMP
[2720931.218817] Modules linked in: ecryptfs encrypted_keys trusted tpm tpm_bios vfat fat fuse bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables pl2303 snd_hda_
[2720931.218872] CPU 0
[2720931.218876] Pid: 31461, comm: rm Tainted: P O 3.6.11-
[2720931.218878] RIP: 0010:[<
[2720931.218885] RSP: 0018:ffff8800b3
[2720931.218887] RAX: ffff88020f9849c0 RBX: ffff8801244cdfa0 RCX: 0000000000000060
[2720931.218889] RDX: 0000000000000000 RSI: ffff8800a452f600 RDI: ffff8802227a3b20
[2720931.218891] RBP: ffff8800b3531dd8 R08: 0000000000000000 R09: 0000000000000000
[2720931.218893] R10: ffff880090136780 R11: 0000000000000000 R12: ffff8800a452f600
[2720931.218895] R13: ffff8802227a3b20 R14: 0000000000000000 R15: ffff88007894ed00
[2720931.218897] FS: 00007f68a22b174
[2720931.218899] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[2720931.218901] CR2: 0000003e800e60f0 CR3: 0000000036b70000 CR4: 00000000000407f0
[2720931.218903] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[2720931.218905] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[2720931.218907] Process rm (pid: 31461, threadinfo ffff8800b3530000, task ffff88021fb84530)
[2720931.218908] Stack:
[2720931.218910] ffff88004d5c4f00 ffff8800a452f600 ffff8802227a3b20 ffff880090136780
[2720931.218913] ffff8800b3531e08 ffffffff8119dbd6 ffff8800b3531e08 ffff88004d5c4f00
[2720931.218917] ffff8800a452f600 ffff8802227a3b20 ffff8800b3531e58 ffffffffa0f7286b
[2720931.218920] Call Trace:
[2720931.218925] [<ffffffff8119d
[2720931.218931] [<ffffffffa0f72
[2720931.218936] [<ffffffffa0f72
[2720931.218938] [<ffffffff8119d
[2720931.218941] [<ffffffff8119d
[2720931.218946] [<ffffffff810d8
[2720931.218949] [<ffffffff811a0
[2720931.218953] [<ffffffff81627
[2720931.218955] Code: 0f 1f 84 00 00 00 00 00 41 bd fe ff ff ff eb 9e 0f 1f 84 00 00 00 00 00 41 bd ec ff ff ff eb 8e 41 bd eb ff ff ff e9 83 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 48 83 ec 20
[2720931.218988] RIP [<ffffffff8119d
[2720931.218991] RSP <ffff8800b3531db8>
[2720931.218994] ---[ end trace b9095fcbe7fc61ac ]---
I had to reboot the machine to unmount the ecryptfs partition.
Note, the machines were not running the exact same kernel version - the first machine was running 3.7.3-101.