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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
