[lkml]   [2012]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: WARNING: at lib/debugobjects.c:262 debug_print_object+0x8c/0xb0()
    On 01/25/2012 04:05 PM, Thomas Gleixner wrote:
    > On Tue, 24 Jan 2012, Jeff Layton wrote:
    >>> Still, I wonder if there are other problems like this around. The slab
    >>> allocators seem to call debug_check_no_obj_freed() on kmem_cache_free,
    >>> but parts of the objects themselves (like the timer in the work object
    >>> here) get initialized in other places and aren't necessarily
    >>> reinitialized when they're recycled out of the slab...
    >> On second thought...getting rid of the ctor function here might be
    >> problematic. We have to call inode_init_once, etc...
    >> Almost all of the inode slabs have one, so I've settled for just moving
    >> the INIT_DELAYED_WORK call out of init_once and into rpc_alloc_inode. I
    >> sent a patch to Trond and linux-nfs to do that. That will fix this
    >> case, but I do wonder if there are other places in the kernel that have
    >> similar problems with debugobject initialization.
    > The problem is that debugobject requires that a newly allocated object
    > is reinitialized and made available to the debugobjects code again
    > simply because we remove it from the debugobjects core on
    > kmem_cache_free().
    > The real question is why the heck kmem_cache_alloc() does not call the
    > ctor on each allocation and just expects the previously used and freed
    > object to be in a consistent initialiazed state.

    Perhaps it's some flags that is to do with the RCU delete thing.
    You know for the lockless walks and stuff

    > Thanks,
    > tglx

     \ /
      Last update: 2012-01-25 15:51    [W:0.021 / U:65.812 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site