Comment 11 for bug 1385755

> This chunk of code may fire reaching some (high enough) nested catalog depth trying to resolve some path to which descriptor for a destination pid (for lsof) belongs.

I don't think resolving (possibly recursive) symlink can yield such a trace. The above mentioned warning is issued
for root dentries only:

2553 global_root:
2554 /*
2555 * Filesystems needing to implement special "root names"
2556 * should do so with ->d_dname()
2557 */
2558 if (IS_ROOT(dentry) &&
2559 (dentry->d_name.len != 1 || dentry->d_name.name[0] != '/')) {
2560 WARN(1, "Root dentry has weird name <%.*s>\n",
2561 (int) dentry->d_name.len, dentry->d_name.name);
2562 }

On the other hand there are no warnings about buffer being too short, or symlink nesting level being too big
(which is pretty normal situation), instead the corresponding error code is returned.

The warning might indicate filesystem problem (say, NFS failed to read its dentries due to network being down).
That said I don't think the trace indicates root filesystem corruption (typically it results in a lot of other easily
visible problems).

However many synthetic filesystems (anonpipefs, sockfs, inotifyfd, eventfd, signalfd, internal tmpfs which implements sys V
shared memory, you name it) have no mount point (so they qualify as a "global root"), and their root dentries might have no sensible names.

Most likely lsof attempts to find out the path corresponding to such a file descriptor. Also stat might race with process exit
(so even if the filesystem in question implements a custom d_name for root dentry, it might give pointless values after
the process has exited).

The bottom line is that the above kernel trace is harmless, and MongoDB has very little to do with that trace.