I have added the linux-nfs list to hopefully add a wider interested audience. Sven Geggus <lists@xxxxxxxxxxxxxxxxxxxxx> writes: > Hello, > > I have a couple of machines running Debian GNU/Linux 8 using an NFS-ro-mounted > root filesystem. > > The systems seem to get bitten by VFS changes in some (unfortunaly > somewhat difficult to reproduce) circumstances. > > The effect is, that /dev (dectmpfs) gets unmounted for some strange reason. > > I added the following debug code to fs/namespace.c > > printk(KERN_DEBUG "%s: %s\n", __func__, dentry->d_name.name); > dump_stack(); > > And this is what I get if one of those events happen: The only way to get to d_invalidate in lookup_fast is if d_revalidate fails. Which yields two functions to look at: nfs_lookup_revalidate and nfs4_lookup_revalidate If what is being revalidated is a mount point nfs4_lookup_revalidate calls nfs_lookup_revalidate. So nfs_lookup_revalidate is the only interesting function. The last round of this was with readdir having problems and invalidating the dcache. So now apparently we are down to something weird happening in revalidate. I don't understand the what nfs_lookup_revalidate is doing particularly well. However it appears that if you enable the kconfig SUNRPC_DEBUG option there will be more relevant information. I am not certain what more to print out that SUNRPC_DEBUG won't, but I have verified that SUNRPC_DEBUG will report when a failure path is hit in nfs_lookup_revalidate and which failure path was hit (out_bad or out_error). Which should be sufficient to start narrowing down what is happening even further. I hope that helps a little bit in tracking down what is happening. Eric > __detach_mounts: dev > CPU: 1 PID: 5551 Comm: modtrack Not tainted 4.1.3-debug-00287-g0fe8050-dirty #1 > Hardware name: Dell Inc. Precision WorkStation T3400 /0TP412, BIOS A03 01/31/2008 > ffff880127183c18 ffff880127183bc8 ffffffff815605f8 ffff88012bc4fcb0 > ffff880126c16198 ffff880127183bf8 ffffffff81106cf7 000000000000000f > ffff880126c16198 ffff880127183c18 ffff880127183d00 ffff880127183c48 > Call Trace: > [<ffffffff815605f8>] dump_stack+0x4c/0x6e > [<ffffffff81106cf7>] __detach_mounts+0x2b/0x12c > [<ffffffff810ffbb6>] d_invalidate+0x9a/0xc8 > [<ffffffff810f6b13>] lookup_fast+0x1f5/0x26f > [<ffffffff810f6dba>] do_last.isra.43+0xd6/0x9fb > [<ffffffff810f916e>] path_openat+0x1d1/0x53e > [<ffffffff810f9f41>] ? user_path_at_empty+0x63/0x93 > [<ffffffff810f9fe6>] do_filp_open+0x35/0x85 > [<ffffffff811f1893>] ? find_next_zero_bit+0x17/0x1d > [<ffffffff81104225>] ? __alloc_fd+0xdd/0xef > [<ffffffff810ec966>] do_sys_open+0x146/0x1d5 > [<ffffffff810eca1f>] SyS_openat+0xf/0x11 > [<ffffffff81565a17>] system_call_fastpath+0x12/0x6a > > Regards > > Sven > > P.S.: Kernel is vanilla 4.1.3 with aufs patches, but aufs is not related in > this problem. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
