From: Greg KH <[email protected]>

3.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Pravin B Shelar <[email protected]>

commit abca7c4965845924f65d40e0aa1092bdd895e314 upstream.

On arches that do not support this_cpu_cmpxchg_double() slab_lock is used
to do atomic cmpxchg() on double word which contains page->_count.  The
page count can be changed from get_page() or put_page() without taking
slab_lock.  That corrupts page counter.

Fix it by moving page->_count out of cmpxchg_double data.  So that slub
does no change it while updating slub meta-data in struct page.

[[email protected]: use standard comment layout, tweak comment text]
Reported-by: Amey Bhide <[email protected]>
Signed-off-by: Pravin B Shelar <[email protected]>
Acked-by: Christoph Lameter <[email protected]>
Cc: Pekka Enberg <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
 include/linux/mm_types.h |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -56,8 +56,18 @@ struct page {
                };
 
                union {
+#if defined(CONFIG_HAVE_CMPXCHG_DOUBLE) && \
+       defined(CONFIG_HAVE_ALIGNED_STRUCT_PAGE)
                        /* Used for cmpxchg_double in slub */
                        unsigned long counters;
+#else
+                       /*
+                        * Keep _count separate from slub cmpxchg_double data.
+                        * As the rest of the double word is protected by
+                        * slab_lock but _count is not.
+                        */
+                       unsigned counters;
+#endif
 
                        struct {
 


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

Reply via email to