Skip to contentSkip to conversation

a bug in slub on 3.2 and 3.4

BUG Zefan Li 3 participants 3 messages Jun 3, 2015 – Aug 1, 2015 Stable branch

lore
Share & tools
lore

Zefan Li

author
#0 lore raw

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;
					...
				}
		...
	}
	...
}
Acked-by
#1 lore raw
Quoted 17 lines

-----Original Message-----
From: Zefan Li [mailto:[email protected]]
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.

Quoted 5 lines

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 <[email protected]>

Thanks.

#2 lore raw
In reply to Zefan Li
Quoted 9 lines · 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.

[...]

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

Ben.

Signature · 2 lines
Ben Hutchings
One of the nice things about standards is that there are so many of them.