lkml.org 
[lkml]   [2013]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [linux-next-20130422] Bug in SLAB?

    On Wed, 1 May 2013, Tetsuo Handa wrote:

    > 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.

    It did for SLUB. SLAB returned NULL for some cases.

    > "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?

    > 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?




    \
     
     \ /
      Last update: 2013-04-30 20:01    [W:3.621 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site