Description of problem: I've noticed this when I played with creating nodes (`mknod') in directory shielded by ecryptfs: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 IP: [<ffffffffa03e909a>] ecryptfs_d_revalidate+0x3a/0x88 [ecryptfs] PGD 64528067 PUD 538c0067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/fs/ecryptfs/version CPU 1 Modules linked in: cast6 cast5 twofish_x86_64 twofish_common blowfish aes_x86_64 aes_generic des_generic ecb ecryptfs fuse ipt_MASQUERADE iptable_nat nf_nat sco bridge stp llc bnep l2cap bluetooth irnet ppp_generic slhc irtty_sir sir_dev ircomm_tty ircomm irda crc_ccitt coretemp nfs lockd nfs_acl auth_rpcgss sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 p4_clockmod speedstep_lib freq_table dm_multipath kvm_intel kvm uinput snd_hda_codec_idt snd_hda_intel snd_hda_codec ppdev snd_hwdep snd_pcm snd_timer iTCO_wdt dcdbas parport_pc i5k_amb i2c_i801 snd iTCO_vendor_support serio_raw hwmon i5000_edac parport edac_core soundcore tg3 shpchp snd_page_alloc nouveau drm i2c_algo_bit i2c_core [last unloaded: freq_table] Pid: 4930, comm: mknod Not tainted 2.6.29.2-126.fc11.x86_64 #1 Precision WorkStation 490 RIP: 0010:[<ffffffffa03e909a>] [<ffffffffa03e909a>] ecryptfs_d_revalidate+0x3a/0x88 [ecryptfs] RSP: 0018:ffff8800539fbd08 EFLAGS: 00010286 RAX: ffffffffa03ffb50 RBX: 0000000000000000 RCX: 000000000000006f RDX: ffff88007a0d6300 RSI: 0000000000000000 RDI: ffff88004b12b9c0 RBP: ffff8800539fbd38 R08: ffff8800539fbc88 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88004b12bcc0 R13: ffff880046c93840 R14: 0000000000000000 R15: ffff880046c94380 FS: 00007fb48a64c790(0000) GS:ffff88007e7ae500(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 0000000079847000 CR4: 00000000000026e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process mknod (pid: 4930, threadinfo ffff8800539fa000, task ffff880046c5ae00) Stack: ffff880046c93840 0000000000000003 ffff88004b12bcc0 ffff8800539fbda8 ffff880046c93840 0000000000000000 ffff8800539fbd58 ffffffff810dca98 ffff88004b12bf00 ffff8800539fbda8 ffff8800539fbd98 ffffffff810dccb9 Call Trace: [<ffffffff810dca98>] do_revalidate+0x18/0x4d [<ffffffff810dccb9>] __lookup_hash+0x87/0xf1 [<ffffffff8117f65b>] ? security_inode_permission+0x21/0x23 [<ffffffff810dea7a>] lookup_one_len+0x75/0x85 [<ffffffffa03eacf9>] ecryptfs_lookup+0x85/0x180 [ecryptfs] [<ffffffff810dccfc>] __lookup_hash+0xca/0xf1 [<ffffffff8117f65b>] ? security_inode_permission+0x21/0x23 [<ffffffff810dddae>] lookup_hash+0x3b/0x3f [<ffffffff810dde00>] lookup_create+0x4e/0x94 [<ffffffff810dfd9e>] sys_mknodat+0x59/0x20b [<ffffffff813ab03d>] ? trace_hardirqs_off_thunk+0x3a/0x6c [<ffffffff810885b6>] ? audit_syscall_entry+0x11e/0x14a [<ffffffff810dff6a>] sys_mknod+0x1a/0x1c [<ffffffff8101133a>] system_call_fastpath+0x16/0x1b Code: 0f 1f 44 00 00 48 8b 87 98 00 00 00 49 89 fc 48 89 f3 48 8b 78 08 48 8b 10 48 8b 87 88 00 00 00 48 85 c0 74 44 48 83 38 00 74 3e <4c> 8b 76 08 4c 8b 2e 48 89 7e 08 48 89 16 48 8b 87 88 00 00 00 RIP [<ffffffffa03e909a>] ecryptfs_d_revalidate+0x3a/0x88 [ecryptfs] RSP <ffff8800539fbd08> CR2: 0000000000000008 ---[ end trace dca96c1ffb0dc0f8 ]--- Dunno, how to reliably reproduce it but I guess I mounted few times secret/ dir on top of itself mount.ecryptfs secret/ secret -o ... and then created the node and then mounted. After some time unmounting is not possible. Not sure which command produced the trace. Version-Release number of selected component (if applicable): Linux dhcp-lab-124.englab.brq.redhat.com 2.6.29.2-126.fc11.x86_64 #1 SMP Mon May 4 04:46:15 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux ecryptfs-utils-75-1.fc11.x86_64 (from Koji, not in Rawhide yet) How reproducible: often...
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.