Messages in this thread | | | Subject | Re: [linux-next-20130422] Bug in SLAB? | From | Tetsuo Handa <> | Date | Wed, 1 May 2013 21:14:23 +0900 |
| |
Christoph Lameter wrote: > > "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. > > This behavior has been in there for years. Why try a kmalloc that > always fails since the size is too big? >
This is nothing but a testcase. Size argument is sometimes unknown and/or user-controlled. We expect that not only kmalloc() etc. but also kstrdup(), kmemdup(), krealloc() etc. do not trigger oops. I think that checking the size in SLAB/SLUB is the only safe way.
> > 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.) > > Hmm... Where does this fail? In slab? > It hangs (with CPU#0 spinning) immediately after printing
Decompressing Linux... Parsing ELF... done. Booting the kernel.
lines. Today I heard that gdb can be used if I use qemu, but I doubt that I can manage time to understand and find the exact location within a few days.
The culprit location is possibly in SLAB because the kernel boots if built with CONFIG_DEBUG_SLAB=n || CONFIG_DEBUG_SPINLOCK=n || CONFIG_DEBUG_PAGEALLOC=n.
| |