Bug 766277

Summary: WARNING: at fs/dcache.c:2460 prepend_path+0x11b/0x131() (proc_pid_readlink)
Product: [Fedora] Fedora Reporter: Gajdos Tamás <gajdipajti>
Component: kernelAssignee: Jeff Layton <jlayton>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 16CC: aviro, bmason, clancy.kieran+redhat, dima_skok, edgar.hoch, flokip, gansalmon, itamar, jacek.luczak, jeremy, jlayton, jonathan, kernel-maint, lst_manage, madhu.chinakonda, mailings, mertensb.mazda, paul, pportant, rwheeler, steved
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:146444af0b0ab68826d246da80c40e66dbce4e57
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-01-15 00:20:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: smolt_data
none
All logs saved & uploaded none

Description Gajdos Tamás 2011-12-11 13:00:02 UTC
libreport version: 2.0.7
abrt_version:   2.0.6
cmdline:        BOOT_IMAGE=/vmlinuz-3.1.0-7.fc16.x86_64 root=UUID=8b7c4d77-01ab-464c-ab36-c2549b1a5c78 ro rd.md=0 rd.lvm=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=hu_HU.UTF-8 KEYTABLE=hu
kernel:         3.1.0-7.fc16.x86_64
reason:         WARNING: at fs/dcache.c:2460 prepend_path+0x11b/0x131()
time:           2011. dec.  8., csütörtök, 17.56.47 CET

smolt_data:     Text file, 2871 bytes

backtrace:
:WARNING: at fs/dcache.c:2460 prepend_path+0x11b/0x131()
:Hardware name: System Product Name
:Root dentry has weird name <>
:Modules linked in: ppdev parport_pc lp parport fuse nfs fscache auth_rpcgss nfs_acl via drm lockd ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_filter nf_conntrack_tftp ip6_tables nf_conntrack snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device joydev snd_pcm via_rhine snd_timer snd mii soundcore snd_page_alloc shpchp asus_atk0110 i2c_viapro i2c_core microcode sunrpc xfs pata_acpi ata_generic pata_via sata_via [last unloaded: scsi_wait_scan]
:Pid: 6635, comm: abrt-hook-ccpp Not tainted 3.1.0-7.fc16.x86_64 #1
:Call Trace:
: [<ffffffff81057a4e>] warn_slowpath_common+0x83/0x9b
: [<ffffffff81057b09>] warn_slowpath_fmt+0x46/0x48
: [<ffffffff81139190>] prepend_path+0x11b/0x131
: [<ffffffff81139216>] path_with_deleted+0x70/0x79
: [<ffffffff8113a40d>] d_path+0xa1/0xc6
: [<ffffffff81175f03>] proc_pid_readlink+0x71/0xcf
: [<ffffffff8112cd36>] sys_readlinkat+0x73/0x95
: [<ffffffff8112cd73>] sys_readlink+0x1b/0x1d
: [<ffffffff814bc482>] system_call_fastpath+0x16/0x1b

event_log:
:2011-12-11-13:58:01> Smolt profile successfully saved
:2011-12-11-13:58:51> Submitting oops report to http://submit.kerneloops.org/submitoops.php
:2011-12-11-13:59:54  Kernel oops has not been sent due to Couldn't connect to server
:2011-12-11-13:59:54* (exited with 1)

Comment 1 Gajdos Tamás 2011-12-11 13:00:06 UTC
Created attachment 545232 [details]
File: smolt_data

Comment 2 Eric Sandeen 2011-12-12 23:08:06 UTC
:Root dentry has weird name <>

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

i.e. looks like d_name.name is an empty string?

The process issuing the warning was abrt-hook-ccpp, can you look in your logs and see if there was some other event just prior to this one ...

thanks,
-Eric

Comment 3 Gajdos Tamás 2011-12-14 17:42:21 UTC
Created attachment 546839 [details]
All logs saved & uploaded

If you need anything, please ask.

Comment 4 Eric Sandeen 2011-12-14 18:48:02 UTC
Thanks!

