Re: [linux-next-20130422] Bug in SLAB?

From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: cl@linux.com
Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [linux-next-20130422] Bug in SLAB?
Date: Wed, 1 May 2013 01:01:58 +0900	[thread overview]
Message-ID: <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com>

Christoph Lameter wrote:
> On Tue, 30 Apr 2013, Tetsuo Handa wrote:
> 
> > The testcases still trigger BUG() at 32M:
> 
> I thought we established that MAX_ORDER only allows a maximum of 8M sized
> allocations? Why are you trying 32M?

Only for regression testing. At least until Linux 3.9, requesting too large
size didn't trigger oops, did it? I'm not expecting kmalloc() to trigger oops
for Linux 3.10 and future kernels.

> 
> The BUG() should trigger for these allocations.
> 

"kmalloc() returning NULL for these allocations" is needed by "try kmalloc()
first, fallback to vmalloc()" allocation. There are kernel modules which expect
kmalloc() to return NULL rather than oops when the requested size is larger
than KMALLOC_MAX_SIZE bytes. If kmalloc() suddenly starts triggering oops, such
modules will break.

Anyway, there is a regression we want to fix : we won't be able to boot
Linux 3.10-rc1 for x86_32 built with CONFIG_DEBUG_SLAB=y &&
CONFIG_DEBUG_SPINLOCK=y && CONFIG_DEBUG_PAGEALLOC=y .
("Fix off by one error in slab.h" did not fix the regression.)

Regards.