From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx104.postini.com [74.125.245.104]) by kanga.kvack.org (Postfix) with SMTP id 12BC06B004D for ; Sun, 18 Dec 2011 22:19:51 -0500 (EST) From: ebiederm@xmission.com (Eric W. Biederman) References: <1321836285.30341.554.camel@debian> <20111121080554.GB1625@x4.trippels.de> <20111121082445.GD1625@x4.trippels.de> <1321866988.2552.10.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <20111121131531.GA1679@x4.trippels.de> <1321884966.10470.2.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <20111121153621.GA1678@x4.trippels.de> <1321890510.10470.11.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> <20111121161036.GA1679@x4.trippels.de> <20111121163459.GA1679@x4.trippels.de> <20111122083630.GA1672@x4.trippels.de> Date: Sun, 18 Dec 2011 19:21:26 -0800 In-Reply-To: <20111122083630.GA1672@x4.trippels.de> (Markus Trippelsdorf's message of "Tue, 22 Nov 2011 09:36:30 +0100") Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413 Sender: owner-linux-mm@kvack.org List-ID: To: Markus Trippelsdorf Cc: Eric Dumazet , "Alex,Shi" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Christoph Lameter , Pekka Enberg , Matt Mackall , "netdev@vger.kernel.org" , tj@kernel.org Markus Trippelsdorf writes: > On 2011.11.21 at 17:34 +0100, Markus Trippelsdorf wrote: >> On 2011.11.21 at 17:10 +0100, Markus Trippelsdorf wrote: >> > On 2011.11.21 at 16:48 +0100, Eric Dumazet wrote: >> > > Le lundi 21 novembre 2011 =C3=A0 16:36 +0100, Markus Trippelsdorf a = =C3=A9crit : >> > > > On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote: >> > > > > Le lundi 21 novembre 2011 =C3=A0 14:15 +0100, Markus Trippelsdor= f a =C3=A9crit : >> > > > >=20 >> > > > > > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend: >> > > > > >=20 >> > > > >=20 >> > > > > Thanks >> > > > >=20 >> > > > > Please continue to provide more samples. >> > > > >=20 >> > > > > There is something wrong somewhere, but where exactly, its hard = to say. >> > > >=20 >> > > > New sample. This one points to lib/idr.c: >> > > >=20 >> > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> > > > BUG idr_layer_cache: Poison overwritten >> > > > ------------------------------------------------------------------= ----------- >> > >=20 >> > > Thanks, could you now add "CONFIG_DEBUG_PAGEALLOC=3Dy" in your confi= g as >> > > well ? >> >=20 >> > Sure. This one happend with CONFIG_DEBUG_PAGEALLOC=3Dy: >> >=20 >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > BUG task_struct: Poison overwritten >> > ----------------------------------------------------------------------= ------- >>=20 >> And sometimes this one that I've reported earlier already: >>=20 >> (see: http://thread.gmane.org/gmane.linux.kernel/1215023 ) >>=20 >> ------------[ cut here ]------------ >> WARNING: at fs/sysfs/sysfs.h:195 sysfs_get_inode+0x136/0x140() >> Hardware name: System Product Name >> Pid: 1876, comm: slabinfo Not tainted 3.2.0-rc2-00274-g6fe4c6d #72 >> Call Trace: >> [] warn_slowpath_common+0x75/0xb0 >> [] warn_slowpath_null+0x15/0x20 >> [] sysfs_get_inode+0x136/0x140 >> [] sysfs_lookup+0x6f/0x110 >> [] d_alloc_and_lookup+0x39/0x80 >> [] do_lookup+0x294/0x3a0 >> [] ? inode_permission+0x7a/0xb0 >> [] do_last.isra.46+0x137/0x7f0 >> [] path_openat+0xc6/0x370 >> [] ? getname_flags+0x36/0x230 >> [] ? handle_mm_fault+0x192/0x290 >> [] do_filp_open+0x3c/0x90 >> [] ? alloc_fd+0xdc/0x120 >> [] do_sys_open+0xe7/0x1c0 >> [] sys_open+0x1b/0x20 >> [] system_call_fastpath+0x16/0x1b >> ---[ end trace b1377eb8b131d37d ]--- > > Hm, the "sysfs: use rb-tree" thing hit again during boot. Could this be > the root cause of this all? > > I wrote down the following: > > RIP : rb_next > > Trace: > sysfs_dir_pos > sysfs_readdir > ? sys_ioctl > vfs_readdir > sys_getdents Thanks for reporting this. Has this by any chance been resolved or stopped happening? This looks for all of the world like something is stomping your sysfs dirents. I haven't seen anyone else complaining so this seems like the problem is unique to your configuration. Which suggests that it is not sysfs itself that is wrong. I have been through the code a time or two and I haven't seen anything obviously wrong. Everything that sysfs does is protected by the sysfs_mutex so the locking is very very simple. My best guess of why now is that the rbtree code make a sysfs dirent 48 bytes larger. And so it is much more exposed to these kinds of problems. Eric -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org