[patch] slub: fix per cpu kmem_cache_cpu array memory leak
David Rientjes
NR_KMEM_CACHE_CPU such structs.
When this array overflows and a struct is allocated by kmalloc(), it may
have an address at the upper bound of this array. If this happens, it
does not get freed and the per cpu kmem_cache_cpu_free pointer will be out
of bounds after kmem_cache_destroy() or cpu offlining.
Cc: Christoph Lameter <c...@linux-foundation.org>
Signed-off-by: David Rientjes <rien...@google.com>
---
mm/slub.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1996,7 +1996,7 @@ static struct kmem_cache_cpu *alloc_kmem_cache_cpu(struct kmem_cache *s,
static void free_kmem_cache_cpu(struct kmem_cache_cpu *c, int cpu)
{
if (c < per_cpu(kmem_cache_cpu, cpu) ||
- c > per_cpu(kmem_cache_cpu, cpu) + NR_KMEM_CACHE_CPU) {
+ c >= per_cpu(kmem_cache_cpu, cpu) + NR_KMEM_CACHE_CPU) {
kfree(c);
return;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Pekka Enberg
> The per cpu array of kmem_cache_cpu structures accomodates
> NR_KMEM_CACHE_CPU such structs.
>
> When this array overflows and a struct is allocated by kmalloc(), it may
> have an address at the upper bound of this array. If this happens, it
> does not get freed and the per cpu kmem_cache_cpu_free pointer will be out
> of bounds after kmem_cache_destroy() or cpu offlining.
>
> Cc: Christoph Lameter <c...@linux-foundation.org>
> Signed-off-by: David Rientjes <rien...@google.com>
Applied, thanks!
Pekka Enberg
>> The per cpu array of kmem_cache_cpu structures accomodates
>> NR_KMEM_CACHE_CPU such structs.
>>
>> When this array overflows and a struct is allocated by kmalloc(), it may
>> have an address at the upper bound of this array. If this happens, it
>> does not get freed and the per cpu kmem_cache_cpu_free pointer will be out
>> of bounds after kmem_cache_destroy() or cpu offlining.
>>
>> Cc: Christoph Lameter <c...@linux-foundation.org>
>> Signed-off-by: David Rientjes <rien...@google.com>
On Wed, Jan 28, 2009 at 10:52 AM, Pekka Enberg <pen...@cs.helsinki.fi> wrote:
> Applied, thanks!
Btw, did you hit this bug during testing or did you just spot it
during review? That is, do we need to get this to -stable?
Pekka Enberg
On Wed, 28 Jan 2009, Pekka Enberg wrote:
> > Btw, did you hit this bug during testing or did you just spot it
> > during review? That is, do we need to get this to -stable?
On Wed, 2009-01-28 at 01:20 -0800, David Rientjes wrote:
> I ran into it while hacking the per cpu arrays, but haven't witnessed it
> on a vanilla kernel. Since there are no guarantees that a kmem_cache_cpu
> will not be allocated on this boundary, I would recommend it for -stable.
Documentation/stable_kernel_rules.txt states that:
- It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing).
The bug has been there for a very long time and hasn't generated any bug
reports so I think I'll just push it to mainline and leave it that.
Thanks!
Pekka
David Rientjes
> Btw, did you hit this bug during testing or did you just spot it
> during review? That is, do we need to get this to -stable?
>
I ran into it while hacking the per cpu arrays, but haven't witnessed it
on a vanilla kernel. Since there are no guarantees that a kmem_cache_cpu
will not be allocated on this boundary, I would recommend it for -stable.
Christoph Lameter
> The bug has been there for a very long time and hasn't generated any bug
> reports so I think I'll just push it to mainline and leave it that.
Typically we do not run out of elements of the per cpu array.
Note that this code can be removed if we finally get a per cpu allocator.