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] [day] [month] [year] [list]

Message-ID: <20111116063805.GA1638@x4.trippels.de>
Date:	Wed, 16 Nov 2011 07:38:05 +0100
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Greg KH <gregkh@...e.de>, linux-kernel@...r.kernel.org
Subject: Re: WARNING: at fs/sysfs/sysfs.h:195 (during boot)

On 2011.11.15 at 18:14 -0800, Eric W. Biederman wrote:
> 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.

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
--
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/