One interesting thing is that it looks like a hibernate or suspend failed just a bit before this:

Dec  8 17:56:35 szikk-g1l kernel: [ 6743.187836] PM: Syncing filesystems ... done.
Dec  8 17:56:35 szikk-g1l kernel: [ 6744.368274] Freezing user space processes ...
Dec  8 17:56:35 szikk-g1l kernel: [ 6764.377125] Freezing of tasks failed after 20.00 seconds (1 tasks refusing to freeze, wq_busy=0):
...
Dec  8 17:56:35 szikk-g1l kernel: [ 6764.377818] Restarting tasks ...

And then just a bit later:

Dec  8 17:56:47 szikk-g1l kernel: [ 6775.541271] ------------[ cut here ]------------
Dec  8 17:56:47 szikk-g1l kernel: [ 6775.541290] WARNING: at fs/dcache.c:2460 prepend_path+0x11b/0x131()

maybe error handling from a failed suspend is fubar...

It's not clear what triggered abrt though... not sure if it matters....

Comment 5 Gajdos Tamás 2011-12-14 19:03:08 UTC
I closed the bug, because it is not connected to the kernel. It is in connection with the new NIS+NFS centralized home folder mounts with aufs, which I've been trying/testing. When I send the system to sleep/hybernate, the system hangs, because the connection to the server is lost (eth0 shuts down), and it cannot write to the server the last changes.
Thanks for the analysis, and sorry for the non-kernel-related bugreport.
(Btw can you direct me, how to solve the centralized user profiles and central auth problem?)

Comment 6 Eric Sandeen 2011-12-15 17:46:17 UTC
I can't help you with your question, that's not my area of expertise either.  :)

I still wonder if the warning you hit is a generic problem, though, to be honest, although I'm happy to let the bug close if we've only ever seen it in your testing setup...

Comment 7 Kieran Clancy 2012-01-03 02:25:00 UTC
I am seeing this bug on my production system. I think any kind of kernel oops is a bug.

In my case, I also see it after disconnecting from my network on which I had an NFS mount.

Reopen?

Comment 8 Gajdos Tamás 2012-01-03 08:34:01 UTC
Reopening the bug, as it has occured in an other setup also.

Comment 9 Josh Boyer 2012-01-04 12:43:46 UTC
*** Bug 759868 has been marked as a duplicate of this bug. ***

Comment 10 Josh Boyer 2012-01-04 12:44:09 UTC
*** Bug 770899 has been marked as a duplicate of this bug. ***

Comment 11 Josh Boyer 2012-01-04 12:44:53 UTC
*** Bug 770838 has been marked as a duplicate of this bug. ***

Comment 12 Josh Boyer 2012-01-04 12:45:08 UTC
*** Bug 771468 has been marked as a duplicate of this bug. ***

Comment 13 Ferry Huberts 2012-01-04 13:09:47 UTC
I reproduced it: https://bugzilla.redhat.com/show_bug.cgi?id=770838#c1

Comment 14 Jeff Layton 2012-01-04 16:49:42 UTC
The suspend problem should be fixed now in current Fedora and the upstream patches should make 3.3.

I'm a little less clear on the d_name thing though. Do we know what filesystem that dentry actually lives in?

Comment 15 Justin M. Forbes 2012-02-29 17:08:58 UTC
*** Bug 798607 has been marked as a duplicate of this bug. ***

Comment 16 Dave Jones 2012-03-07 19:45:16 UTC
*** Bug 799051 has been marked as a duplicate of this bug. ***

Comment 17 Dave Jones 2012-03-07 19:47:51 UTC
There's two different 'flavours' of this bug, with the same end result.
This one via proc_pid_readlink, and bug 787171 which happens via getcwd instead.

I suspect this is the same problem.

Comment 18 Jacek Luczak 2012-03-20 11:58:07 UTC
I've hit same issue on 2.6.39.4 and now I'm working on reproducing it. Will let you know when I will find a clear path towards issue.

