Patch "slub/memcg: cure the brainless abuse of sysfs attributes" has been added to the 4.11-stable tree

This is a note to let you know that I've just added the patch titled

slub/memcg: cure the brainless abuse of sysfs attributes

to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
slub-memcg-cure-the-brainless-abuse-of-sysfs-attributes.patch
and it can be found in the queue-4.11 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Thomas Gleixner <[email protected]>
Date: Fri, 2 Jun 2017 14:46:25 -0700
Subject: slub/memcg: cure the brainless abuse of sysfs attributes

From: Thomas Gleixner <[email protected]>

commit 478fe3037b2278d276d4cd9cd0ab06c4cb2e9b32 upstream.

memcg_propagate_slab_attrs() abuses the sysfs attribute file functions to propagate settings from the root kmem_cache to a newly created kmem_cache. It does that with:

     attr->show(root, buf);
     attr->store(new, buf, strlen(bug);

Aside of being a lazy and absurd hackery this is broken because it does not check the return value of the show() function.

Some of the show() functions return 0 w/o touching the buffer. That means in such a case the store function is called with the stale content of the previous show(). That causes nonsense like invoking kmem_cache_shrink() on a newly created kmem_cache. In the worst case it would cause handing in an uninitialized buffer.

This should be rewritten proper by adding a propagate() callback to those slub_attributes which must be propagated and avoid that insane conversion to and from ASCII, but that's too large for a hot fix.

Check at least the return value of the show() function, so calling store() with stale content is prevented.

Steven said:
"It can cause a deadlock with get_online_cpus() that has been uncovered
by recent cpu hotplug and lockdep changes that Thomas and Peter have been doing.

     Possible unsafe locking scenario:

           CPU0                    CPU1
           ----                    ----
      lock(cpu_hotplug.lock);
                                   lock(slab_mutex);
                                   lock(cpu_hotplug.lock);
      lock(slab_mutex);

     *** DEADLOCK ***"

---
 mm/slub.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

@@ -5512,6 +5512,7 @@ static void memcg_propagate_slab_attrs(s
 		char mbuf[64];
 		char *buf;
 		struct slab_attribute *attr = to_slab_attr(slab_attrs[i]);
+		ssize_t len;
 
 		if (!attr || !attr->store || !attr->show)
 			continue;

@@ -5536,8 +5537,9 @@ static void memcg_propagate_slab_attrs(s
 			buf = buffer;
 		}
 
-		attr->show(root_cache, buf);
-		attr->store(s, buf, strlen(buf));
+		len = attr->show(root_cache, buf);
+		if (len > 0)
+			attr->store(s, buf, len);
 	}
 
 	if (buffer)

Patches currently in stable-queue which might be from [email protected] are

queue-4.11/x86-pat-fix-xorg-regression-on-cpus-that-don-t-support-pat.patch queue-4.11/x86-mce-export-memory_error.patch queue-4.11/x86-boot-use-cross_compile-prefix-for-readelf.patch queue-4.11/slub-memcg-cure-the-brainless-abuse-of-sysfs-attributes.patch queue-4.11/acpi-nfit-fix-the-memory-error-check-in-nfit_handle_mce.patch