[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0802271412420.13186@schroedinger.engr.sgi.com>
Date: Wed, 27 Feb 2008 14:15:45 -0800 (PST)
From: Christoph Lameter <clameter@....com>
To: Pekka Enberg <penberg@...helsinki.fi>
cc: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Torsten Kaiser <just.for.lkml@...glemail.com>
Subject: Re: NULL pointer in kmem_cache_alloc with 2.6.25-rc1
On Tue, 19 Feb 2008, Pekka Enberg wrote:
> > I will do more testing and investigation, as the bug also exists in 2.6.25-rc2.
>
> Could you please try Ingo's patch: http://lkml.org/lkml/2008/2/19/13
>
> Looks like there are some problems with SLUB_FASTPATH.
Yeah that would determine if its the fastpath code. Note that the new
fastpath code may expose bugs that so far have been tolerated by the slab
allocators. If a store of a NULL to the first word of an object occurs
then this will be tolerated in 2.6.24 because slub will take it as the end
of the object list and just forget about the remaining objects. The
fastpath code will terminate with a NULL pointer deref.
Enabling full debugging may get rid of the race due to the slowdown. It
could help to just enable minimal debugging for the slab cache in which we
see the issue.
So do
slub_debug=F,<affected cache>
--
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