Comment 19 Dave Jones 2012-03-20 15:20:31 UTC
the latest kernel update in testing has some extra debug patch to print out the mountpoint where the file lives, which might aid in debugging.

Comment 20 Josh Boyer 2012-03-28 18:03:03 UTC
[Mass hibernate bug update]

Dave Airlied has found an issue causing some corruption in the i915 fbdev after a resume from hibernate.  I have included his patch in this scratch build:

http://koji.fedoraproject.org/koji/taskinfo?taskID=3940545

This will probably not solve all of the issues being tracked at the moment, but it is worth testing when the build completes.  If this seems to clear up the issues you see with hibernate, please report your results in the bug.

Comment 21 Jacek Luczak 2012-04-04 12:53:28 UTC
In my case this is pure NFS driven and there's no hibernate in use. I guess it comes from stale NFS:
------------[ cut here ]------------
WARNING: at fs/dcache.c:2529 prepend_path+0x11a/0x13a()
Hardware name: ProLiant BL460c G7
Root dentry has weird name <>
Modules linked in: sctp ipmi_watchdog ipmi_devintf ipmi_si autofs4 ext4 jbd2 crc16 be2iscsi iscsi_boot_sysfs ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_addr iscsi_tcp bnx2i cnic uio ipv6 cxgb3i libcxgbi iw_cxgb3 ib_core cxgb3 libiscsi_tcp libiscsi scsi_transport_iscsi loop dm_mirror dm_region_hash dm_log dm_multipath video backlight battery acpi_pad acpi_ipmi ipmi_msghandler ac parport usbhid evdev power_meter hwmon psmouse uhci_hcd ehci_hcd
Pid: 20497, comm: ps Tainted: G        W   2.6.39.4 #1
Call Trace:
 [<ffffffff810e2da9>] ? prepend_path+0x11a/0x13a
 [<ffffffff81054400>] ? warn_slowpath_common+0x78/0x8d
 [<ffffffff81054554>] ? warn_slowpath_fmt+0x95/0x9d
 [<ffffffff8109b850>] ? __alloc_pages_nodemask+0x10c/0x6ef
 [<ffffffff810e2da9>] ? prepend_path+0x11a/0x13a
 [<ffffffff810e4911>] ? d_path+0xb0/0xdd
 [<ffffffff81116b3b>] ? proc_pid_readlink+0x65/0xbe
 [<ffffffff810d5e62>] ? sys_readlinkat+0x62/0x7a
 [<ffffffff813a44d2>] ? system_call_fastpath+0x16/0x1b
---[ end trace f2075c15fea69d17 ]---

Comment 22 Dave Jones 2012-04-04 15:33:24 UTC
as mentioned in comment 19, I'd like to see a trace from the current kernel update.

Comment 23 Jacek Luczak 2012-04-05 08:58:59 UTC
Thanks Dave but I can't really boot it to testing kernel as this is production host. I'm also a bit afraid that after reboot I won't be able to reproduce this issue.

I've found the way to trigger this WARN_ON with ps:
ps -ejlfH | less 

and we got at least three WARN_ON messages (NOTE: It must be pipe-ed to sth that will keep ps up for a while). In my case I've found this from WARN_ON frequency - it was cfengine that was doing this a it was executing policy with same frequency. 

I had two borked NFS mounts. One was giving IO error (it was mounted over half of the world) - this was lazy unmouted but did WARN_ON still show up. Now the second one - this one is tricky. Some idiot mounted a NFS share inside automouted home director. Home is not mounted but according to /proc/mounts the first one is still mounted while of course mount  point does not exist.

Comment 24 Jacek Luczak 2012-04-10 12:54:23 UTC
Host was even more borked around NFS. User home directories were mounted 3 times under same target by automouter depending on when user logged in. I guess this was the issue I've been observing in my case. Host has been rebooted and since that I don't get WARN_ONs. 

@Dave can I have a link to a patch or commit so that I could maybe add this on top of my vanilla kernel for future use?

