All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-mm <linux-mm@kvack.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] SLOB's krealloc() seems bust
Date: Tue, 07 Oct 2008 10:00:55 -0500	[thread overview]
Message-ID: <1223391655.13453.344.camel@calx> (raw)
In-Reply-To: <48EB6D2C.30806@linux-foundation.org>


On Tue, 2008-10-07 at 09:07 -0500, Christoph Lameter wrote:
> > Which basically shows us that the content of the pcpu_size[] array got
> > corrupted after the krealloc() call in split_block().
> > 
> > Which made me look at which slab allocator I had selected, which turned
> > out to be SLOB (from testing the network swap stuff).
> 
> krealloc() is in generic core code (mm/util.c) and is the same for all allocators.
> 
> krealloc uses ksize() which is somewhat dicey for SLOB because it only works
> on kmalloc'ed memory. Is the krealloc used on memory allocated with kmalloc()?
> Slob's ksize could use a BUG_ON for the case in which ksize() is used on
> kmem_cache_alloc'd memory.
> 
> /* can't use ksize for kmem_cache_alloc memory, only kmalloc */
> size_t ksize(const void *block)
> {
>         struct slob_page *sp;
> 
>         BUG_ON(!block);
>         if (unlikely(block == ZERO_SIZE_PTR))
>                 return 0;
> 
>         sp = (struct slob_page *)virt_to_page(block);
> 
> 
> Add a BUG_ON(!kmalloc_cache(sp))?

We can't dynamically determine whether a pointer points to a kmalloced
object or not. kmem_cache_alloc objects have no header and live on the
same pages as kmalloced ones.

>         if (slob_page(sp))
>                 return ((slob_t *)block - 1)->units + SLOB_UNIT;
> 			^^^^^^^ Is this correct?

The cast? Yes. We want to look at the slob_t object header immediately
before the object pointer.

But the rest of the statement looks completely broken. If our SLOB
object is 3 units (6 bytes), with a usuable size of 4 bytes, the above
will report 3 + 2 = 5 bytes. Instead we want (3 - 1) * 2 = 4, something
more like:

	return (((slob_t *)block - 1)->units - 1) * SLOB_UNIT;
			
It's a bit amazing no one's hit this before, but I guess that's because
for allocations > 6 bytes, it will under-report buffer sizes, avoiding
overruns. And for the < 6 byte cases, we've just been getting lucky.

Give this a try, please:

diff -r 5e32b09a1b2b mm/slob.c
--- a/mm/slob.c	Fri Oct 03 14:04:43 2008 -0500
+++ b/mm/slob.c	Tue Oct 07 10:00:16 2008 -0500
@@ -515,7 +515,7 @@
 
 	sp = (struct slob_page *)virt_to_page(block);
 	if (slob_page(sp))
-		return ((slob_t *)block - 1)->units + SLOB_UNIT;
+		return (((slob_t *)block - 1)->units - 1) * SLOB_UNIT;
 	else
 		return sp->page.private;
 }

-- 
Mathematics is the supreme nostalgia of our time.


WARNING: multiple messages have this Message-ID (diff)
From: Matt Mackall <mpm@selenic.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-mm <linux-mm@kvack.org>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] SLOB's krealloc() seems bust
Date: Tue, 07 Oct 2008 10:00:55 -0500	[thread overview]
Message-ID: <1223391655.13453.344.camel@calx> (raw)
In-Reply-To: <48EB6D2C.30806@linux-foundation.org>

