From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>,
"Alex,Shi" <alex.shi@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
tj@kernel.org
Subject: Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
Date: Mon, 19 Dec 2011 10:19:09 +0100 [thread overview]
Message-ID: <20111219091909.GA1614@x4> (raw)
In-Reply-To: <m1liq9l009.fsf@fess.ebiederm.org>
On 2011.12.18 at 19:21 -0800, Eric W. Biederman wrote:
> Markus Trippelsdorf <markus@trippelsdorf.de> 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 a 16:36 +0100, Markus Trippelsdorf a ecrit :
> >> > > > On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
> >> > > > > Le lundi 21 novembre 2011 a 14:15 +0100, Markus Trippelsdorf a ecrit :
> >> > > > >
> >> > > > > > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
> >> > > > > >
> >> > > > >
> >> > > > > Thanks
> >> > > > >
> >> > > > > Please continue to provide more samples.
> >> > > > >
> >> > > > > There is something wrong somewhere, but where exactly, its hard to say.
> >> > > >
> >> > > > New sample. This one points to lib/idr.c:
> >> > > >
> >> > > > =============================================================================
> >> > > > BUG idr_layer_cache: Poison overwritten
> >> > > > -----------------------------------------------------------------------------
> >> > >
> >> > > Thanks, could you now add "CONFIG_DEBUG_PAGEALLOC=y" in your config as
> >> > > well ?
> >> >
> >> > Sure. This one happend with CONFIG_DEBUG_PAGEALLOC=y:
> >> >
> >> > =============================================================================
> >> > BUG task_struct: Poison overwritten
> >> > -----------------------------------------------------------------------------
> >>
> >> And sometimes this one that I've reported earlier already:
> >>
> >> (see: http://thread.gmane.org/gmane.linux.kernel/1215023 )
> >>
> >> ------------[ 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:
> >> [<ffffffff8106cac5>] warn_slowpath_common+0x75/0xb0
> >> [<ffffffff8106cbc5>] warn_slowpath_null+0x15/0x20
> >> [<ffffffff81163236>] sysfs_get_inode+0x136/0x140
> >> [<ffffffff81164cef>] sysfs_lookup+0x6f/0x110
> >> [<ffffffff811173f9>] d_alloc_and_lookup+0x39/0x80
> >> [<ffffffff81118774>] do_lookup+0x294/0x3a0
> >> [<ffffffff8111798a>] ? inode_permission+0x7a/0xb0
> >> [<ffffffff8111a3f7>] do_last.isra.46+0x137/0x7f0
> >> [<ffffffff8111ab76>] path_openat+0xc6/0x370
> >> [<ffffffff81117606>] ? getname_flags+0x36/0x230
> >> [<ffffffff810ec852>] ? handle_mm_fault+0x192/0x290
> >> [<ffffffff8111ae5c>] do_filp_open+0x3c/0x90
> >> [<ffffffff81127c8c>] ? alloc_fd+0xdc/0x120
> >> [<ffffffff8110ce77>] do_sys_open+0xe7/0x1c0
> >> [<ffffffff8110cf6b>] sys_open+0x1b/0x20
> >> [<ffffffff814ccb7b>] 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?
Yes.
> 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.
Sorry, but your subsystem was just accidentally hit by a bug in the
Radeon driver, that sometimes randomly writes 0 dwords somewhere to
memory after a kexec boot (see the rest of this huge thread).
It's still not fixed in mainline, because Linus refused to take the fix
this late in the series.
--
Markus
--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-12-19 8:19 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-18 7:25 WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413 Markus Trippelsdorf
2011-11-18 7:55 ` Markus Trippelsdorf
2011-11-18 8:43 ` Alex,Shi
2011-11-18 8:54 ` Markus Trippelsdorf
2011-11-18 8:57 ` Markus Trippelsdorf
2011-11-18 12:02 ` Markus Trippelsdorf
2011-11-21 0:44 ` Alex,Shi
2011-11-21 7:29 ` Markus Trippelsdorf
2011-11-21 8:05 ` Markus Trippelsdorf
2011-11-21 8:24 ` Markus Trippelsdorf
2011-11-21 8:56 ` Eric Dumazet
2011-11-21 9:16 ` Eric Dumazet
2011-11-21 13:15 ` Markus Trippelsdorf
2011-11-21 14:16 ` Eric Dumazet
2011-11-21 14:21 ` Markus Trippelsdorf
2011-11-21 15:36 ` Markus Trippelsdorf
2011-11-21 15:48 ` Eric Dumazet
2011-11-21 16:10 ` Markus Trippelsdorf
2011-11-21 16:34 ` Markus Trippelsdorf
2011-11-22 8:36 ` Markus Trippelsdorf
2011-12-19 3:21 ` Eric W. Biederman
2011-12-19 9:19 ` Markus Trippelsdorf [this message]
2011-12-19 9:06 ` Eric W. Biederman
2011-11-21 16:52 ` Eric Dumazet
2011-11-21 17:15 ` Eric Dumazet
2011-11-21 17:35 ` Markus Trippelsdorf
2011-11-21 18:39 ` Eric Dumazet
2011-11-21 18:52 ` Markus Trippelsdorf
2011-11-21 19:51 ` Markus Trippelsdorf
2011-11-21 20:27 ` Benjamin Herrenschmidt
2011-11-21 21:30 ` Pekka Enberg
2011-11-21 21:43 ` Christoph Lameter
2011-11-22 0:21 ` Christian Kujau
2011-11-22 0:42 ` Christian Kujau
2011-11-22 2:17 ` Benjamin Herrenschmidt
2011-11-22 8:37 ` Christian Kujau
2011-11-22 3:18 ` Christoph Lameter
2011-11-22 7:48 ` Eric Dumazet
2011-11-22 7:51 ` Markus Trippelsdorf
2011-11-22 8:27 ` Eric Dumazet
2011-11-23 7:13 ` Markus Trippelsdorf
2011-11-23 7:20 ` Eric Dumazet
2011-11-22 8:39 ` Christian Kujau
2011-11-22 22:16 ` Benjamin Herrenschmidt
2011-11-22 22:31 ` Eric Dumazet
2011-11-22 22:32 ` Christoph Lameter
2011-11-22 21:58 ` Benjamin Herrenschmidt
2011-11-22 23:12 ` Christian Kujau
2011-11-23 0:18 ` Benjamin Herrenschmidt
2011-11-23 1:22 ` Christian Kujau
2011-11-23 1:43 ` Benjamin Herrenschmidt
2011-11-23 5:51 ` Christian Kujau
2011-11-23 6:59 ` Pekka Enberg
2011-11-23 15:14 ` slub: use irqsafe_cpu_cmpxchg for put_cpu_partial Christoph Lameter
2011-11-23 16:04 ` Eric Dumazet
2011-11-23 18:33 ` Christian Kujau
2011-11-24 6:45 ` Pekka Enberg
2011-11-23 23:15 ` David Rientjes
2011-11-22 8:45 ` WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413 Markus Trippelsdorf
2011-11-22 9:25 ` Eric Dumazet
2011-11-22 9:27 ` Eric Dumazet
2011-11-22 9:38 ` Eric Dumazet
2011-11-22 9:46 ` Eric Dumazet
2011-11-22 14:46 ` Christoph Lameter
2011-11-22 14:52 ` Eric Dumazet
2011-11-22 15:02 ` Christoph Lameter
2011-11-22 15:07 ` Christoph Lameter
2011-11-22 16:20 ` Christoph Lameter
2011-11-22 16:32 ` Eric Dumazet
2011-11-22 16:36 ` Christoph Lameter
2011-11-22 16:41 ` Christoph Lameter
2011-11-22 16:53 ` slub: Lockout validation scans during freeing of object Christoph Lameter
2011-11-22 17:21 ` Eric Dumazet
2011-11-22 17:40 ` Christoph Lameter
2011-11-22 18:55 ` Markus Trippelsdorf
2011-11-22 19:20 ` Christoph Lameter
2011-11-22 19:32 ` Markus Trippelsdorf
2011-11-22 19:46 ` Christoph Lameter
2011-11-22 17:59 ` Christoph Lameter
2011-11-22 11:21 ` WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413 Markus Trippelsdorf
2011-11-22 14:50 ` Christoph Lameter
2011-11-22 14:44 ` Christoph Lameter
2011-11-21 15:51 ` Markus Trippelsdorf
2011-11-23 16:03 ` Markus Trippelsdorf
2011-11-23 16:06 ` Christoph Lameter
2011-11-24 8:50 ` Markus Trippelsdorf
2011-12-01 8:44 ` Markus Trippelsdorf
2011-12-01 8:53 ` Pekka Enberg
2011-12-02 19:43 ` Jerome Glisse
2011-12-02 20:06 ` Markus Trippelsdorf
2011-12-02 20:48 ` Markus Trippelsdorf
2011-12-07 14:32 ` Robert Richter
2011-12-07 14:39 ` Markus Trippelsdorf
2011-12-02 23:04 ` Jerome Glisse
2011-12-03 9:28 ` Markus Trippelsdorf
2011-12-03 12:20 ` Dave Airlie
2011-12-03 12:29 ` Markus Trippelsdorf
2011-12-03 19:31 ` Jerome Glisse
2011-12-03 19:32 ` Jerome Glisse
2011-12-04 1:02 ` Markus Trippelsdorf
2011-12-04 17:32 ` Jerome Glisse
2011-12-05 17:10 ` Jerome Glisse
2011-12-05 18:15 ` Markus Trippelsdorf
2011-12-05 18:43 ` Jerome Glisse
2011-12-05 19:11 ` Jerome Glisse
2011-12-05 19:27 ` Markus Trippelsdorf
2011-12-05 20:10 ` Pekka Enberg
2011-12-05 20:20 ` Jerome Glisse
2011-12-05 10:44 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111219091909.GA1614@x4 \
--to=markus@trippelsdorf.de \
--cc=alex.shi@intel.com \
--cc=cl@linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=netdev@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).