lkml.org 
[lkml]   [2011]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: WARNING: at fs/sysfs/sysfs.h:195 (during boot)
On 2011.11.15 at 18:14 -0800, Eric W. Biederman wrote:
> Greg KH <gregkh@suse.de> writes:
>
> > On Sun, Nov 13, 2011 at 08:24:17PM +0100, Markus Trippelsdorf wrote:
> >> I'm seeing this for the fist time:
> >>
> >> ...
> >> XFS (sda): Mounting Filesystem
> >> XFS (sda): Ending clean mount
> >> ATL1E 0000:02:00.0: irq 40 for MSI/MSI-X
> >> ATL1E 0000:02:00.0: eth0: NIC Link is Up <100 Mbps Full Duplex>
> >> ATL1E 0000:02:00.0: eth0: NIC Link is Up <100 Mbps Full Duplex>
> >> udevd[888]: starting version 171
> >> ------------[ cut here ]------------
> >> WARNING: at fs/sysfs/sysfs.h:195 sysfs_get_inode+0x136/0x140()
> >> Hardware name: System Product Name
> >> Pid: 945, comm: udevadm Not tainted 3.2.0-rc1-00252-g8f042aa #49
> >> Call Trace:
> >> [<ffffffff81072795>] warn_slowpath_common+0x75/0xb0
> >> [<ffffffff81072895>] warn_slowpath_null+0x15/0x20
> >> [<ffffffff81167b26>] sysfs_get_inode+0x136/0x140
> >> [<ffffffff811695df>] sysfs_lookup+0x6f/0x110
> >> [<ffffffff8111b739>] d_alloc_and_lookup+0x39/0x80
> >> [<ffffffff8111ca93>] do_lookup+0x283/0x390
> >> [<ffffffff8111d954>] path_lookupat+0x114/0x6d0
> >> [<ffffffff8111b946>] ? getname_flags+0x36/0x230
> >> [<ffffffff8111df3b>] do_path_lookup+0x2b/0x70
> >> [<ffffffff8111e3a8>] user_path_at_empty+0x58/0xb0
> >> [<ffffffff81169d4c>] ? sysfs_put_link+0x1c/0x20
> >> [<ffffffff81120ac4>] ? generic_readlink+0x84/0xa0
> >> [<ffffffff8111e40c>] user_path_at+0xc/0x10
> >> [<ffffffff811161e0>] vfs_fstatat+0x30/0x70
> >> [<ffffffff8112d94b>] ? mntput_no_expire+0x2b/0xe0
> >> [<ffffffff81116236>] vfs_stat+0x16/0x20
> >> [<ffffffff81116305>] sys_newstat+0x15/0x30
> >> [<ffffffff8111642e>] ? sys_readlinkat+0x7e/0xb0
> >> [<ffffffff814d2c7b>] system_call_fastpath+0x16/0x1b
> >> ---[ end trace 2226f614d7765573 ]---
> >> Adding 2097148k swap on /var/tmp/swap/swapfile. Priority:-1 extents:2 across:2634672k
> >>
> >> fs/sysfs/sysfs.h:195:
> >> WARN_ON(!atomic_read(&sd->s_count));
> >
> > Odd, is it reproducable?
> >
> > Eric, any ideas?
>
> So this indicates we found a sysfs_dirent in a directory with a
> reference count of 0.
>
> If this isn't caused by a bitflip. My guess would be something off in
> the new sysfs directory handling.
>
> Off the top of my head I don't know how the new sysfs directory
> handling could have caused this. But I expect it would take
> a fair amount of directory modification to cause this. Everything
> is serialized under the sysfs_mutex so it should be really hard
> to trigger race conditions. I am scratching my head.

Please note that the WARNING above appears to be the benign
manifestation of the underlying bug. There is also a more malignant
form that manifests itself in a kernel OOPS during startup. This
happened two times thus far on my machine. The oops had sysfs entries
all over the call-traces. Unfortunately I didn't take a photo.
Neither the WARNING nor the OOPS are easily reproducible.

A bit-flip is very unlikely because this machine uses ECC memory and
there is nothing in the logs.

--
Markus


\
 
 \ /
  Last update: 2011-11-16 07:41    [W:1.861 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site