On Fri, May 04, 2012 at 03:36:16PM +0200, David Sterba wrote:
> On Fri, May 04, 2012 at 09:25:36AM -0400, Chris Mason wrote:
> > I'm having a hard time reproducing this here. Do you have lockdep on?
> > It might tell us which lock we're leaving around.
>
> He's using SLUB and it does not like waiting allocations when
> CONFIG_SLUB_DEBUG is on:
>
> 445 #ifdef CONFIG_SLUB_DEBUG
> ...
> 935 /*
> 936 * Hooks for other subsystems that check memory allocations. In a typical
> 937 * production configuration these hooks all should produce no code at all.
> 938 */
> 939 static inline int slab_pre_alloc_hook(struct kmem_cache *s, gfp_t flags)
> 940 {
> 941 flags &= gfp_allowed_mask;
> 942 lockdep_trace_alloc(flags);
> 943 might_sleep_if(flags & __GFP_WAIT);
> 944
> 945 return should_failslab(s->objsize, flags, s->flags);
> 946 }
> ...
> 1223 #else
> ...
> 1259 static inline int slab_pre_alloc_hook(struct kmem_cache *s, gfp_t flags)
> 1260 { return 0; }
>
> where slab_pre_alloc_hook is called down the chain from kmem_cache_alloc.
Right, but this should be after the fact, we're not supposed to be
holding any locks here. Lockdep should tell us which lock is still
held, which will make it much easier.
-chris
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