On Tue, 2008-10-07 at 09:07 -0500, Christoph Lameter wrote:
> > Which basically shows us that the content of the pcpu_size[] array got
> > corrupted after the krealloc() call in split_block().
> > 
> > Which made me look at which slab allocator I had selected, which turned
> > out to be SLOB (from testing the network swap stuff).
> 
> krealloc() is in generic core code (mm/util.c) and is the same for all allocators.
> 
> krealloc uses ksize() which is somewhat dicey for SLOB because it only works
> on kmalloc'ed memory. Is the krealloc used on memory allocated with kmalloc()?
> Slob's ksize could use a BUG_ON for the case in which ksize() is used on
> kmem_cache_alloc'd memory.
> 
> /* can't use ksize for kmem_cache_alloc memory, only kmalloc */
> size_t ksize(const void *block)
> {
>         struct slob_page *sp;
> 
>         BUG_ON(!block);
>         if (unlikely(block == ZERO_SIZE_PTR))
>                 return 0;
> 
>         sp = (struct slob_page *)virt_to_page(block);
> 
> 
> Add a BUG_ON(!kmalloc_cache(sp))?

We can't dynamically determine whether a pointer points to a kmalloced
object or not. kmem_cache_alloc objects have no header and live on the
same pages as kmalloced ones.

>         if (slob_page(sp))
>                 return ((slob_t *)block - 1)->units + SLOB_UNIT;
> 			^^^^^^^ Is this correct?

The cast? Yes. We want to look at the slob_t object header immediately
before the object pointer.

But the rest of the statement looks completely broken. If our SLOB
object is 3 units (6 bytes), with a usuable size of 4 bytes, the above
will report 3 + 2 = 5 bytes. Instead we want (3 - 1) * 2 = 4, something
more like:

	return (((slob_t *)block - 1)->units - 1) * SLOB_UNIT;
			
It's a bit amazing no one's hit this before, but I guess that's because
for allocations > 6 bytes, it will under-report buffer sizes, avoiding
overruns. And for the < 6 byte cases, we've just been getting lucky.

Give this a try, please:

diff -r 5e32b09a1b2b mm/slob.c
--- a/mm/slob.c	Fri Oct 03 14:04:43 2008 -0500
+++ b/mm/slob.c	Tue Oct 07 10:00:16 2008 -0500
@@ -515,7 +515,7 @@
 
 	sp = (struct slob_page *)virt_to_page(block);
 	if (slob_page(sp))
-		return ((slob_t *)block - 1)->units + SLOB_UNIT;
+		return (((slob_t *)block - 1)->units - 1) * SLOB_UNIT;
 	else
 		return sp->page.private;
 }

-- 
Mathematics is the supreme nostalgia of our time.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2008-10-07 15:04 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 13:57 [BUG] SLOB's krealloc() seems bust Peter Zijlstra
2008-10-07 13:57 ` Peter Zijlstra
2008-10-07 14:07 ` Christoph Lameter
2008-10-07 14:07   ` Christoph Lameter
2008-10-07 14:13   ` Peter Zijlstra
2008-10-07 14:13     ` Peter Zijlstra
2008-10-07 14:26     ` Christoph Lameter
2008-10-07 14:26       ` Christoph Lameter
2008-10-07 15:00   ` Matt Mackall [this message]
2008-10-07 15:00     ` Matt Mackall
2008-10-07 15:20     ` Christoph Lameter
2008-10-07 15:20       ` Christoph Lameter
2008-10-07 15:58       ` Matt Mackall
2008-10-07 15:58         ` Matt Mackall
2008-10-07 16:10     ` Peter Zijlstra
2008-10-07 16:10       ` Peter Zijlstra
2008-10-07 16:37       ` Linus Torvalds
2008-10-07 16:37         ` Linus Torvalds
2008-10-07 16:37       ` Matt Mackall
2008-10-07 16:37         ` Matt Mackall
2008-10-07 16:57         ` Pekka Enberg
2008-10-07 16:57           ` Pekka Enberg
2008-10-07 17:13           ` Matt Mackall
2008-10-07 17:13             ` Matt Mackall
2008-10-07 17:31             ` Pekka Enberg
2008-10-07 17:31               ` Pekka Enberg
2008-10-07 23:08               ` Matt Mackall
2008-10-07 23:08                 ` Matt Mackall
2008-10-08  4:22                 ` Nick Piggin
2008-10-08  4:22                   ` Nick Piggin
2008-10-08  4:46                   ` Matt Mackall
2008-10-08  4:46                     ` Matt Mackall
2008-10-08  4:54                     ` Nick Piggin
2008-10-08  4:54                       ` Nick Piggin
2008-10-08  5:11                       ` Nick Piggin
2008-10-08  5:11                         ` Nick Piggin
2008-10-08  5:15                         ` Matt Mackall
2008-10-08  5:15                           ` Matt Mackall
2008-10-08  6:43                           ` Peter Zijlstra
2008-10-08  6:43                             ` Peter Zijlstra
2008-10-08  7:25                             ` Pekka Enberg
2008-10-08  7:25                               ` Pekka Enberg
2008-10-08  7:37                               ` Peter Zijlstra
2008-10-08  7:37                                 ` Peter Zijlstra
2008-10-08  7:39                                 ` Pekka Enberg
2008-10-08  7:39                                   ` Pekka Enberg
2008-10-07 17:57         ` Linus Torvalds
2008-10-07 17:57           ` Linus Torvalds
2008-10-07 18:11           ` Peter Zijlstra
2008-10-07 18:11             ` Peter Zijlstra
2008-10-07 18:18             ` Linus Torvalds
2008-10-07 18:18               ` Linus Torvalds
2008-10-08 19:51               ` Matt Mackall
2008-10-08 19:51                 ` Matt Mackall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1223391655.13453.344.camel@calx \
    --to=mpm@selenic.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.