lkml.org 
[lkml]   [2011]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: WARNING: at fs/sysfs/sysfs.h:195 (during boot)
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.

Eric


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