[BUG] a bug in slub on 3.2 and 3.4

[BUG] a bug in slub on 3.2 and 3.4

[Zefan Li]

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;
					...
				}
		...
	}
	...
}

RE: [BUG] a bug in slub on 3.2 and 3.4

[Joonsoo Kim]

> -----Original Message-----
> From: Zefan Li [mailto:lizefan@huawei.com]
> Sent: Wednesday, June 03, 2015 12:37 PM
> To: Ben Hutchings; Christoph Lameter; Pekka Enberg; Joonsoo Kim; stable
> Subject: [BUG] a bug in slub on 3.2 and 3.4
> 
> 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.

Looks like it's possible scenario.
And, yes, commit 43d77867a4f3 will fix the issue.

Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>

Thanks.

Re: [BUG] a bug in slub on 3.2 and 3.4

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Wed, 2015-06-03 at 11:37 +0800, Zefan Li wrote:
> 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.
[...]

Thanks, I've queued this up for 3.2 with a small adjustment.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that there are so many of them.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]