Re: [PATCH 4/10] cpu: deliver CPU_UP_CANCELED only to NOTIFY_OKed callbacks with CPU_UP_PREPARE

["Akinobu Mita" <akinobu.mita@gmail.com>]

> > So it is natural to deliver CPU_UP_CANCELED event only to the functions
> > that have returned NOTIFY_OK with CPU_UP_PREPARE event and not to call
> > the function that have returned NOTIFY_BAD. This is what this patch is doing.
>
> Yes, this makes sense.

Thank you for making sure of it.

> [...] However, it might break slab.
> If I am not mistaken, slab code initializes multiple objects in
> CPU_UP_PREPARE and relies on the CPU_UP_CANCELLED to destroy the
> objects which successfully got initialized before the some object's
> initialization went bad.

My testing machine is ordinary dual core non numa box. So it might not
trigger the problem that you are warried about under heavy slab alloc
failure injection.

At first glance I couln't find the problem in cpu hottplug code in slab.c yet,
but found some memory leak path. (it doesn't break slab though)

Index: 2.6-git/mm/slab.c
===================================================================
--- 2.6-git.orig/mm/slab.c
+++ 2.6-git/mm/slab.c
@@ -1221,13 +1221,18 @@ static int __cpuinit cpuup_callback(stru
				shared = alloc_arraycache(node,
					cachep->shared * cachep->batchcount,
					0xbaadf00d);
-				if (!shared)
+				if (!shared) {
+					kfree(nc);
					goto bad;
+				}
			}
			if (use_alien_caches) {
                                alien = alloc_alien_cache(node, cachep->limit);
-                                if (!alien)
-                                        goto bad;
+                                if (!alien) {
+					kfree(shared);
+					kfree(nc);
+					goto bad;
+				}
                        }
			cachep->array[cpu] = nc;
			l3 = cachep->nodelists[node];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/