Re: [linux-next][PATCH] mm: slub: work around unneeded lockdep warning
On Fri, 24 Jan 2014, Dave Hansen wrote: > From: Dave Hansen > > The slub code does some setup during early boot in > early_kmem_cache_node_alloc() with some local data. There is no > possible way that another CPU can see this data, so the slub code > doesn't unnecessarily lock it. However, some new lockdep asserts > check to make sure that add_partial() _always_ has the list_lock > held. > > Just add the locking, even though it is technically unnecessary. > > Signed-off-by: Dave Hansen > Cc: Peter Zijlstra > Cc: Pekka Enberg > Cc: Russell King Acked-by: David Rientjes -- 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/
Re: [linux-next][PATCH] mm: slub: work around unneeded lockdep warning
On Fri, 24 Jan 2014, Dave Hansen wrote: From: Dave Hansen dave.han...@linux.intel.com The slub code does some setup during early boot in early_kmem_cache_node_alloc() with some local data. There is no possible way that another CPU can see this data, so the slub code doesn't unnecessarily lock it. However, some new lockdep asserts check to make sure that add_partial() _always_ has the list_lock held. Just add the locking, even though it is technically unnecessary. Signed-off-by: Dave Hansen dave.han...@linux.intel.com Cc: Peter Zijlstra pet...@infradead.org Cc: Pekka Enberg penb...@kernel.org Cc: Russell King li...@arm.linux.org.uk Acked-by: David Rientjes rient...@google.com -- 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/
[linux-next][PATCH] mm: slub: work around unneeded lockdep warning
I think this is a next-only thing. Pekka, can you pick this up, please? -- From: Dave Hansen The slub code does some setup during early boot in early_kmem_cache_node_alloc() with some local data. There is no possible way that another CPU can see this data, so the slub code doesn't unnecessarily lock it. However, some new lockdep asserts check to make sure that add_partial() _always_ has the list_lock held. Just add the locking, even though it is technically unnecessary. Signed-off-by: Dave Hansen Cc: Peter Zijlstra Cc: Pekka Enberg Cc: Russell King --- b/mm/slub.c |6 ++ 1 file changed, 6 insertions(+) diff -puN mm/slub.c~slub-lockdep-workaround mm/slub.c --- a/mm/slub.c~slub-lockdep-workaround 2014-01-24 07:19:23.794069012 -0800 +++ b/mm/slub.c 2014-01-24 07:19:23.799069236 -0800 @@ -2890,7 +2890,13 @@ static void early_kmem_cache_node_alloc( init_kmem_cache_node(n); inc_slabs_node(kmem_cache_node, node, page->objects); + /* +* the lock is for lockdep's sake, not for any actual +* race protection +*/ + spin_lock(>list_lock); add_partial(n, page, DEACTIVATE_TO_HEAD); + spin_unlock(>list_lock); } static void free_kmem_cache_nodes(struct kmem_cache *s) _ -- 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/
[linux-next][PATCH] mm: slub: work around unneeded lockdep warning
I think this is a next-only thing. Pekka, can you pick this up, please? -- From: Dave Hansen dave.han...@linux.intel.com The slub code does some setup during early boot in early_kmem_cache_node_alloc() with some local data. There is no possible way that another CPU can see this data, so the slub code doesn't unnecessarily lock it. However, some new lockdep asserts check to make sure that add_partial() _always_ has the list_lock held. Just add the locking, even though it is technically unnecessary. Signed-off-by: Dave Hansen dave.han...@linux.intel.com Cc: Peter Zijlstra pet...@infradead.org Cc: Pekka Enberg penb...@kernel.org Cc: Russell King li...@arm.linux.org.uk --- b/mm/slub.c |6 ++ 1 file changed, 6 insertions(+) diff -puN mm/slub.c~slub-lockdep-workaround mm/slub.c --- a/mm/slub.c~slub-lockdep-workaround 2014-01-24 07:19:23.794069012 -0800 +++ b/mm/slub.c 2014-01-24 07:19:23.799069236 -0800 @@ -2890,7 +2890,13 @@ static void early_kmem_cache_node_alloc( init_kmem_cache_node(n); inc_slabs_node(kmem_cache_node, node, page-objects); + /* +* the lock is for lockdep's sake, not for any actual +* race protection +*/ + spin_lock(n-list_lock); add_partial(n, page, DEACTIVATE_TO_HEAD); + spin_unlock(n-list_lock); } static void free_kmem_cache_nodes(struct kmem_cache *s) _ -- 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/