Comment 25 Dave Jones 2012-05-10 15:50:27 UTC
*** Bug 820661 has been marked as a duplicate of this bug. ***

Comment 26 Dave Jones 2012-07-19 20:29:46 UTC
I don't know the exact commit that fixed this. But as we've seen no further reports of this from anyone on 3.4, I'm going to assume this is fixed.

Reopen if it happens again.

Comment 27 BugMasta 2013-01-08 06:23:44 UTC
Unbelievable.

We have some dell precision m6500 laptops doing kernel panic on shutdown/umount of nfs4 filesystems - due to error shrinking the dcache on umount etc - a bug which was supposedly fixed in 2.6.40. 

So we finally get the machines back from the field for long enough to upgrade to 3.0.57-1.el5.elrepo - and now we immediately hit this bug.

Thanks a lot nfs4. Brilliant.

Comment 28 Ric Wheeler 2013-01-08 15:50:29 UTC
BugMasta, you should try a more recent kernel per https://bugzilla.redhat.com/show_bug.cgi?id=766277#c26 - Fedora, RHEL and upstream all have significant NFS updates/changes post the kernel you are having issues with.

Comment 29 BugMasta 2013-01-10 05:38:52 UTC
3.0.57-1.el5.elrepo is the newest kernel available for rhel5. And, another user is still seeing this bug on 3.6.7-4.fc16.x86_64 

I despair. Nfs4 is never going to be free of these bugs. Why does nfs do this, time after time, year after year, kernel after kernel? No other kernel module in existence is as buggy as the nfs4 code. Cifs doesnt do this, so why nfs4? If nfs4 is this buggy, why don't nfs4 developers fix on a certain kernel ABI, and develop all code vs that. So then it would be possible to compile current nfs4 module vs older kernels without any porting or patching effort. If it is necessary to go to the absolute latest nfs4 code, to avoid all these bugs and kernel oopses, I should not have to upgrade to the latest bleeding-edge kernel (and thus risk other performance or stability regressions) in order to do so. I should be able to stay with a good, stable recent kernel, eg rhel6/2.6.32 series, and build latest nfs4 code as a module for my stable kernel. Or distro vendors/3rd party repos could do this. There should be no need for nfs4 to make use of every new feature added to the absolute newest linux kernel. It should be possible to compile current nfs4 code vs older kernels. But, apparently it is not...

I am just completely sick of nfs4 kernel bugs bringing machines to their knees.

See below report from https://bugzilla.redhat.com/show_bug.cgi?id=787171 :

freemarket 2012-12-01 22:34:31 EST
Hi,
Just started getting this on a very recent kernel:

cat /proc/version 
Linux version 3.6.7-4.fc16.x86_64 (mockbuild.fedoraproject.org) (gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC) ) #1 SMP Tue Nov 20 20:33:31 UTC 2012

