On Wed, Feb 05, 2014 at 02:58:37PM -0500, Steven Rostedt wrote:
> On Wed, Feb 05, 2014 at 12:15:33PM +0400, Vladimir Davydov wrote:
> > Commit c65c1877bd68 ("slub: use lockdep_assert_held") requires
> > remove_partial() to be called with n->list_lock held, but free_partial()
> > called from kmem_ca
On Wed, 5 Feb 2014, Steven Rostedt wrote:
> > Looks like you've got something prepared already! Mind sending it to
> > Pekka as a patch based on linux-next?
>
> Sure, and there's another lockdep splat that I'm working on too.
>
If it's coming from slub, make sure you've applied
http://marc.i
On Wed, 5 Feb 2014 13:25:28 -0800 (PST)
David Rientjes wrote:
> Looks like you've got something prepared already! Mind sending it to
> Pekka as a patch based on linux-next?
Sure, and there's another lockdep splat that I'm working on too.
But first, I need to shovel my driveway yet again (We
On Wed, 5 Feb 2014, Steven Rostedt wrote:
> Then add the comment that clears this up. But lets not add spinlocks
> just to quiet something if they truly are not needed.
>
> We use "__" variants all the time. That's really not extra code.
>
> Heck, if you want, call it remove_freed_partial() that
On Wed, 5 Feb 2014 13:07:05 -0800 (PST)
David Rientjes wrote:
> The functions that manipulate the partial lists was modified by
> c65c1877bd68 ("slub: use lockdep_assert_held") which replaced commentary
> with runtime checking on debug kernels with lockdep enabled. I'm not sure
> adding more
On Wed, 5 Feb 2014, Steven Rostedt wrote:
> > There's an extremely small overhead of taking this lock, the cache has
> > been destroyed and is the process of being torn down, there will be
> > absolutely no contention on n->list_lock.
>
> But why add it if it isn't necessary? You're even disabl
On Wed, 5 Feb 2014 12:32:43 -0800 (PST)
David Rientjes wrote:
> On Wed, 5 Feb 2014, Steven Rostedt wrote:
> There's an extremely small overhead of taking this lock, the cache has
> been destroyed and is the process of being torn down, there will be
> absolutely no contention on n->list_lock.
On Wed, 5 Feb 2014 14:42:26 -0600 (CST)
Christoph Lameter wrote:
> > That, IMNSHO, is a much better solution
>
> Ok with me. It just adds another variant of remove_partial.
That's a common practice in the kernel though.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe lin
On Wed, 5 Feb 2014, Steven Rostedt wrote:
> Really? We are adding a spin lock for a case where it is not needed just to
> quiet lockdep?
Well its a very rarely used code path. Doesnt matter performance wise
since a slab cache should have no objects when its going to be removed.
> Now if it reall
On Wed, 5 Feb 2014, Steven Rostedt wrote:
> > Commit c65c1877bd68 ("slub: use lockdep_assert_held") requires
> > remove_partial() to be called with n->list_lock held, but free_partial()
> > called from kmem_cache_close() on cache destruction does not follow this
> > rule, leading to a warning:
> >
On Wed, Feb 05, 2014 at 12:15:33PM +0400, Vladimir Davydov wrote:
> Commit c65c1877bd68 ("slub: use lockdep_assert_held") requires
> remove_partial() to be called with n->list_lock held, but free_partial()
> called from kmem_cache_close() on cache destruction does not follow this
> rule, leading to
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 5 Feb 2014, Vladimir Davydov wrote:
> Commit c65c1877bd68 ("slub: use lockdep_assert_held") requires
> remove_partial() to be called with n->list_lock held, but free_partial()
> called from kmem_cache_close() on cache destruction does not follow this
> rule, leading to a warning:
>
> WA
Commit c65c1877bd68 ("slub: use lockdep_assert_held") requires
remove_partial() to be called with n->list_lock held, but free_partial()
called from kmem_cache_close() on cache destruction does not follow this
rule, leading to a warning:
WARNING: CPU: 0 PID: 2787 at mm/slub.c:1536
__kmem_cache_s
14 matches
Mail list logo
