From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stable-owner@vger.kernel.org>
Received: from szxga02-in.huawei.com ([119.145.14.65]:32400 "EHLO
	szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751481AbbFCDkY (ORCPT
	<rfc822;stable@vger.kernel.org>); Tue, 2 Jun 2015 23:40:24 -0400
Message-ID: <556E766C.80006@huawei.com>
Date: Wed, 3 Jun 2015 11:37:16 +0800
From: Zefan Li <lizefan@huawei.com>
MIME-Version: 1.0
To: Ben Hutchings <ben@decadent.org.uk>,
	Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	stable <stable@vger.kernel.org>
Subject: [BUG] a bug in slub on 3.2 and 3.4
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 7bit
Sender: stable-owner@vger.kernel.org
List-ID: <stable.vger.kernel.org>

I think 3.2 and 3.4 need to backport 43d77867a4f3 ("slub: refactoring unfreeze_partials()")

On 3.4 kernel, we found there are tens of thousands of free task_struct slabs
in the partial list of node 0 when they should have been discarded, which is
essentially a huge memory leak.

Looking into the code, seems the cause is, we check n->nr_partial but the page
might be in n2 where n != n2, and then the page is added to n2->partial though
n2->partial > s->min_partial.

static void unfreeze_partials(struct kmem_cache *s)
{
	...
	while ((page = c->partial)) {
			...
			c->partial = page->next;
			...
			if (!new.inuse && (!n || n->nr_partial > s->min_partial))
				m = M_FREE;
			else {
				struct kmem_cache_node *n2 = get_node(s,
							page_to_nid(page));
				m = M_PARTIAL;
				if (n != n2) {
					...
					n = n2;
					...
				}
		...
	}
	...
}