Dec  1 22:33:30 zurich kernel: [47181.650103] ------------[ cut here ]------------
Dec  1 22:33:30 zurich kernel: [47181.650110] WARNING: at fs/dcache.c:2630 prepend_path+0x1e1/0x1f0()
Dec  1 22:33:30 zurich kernel: [47181.650112] Hardware name: SX58
Dec  1 22:33:30 zurich kernel: [47181.650114] Root dentry has weird name <>  vfsmnt: fs:nfs
Dec  1 22:33:30 zurich kernel: [47181.650115] Modules linked in: tcp_lp ppdev parport_pc lp parport nfsv3 nfs_acl nfsv4 auth_rpcgss nfs fscache dns_resolver lockd tpm_bios fuse nvidia(PO) snd_hda_codec_hdmi snd_hda_codec_realtek i7core_edac edac_core snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc r8169 mii sunrpc iTCO_wdt iTCO_vendor_support lpc_ich coretemp serio_raw i2c_i801 i2c_core mfd_core kvm_intel kvm uinput microcode mxm_wmi crc32c_intel wmi
Dec  1 22:33:30 zurich kernel: [47181.650155] Pid: 27382, comm: gnome-system-mo Tainted: P        W  O 3.6.7-4.fc16.x86_64 #1
Dec  1 22:33:30 zurich kernel: [47181.650157] Call Trace:
Dec  1 22:33:30 zurich kernel: [47181.650163]  [<ffffffff8105c69f>] warn_slowpath_common+0x7f/0xc0
Dec  1 22:33:30 zurich kernel: [47181.650166]  [<ffffffff8105c796>] warn_slowpath_fmt+0x46/0x50
Dec  1 22:33:30 zurich kernel: [47181.650170]  [<ffffffff811a2d91>] prepend_path+0x1e1/0x1f0
Dec  1 22:33:30 zurich kernel: [47181.650175]  [<ffffffff812dfd01>] ? bstr_printf+0x371/0x3a0
Dec  1 22:33:30 zurich kernel: [47181.650178]  [<ffffffff811a2dfc>] path_with_deleted+0x5c/0xa0
Dec  1 22:33:30 zurich kernel: [47181.650182]  [<ffffffff811a35eb>] d_path+0xab/0xe0
Dec  1 22:33:30 zurich kernel: [47181.650186]  [<ffffffff811af4b1>] seq_path+0x51/0xc0
Dec  1 22:33:30 zurich kernel: [47181.650192]  [<ffffffff811ee26b>] show_map_vma+0x15b/0x290
Dec  1 22:33:30 zurich kernel: [47181.650195]  [<ffffffff811ee421>] show_smap+0x81/0x1f0
Dec  1 22:33:30 zurich kernel: [47181.650199]  [<ffffffff811ef620>] ? smaps_pte_entry+0x210/0x210
Dec  1 22:33:30 zurich kernel: [47181.650203]  [<ffffffff811ee5c3>] show_pid_smap+0x13/0x20
Dec  1 22:33:30 zurich kernel: [47181.650206]  [<ffffffff811af1cb>] seq_read+0x16b/0x400
Dec  1 22:33:30 zurich kernel: [47181.650211]  [<ffffffff8118df20>] vfs_read+0xb0/0x180
Dec  1 22:33:30 zurich kernel: [47181.650214]  [<ffffffff8118e03a>] sys_read+0x4a/0x90
Dec  1 22:33:30 zurich kernel: [47181.650219]  [<ffffffff81621ce9>] system_call_fastpath+0x16/0x1b
Dec  1 22:33:30 zurich kernel: [47181.650221] ---[ end trace 7efe48ede83b6720 ]---

Comment 30 Jeff Layton 2013-01-10 11:47:57 UTC
Reopening this bug since Bugmastah is able to reproduce on a more recent kernel. I'll note that this is more of a dcache core vfs looking problem than anything NFS specific. The NFS code may be doing something in particular to trigger it though.

Eric's analysis in comment #2 looks basically correct.

The kernel is trying to print out a pathname for a mnt/dentry that it has. It first checks this:

                if (dentry == vfsmnt->mnt_root || IS_ROOT(dentry)) {
                        /* Global root? */
                        if (!mnt_has_parent(mnt))
                                goto global_root;

...so the dentry in this case is the mnt_root for this vfsmount. That vfsmount also has a parent that points to itself.

It then does this:

global_root:
        /*
         * Filesystems needing to implement special "root names"
         * should do so with ->d_dname()
         */

        if (IS_ROOT(dentry) &&
            (dentry->d_name.len != 1 || dentry->d_name.name[0] != '/')) {
                WARN(1, "Root dentry has weird name <%.*s>\n",
                     (int) dentry->d_name.len, dentry->d_name.name);
        }

...and that causes your warning to pop. Note that this is a WARN message, which shouldn't affect any activity on the box (aside from dumping this message to the ring buffer). If it really bothers you, you can always go back to using NFSv3.

In any case, it looks like the vfsmount is being disconnected from the tree while we're trying to print out the path. There are a couple of possibilities, I guess...

1) the file got closed and the mount was shrunk while we were walking the path

