Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Dec 2005 06:51:24 -0800
From:      Jason Evans <jasone@freebsd.org>
To:        Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc:        cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/kern kern_malloc.c
Message-ID:  <31F147B1-AC12-4479-9376-4550A163503C@freebsd.org>
In-Reply-To: <200512280153.jBS1rEd6086940@repoman.freebsd.org>
References:  <200512280153.jBS1rEd6086940@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 27, 2005, at 5:53 PM, Pawel Jakub Dawidek wrote:
> pjd         2005-12-28 01:53:13 UTC
>
>   FreeBSD src repository
>
>   Modified files:
>     sys/kern             kern_malloc.c
>   Log:
>   In realloc(9), determine size of the original block based on
>   UMA_SLAB_MALLOC flag.
>   In some circumstances (I observed it when I was doing a lot of  
> reallocs)
>   UMA_SLAB_MALLOC can be set even if us_keg != NULL.
>
>   If this is the case we have wonderful, silent data corruption,  
> because less
>   data is copied to the newly allocated region than should be.
>
>   I'm not sure when this bug was introduced, it could be there  
> undetected
>   for years now, as we don't have a lot of realloc(9) consumers and  
> it was
>   hard to reproduce it...
>   ...but what I know for sure, is that I don't want to know who  
> introduce
>   the bug:) It took me two/three days to track it down (of course  
> most of
>   the time I was looking for the bug in my own code).
>
>   Revision  Changes    Path
>   1.150     +1 -1      src/sys/kern/kern_malloc.c
>
> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sys/kern/ 
> kern_malloc.c.diff?&r1=1.149&r2=1.150&f=H

This bug appears to have been introduced in revision 1.95 (19 March  
2002), and merely kept in place during other changes in revision  
1.133.  Here's the commit log message for revision 1.95:

	This is the first part of the new kernel memory allocator.  This  
replaces
	malloc(9) and vm_zone with a slab like allocator.

This looks like a strong MFC candidate to me.

Jason



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31F147B1-AC12-4479-9376-4550A163503C>