There is no point in flooding logs with warnings or especially crashing
the system if we fail to create a cache for a memcg. In this case we
will be accounting the memcg allocation to the root cgroup until we
succeed to create its own cache, but it isn't that critical.
Signed-off-by: Vladimir Davydov <vdavy...@parallels.com>
Cc: Michal Hocko <mho...@suse.cz>
Cc: Glauber Costa <glom...@gmail.com>
Cc: Johannes Weiner <han...@cmpxchg.org>
Cc: Pekka Enberg <penb...@kernel.org>
Cc: Christoph Lameter <c...@linux.com>
Cc: Andrew Morton <a...@linux-foundation.org>
---
mm/slab_common.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index f34707e..8e40321 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -233,7 +233,14 @@ out_unlock:
mutex_unlock(&slab_mutex);
put_online_cpus();
- if (err) {
+ /*
+ * There is no point in flooding logs with warnings or especially
+ * crashing the system if we fail to create a cache for a memcg. In
+ * this case we will be accounting the memcg allocation to the root
+ * cgroup until we succeed to create its own cache, but it isn't that
+ * critical.
+ */
+ if (err && !memcg) {
if (flags & SLAB_PANIC)
panic("kmem_cache_create: Failed to create slab '%s'.
Error %d\n",
name, err);
--
1.7.10.4
--
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/
