|
|
|
|
|
|
by vsync
4969 days ago
|
|
|
> Only if your libc implements calloc as malloc+memset would this be a problem. Does glibc do that? I just checked (see my reply to the parent) and it doesn't. > In fact the copy on write is probably also done on malloc as well. [...] I don't think any sane kernel will give you someone else's free()'d memory You won't get someone else's freed memory but you're quite likely to get your own back and in that case it won't necessarily be zeroed. |
|
|
Surely the kernel never gives a process it's own pages back. It would keep an unneeded page around that could just be pointing to the zero page.
Reading your other comment I assume what you mean is that it is a two step process where the kernel always gives zero pages but glibc's malloc implementation keeps some stock of pages and will return them back in a malloc() after a free(). That way you're not guaranteed to get zero'd memory on every malloc() since not all of it comes straight from the kernel.
The calloc() implementation has checks for that and will do the clearing when the memory is coming from the glibc stock and not the kernel. But even in that case it's only doing clearing when the page is already in the process address space. So a process will always receive zero pages from the kernel, but the malloc() implementation is made more efficient by giving you back some of your own free()'d memory that from the kernel's point of view was never given back.
Does that sound about right?