linux-kernel - Re: WARNING: at fs/sysfs/sysfs.h:195 (during boot)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1fwhoolth.fsf@fess.ebiederm.org>
Date:	Tue, 15 Nov 2011 18:14:34 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Greg KH <gregkh@...e.de>
Cc:	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	linux-kernel@...r.kernel.org
Subject: Re: WARNING: at fs/sysfs/sysfs.h:195 (during boot)

Greg KH <gregkh@...e.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/