2) someone did a lazy umount of the filesystem while you're holding the file open and mmap'ed

The second case might even be reproducible...

Comment 31 Jeff Layton 2013-01-10 11:55:48 UTC
Yep...I was able to reproduce it by having a process sitting in the root of a NFS mount, doing a lazy umount and then stat'ing /proc/<pid>/cwd for that process.

[34011.669912] ------------[ cut here ]------------
[34011.670473] WARNING: at fs/dcache.c:2630 prepend_path+0x1eb/0x200()
[34011.671198] Hardware name: Bochs
[34011.671564] Root dentry has weird name <>  vfsmnt: fs:nfs4
[34011.672195] Modules linked in: nfsv4 auth_rpcgss nfs lockd sunrpc dns_resolver fscache kvm_amd kvm microcode virtio_net virtio_balloon i2c_piix4 cirrus drm_kms_helper ttm virtio_blk drm i2c_core
[34011.674464] Pid: 7470, comm: ls Tainted: G        W    3.7.0-6.fc19.x86_64 #1
[34011.675417] Call Trace:
[34011.675712]  [<ffffffff8106892f>] warn_slowpath_common+0x7f/0xc0
[34011.676404]  [<ffffffff81068a26>] warn_slowpath_fmt+0x46/0x50
[34011.677058]  [<ffffffff8109eb24>] ? lg_local_lock+0x44/0x80
[34011.677675]  [<ffffffff811e8f18>] ? prepend_path+0x38/0x200
[34011.678315]  [<ffffffff811e90cb>] prepend_path+0x1eb/0x200
[34011.678926]  [<ffffffff811e913c>] path_with_deleted+0x5c/0xa0
[34011.679578]  [<ffffffff811e976f>] d_path+0xbf/0x100
[34011.680139]  [<ffffffff81244bb5>] proc_pid_readlink+0x95/0x100
[34011.680783]  [<ffffffff811d8509>] sys_readlinkat+0xa9/0xc0
[34011.681418]  [<ffffffff81104a5c>] ? __audit_syscall_entry+0xcc/0x300
[34011.682144]  [<ffffffff811d853b>] sys_readlink+0x1b/0x20
[34011.682740]  [<ffffffff816fbd19>] system_call_fastpath+0x16/0x1b
[34011.683425] ---[ end trace 5e8c789abf4f6e53 ]---

I think we may need Al's opinion here, since I'm not sure what the significance of this warning is...

Comment 32 BugMasta 2013-01-11 00:06:32 UTC
thanks Jeff, ok I am less bothered now you've pointed out it's just a warning. Sorry, I should've noticed that myself, but, when the error hits on my machines I don't see the first few lines, they scroll off screen too quickly.

In my case (on 3.0.57-1.el5.elrepo) the warning is being tripped on shutdown by several processes which are running from an nfs mount. The processes sleep for 30secs or so at a time, so on shutdown they don't terminate immediately and they are still sleeping and holding the files open by the time the shutdown attempts to unmount the nfs4 shares.

If I kill the processes manually and give them time to wake and receive the signals, then the unmounts succeed without the ugly warnings.

Since these warnings are still being triggered in 3.6.7-4.fc16.x86_64 it'd be good to avoid them somehow, if they do not indicate any real problem. It is pretty ugly seeing these warnings when shutting down a machine.

Comment 33 Jeff Layton 2013-01-15 00:20:37 UTC
Ok, looks like Neil Brown already fixed this:

commit b911a6bdeef5848c468597d040e3407e0aee04ce
Author: NeilBrown <neilb>
Date:   Thu Nov 8 16:09:37 2012 -0800

    vfs: d_obtain_alias() needs to use "/" as default name.
    
...so 3.8-rc kernels should already be fixed. It was not marked for stable, and probably ought not be since this is just a harmless warning message.

Comment 34 BugMasta 2013-01-15 03:27:11 UTC
Sweet. Ta muchly Jeff and Neil.

