Re: Gigantic memory leak in linux-2.6.[789]!

[David Lang]

On Fri, 22 Oct 2004, Kristian Sørensen wrote:

> Hi all!
>
> After some more testing after the previous post of the OOPS in
> generic_delete_inode, we have now found a gigantic memory leak in Linux 2.6.
> [789]. The scenario is the same:
<SNIP>
> When the loop has completed, the system use 124 MB memory more _each_ time....
> so it is pretty easy to make a denial-of-service attack :-(
>
> We have tried the same test on a RHEL WS 3 host (running a RedHat 2.4 kernel)
> - and there is no problem.
>
>
> Any deas?
>
> --
> Kristian Sørensen
> - The Umbrella Project
>  http://umbrella.sourceforge.net

This is a common mistake that many people make when first looking at the 
Linux stats.

Linux starts off with most of the memory free, but rapidly uses it up. it 
keeps a small amount (a few megs) free at all times, but for the rest 
counts of freeing memory (possibly by swapping) when a new program asks 
for memory and there is less then the minimum amount left free.

It does this becouse there is a chance that the memory will be re-used (in 
your example where you were untaring the kernel source there is a chance 
that someone else would be reading that source and if they did it would 
already be in memory and not have to be re-read from disk) and becouse 
there is a chance that nothing will ever need to use that memory before 
the computer is shut off so it would be a waste of time to do the free 
(which includes zeroing out the memory, not just marking it as available).

This puts the cost of zeroing out and freeing memory on new programs that 
are allocating memory, which tends to scatter the work over time rather 
then having a large burst of work kick in when a program exits (it seems 
odd to think that if a large computer exits the machine would be pegged 
for a little while while it frees up and zeros the memory, not exactly 
what you would expect when you killed a program :-)

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
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/