Zeroed pages returned for heap

From: Nagendra Singh Tomar
Date: Mon Jun 06 2005 - 23:13:20 EST


Hi all,
The short version first.
Is it OK for an application (a C library implementing malloc/calloc is
also an application) to assume that the pages returned by the OS for heap
allocation (either directly thru brk() or thru mmap(MAP_ANONYMOUS)) will
be zero filled.

Now a lengthier version.

Linux zero fills all anonymous pages on allocation. This is _required_ for
the C program BSS sections but _not_ _really_ required for heap pages. For
heap pages the kernel zero fills them to avoid leaking any important
information to users. On my target platform (Xscale) the memory access is
such a big evil that I am constantly thinking of ways to avoid touching
the damned memory as much as possible without any adverse effect on the
kernel and applications behaviour.
One such way which I want to exploit is to not zero fill the heap
pages (since mine is an embedded hardware, I do not care much abt leaking
information out to users), since profiling has shown that the
xscale_mc_clear_user_page function is taking lots of CPU time. When I
implement that I see that few applications namely gcc and awk break. It
seems that either the application or the C library is assuming about the
pages returned by brk()/MAP_ANON, probably to improve calloc() efficiency
( I'm not 100% sure on that as I've not yet looked at the code).
For testing I implemented this on x86 first and could boot the complete
kernel and was able to start X, only that gcc used to crash.

I'll highly appreciate any informative views on this.

Thanx,
Tomar



-- You have moved the mouse. Windows must be restarted for the
changes to take effect.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/