Comment 35 Jeff Layton 2013-01-15 20:01:33 UTC
*** Bug 885872 has been marked as a duplicate of this bug. ***

Comment 36 Edgar Hoch 2013-01-18 16:49:27 UTC
We also have a problem with kernel 3.6.11-1.fc16.x86_64 with may be similar to the problem described in this bug:

Jan 18 14:15:26 host1 kernel: [161288.927437] WARNING: at fs/inode.c:280 drop_nlink+0x46/0x50()
Jan 18 14:15:26 host1 kernel: [161288.927439] Hardware name: H8QG6
Jan 18 14:15:26 host1 kernel: [161288.927440] Modules linked in: nfsv4 auth_rpcgss nfs fscache dns_resolver mpt2sas scsi_transport_sas raid_class mptctl mptbase ip6table_filter ip6_tables ebtable_nat
 ebtables ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_CHECKSUM iptable_mangle bridge stp llc lockd be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4
 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi tpm_bios input_polldev sunrpc vboxnetadp(O) vboxnetflt(O) vbox
drv(O) vhost_net macvtap macvlan igb tun amd64_edac_mod dca ptp edac_core pps_core sp5100_tco kvm_amd serio_raw i2c_piix4 edac_mce_amd i2c_core k10temp kvm microcode uinput binfmt_misc megaraid_sas
Jan 18 14:15:26 host1 kernel: [161288.927479] Pid: 10598, comm: java Tainted: G        WC O 3.6.11-1.fc16.x86_64 #1
Jan 18 14:15:26 host1 kernel: [161288.927480] Call Trace:
Jan 18 14:15:26 host1 kernel: [161288.927492]  [<ffffffff8105c69f>] warn_slowpath_common+0x7f/0xc0
Jan 18 14:15:26 host1 kernel: [161288.927497]  [<ffffffff8105c6fa>] warn_slowpath_null+0x1a/0x20
Jan 18 14:15:26 host1 kernel: [161288.927501]  [<ffffffff811a7ba6>] drop_nlink+0x46/0x50
Jan 18 14:15:26 host1 kernel: [161288.927511]  [<ffffffffa03de74b>] nfs_dentry_iput+0x3b/0x70 [nfs]
Jan 18 14:15:26 host1 kernel: [161288.927516]  [<ffffffff811a320c>] dentry_iput+0x8c/0xe0
Jan 18 14:15:26 host1 kernel: [161288.927520]  [<ffffffff811a4c5d>] dput+0x10d/0x1f0
Jan 18 14:15:26 host1 kernel: [161288.927525]  [<ffffffff8118f000>] __fput+0x180/0x240
Jan 18 14:15:26 host1 kernel: [161288.927528]  [<ffffffff8118f0ce>] ____fput+0xe/0x10
Jan 18 14:15:26 host1 kernel: [161288.927534]  [<ffffffff8107cefc>] task_work_run+0x6c/0x90
Jan 18 14:15:26 host1 kernel: [161288.927538]  [<ffffffff81062bfc>] do_exit+0x8bc/0x8d0
Jan 18 14:15:26 host1 kernel: [161288.927542]  [<ffffffff81062f62>] do_group_exit+0x42/0xa0
Jan 18 14:15:26 host1 kernel: [161288.927548]  [<ffffffff81071c33>] get_signal_to_deliver+0x233/0x620
Jan 18 14:15:26 host1 kernel: [161288.927554]  [<ffffffff8101428c>] do_signal+0x3c/0x620
Jan 18 14:15:26 host1 kernel: [161288.927559]  [<ffffffff81014920>] do_notify_resume+0x90/0xd0
Jan 18 14:15:26 host1 kernel: [161288.927565]  [<ffffffff816226a2>] int_signal+0x12/0x17
Jan 18 14:15:26 host1 kernel: [161288.927567] ---[ end trace e76c6b9acb7404b9 ]---

Comment 37 Jeff Layton 2013-01-18 17:05:05 UTC
No, different problem altogether, but should also be fixed in 3.8.