Re: lockdep complaints in slab allocator

[Pekka Enberg]

On Fri, Nov 20, 2009 at 11:25 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> Did anything change recently? git-log mm/slab.c doesn't show anything
> obvious, although ec5a36f94e7ca4b1f28ae4dd135cd415a704e772 has the exact
> same lock recursion msg ;-)

No, SLAB hasn't changed for a while.

On Fri, Nov 20, 2009 at 11:25 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> So basically its this stupid recursion issue where you allocate the slab
> meta structure using the slab allocator, and now have to free while
> freeing, right?

Yes.

On Fri, Nov 20, 2009 at 11:25 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> The code in kmem_cache_create() suggests its not even fixed size, so
> there is no single cache backing all this OFF_SLAB muck :-(

Oh, crap, I missed that. It's variable-length because we allocate the
freelists (bufctls in slab-speak) in the slab managment structure. So
this is a genuine bug.

On Fri, Nov 20, 2009 at 11:25 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> It does appear to be limited to the kmalloc slabs..
>
> There's a few possible solutions -- in order of preference:
>
>  1) do the great slab cleanup now and remove slab.c, this will avoid any
> further waste of manhours and braincells trying to make slab limp along.

:-) I don't think that's an option for 2.6.33.

On Fri, Nov 20, 2009 at 11:25 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
>  2) propagate the nesting information and user spin_lock_nested(), given
> that slab is already a rat's nest, this won't make it any less obvious.

spin_lock_nested() doesn't really help us here because there's a
_real_ possibility of a recursive spin lock here, right?

                        Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/