[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKb7Uvgxm7ouX0AvPo=eLGn_ruJK7FMCaEMVyK8HxhQ3Ekk0sQ@mail.gmail.com>
Date: Sat, 6 Apr 2013 05:01:32 -0400
From: Ilia Mirkin <imirkin@...m.mit.edu>
To: Christoph Lameter <cl@...ux.com>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
nouveau@...ts.freedesktop.org, linux-mm@...ck.org,
dri-devel@...ts.freedesktop.org
Subject: Re: system death under oom - 3.7.9
On Mon, Apr 1, 2013 at 4:14 PM, Christoph Lameter <cl@...ux.com> wrote:
> On Wed, 27 Mar 2013, Ilia Mirkin wrote:
>
>> The GPF happens at +160, which is in the argument setup for the
>> cmpxchg in slab_alloc_node. I think it's the call to
>> get_freepointer(). There was a similar bug report a while back,
>> https://lkml.org/lkml/2011/5/23/199, and the recommendation was to run
>> with slub debugging. Is that still the case, or is there a simpler
>> explanation? I can't reproduce this at will, not sure how many times
>> this has happened but definitely not many.
>
> slub debugging will help to track down the cause of the memory corruption.
OK, with slub_debug=FZP, I get (after a while):
http://pastebin.com/cbHiKhdq
Which definitely makes it look like something in the nouveau
context/whatever alloc failure path causes some stomping to happen. (I
don't suppose it's reasonable to warn when the stomping happens
through some sort of page protection... would explode the size since
each n-byte object would be at least 4K, but might be worth it for
debugging...)
--
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/
Powered by blists - more mailing lists