Re: Linux inode.i_count overflow

[dleblanc () MINDSPRING COM (David LeBlanc)]

At 05:49 PM 1/14/98 +0000, Alan Cox wrote:

> >    typical Linux configuration. Although you can avoid users to eat
> >    resources this way by setting resource limits properly this effect can
> >    be considered to be a Linux bug. Linux is protected to avoid
> >    allocating all process slots by normal users. There are reserved
> >    MIN_TASKS_LEFT_FOR_ROOT slots for root. So there should be also
> >    protection to avoid allocating all memory by normal users.

> This seems to be a generic Unix bug. I brought down our SGI with that
> program, and netbsd also seems to jam solid. The general vulnerability
> is going to be the same on all OS's (anyone got an NT port ?) or want
> to make a summary table.

So far as I know, you'll never run NT out of proc table space, since the
limit on nearly every sort of handle under NT is 2^32.  You'll cripple it
from RAM usage long before you run into problems with that.  The same deal
with handles, except I think that one is only 2^32 per _process_.  Don't
think we'll see that turn into much of an issue.  4 billion handles ought
to be enough for anyone <g>

Where you can screw up NT is that the OS has no way to limit any given
user's RAM consumption.  So a very simple while(ptr = malloc(somesize));
ought to bring just about any NT box close to it's knees.  This sort of
nonsense is, however, fixed in NT 5.0.  I have inadvertantly done this to
myself a few times, and it is somewhat interesting - NT gets very, very
slow and quite annoyed.  It will continue running, and under some
conditions will get irate and kill the offending process.  In fact, I did
this last night on my work machine - came in this morning, logged in, noted
that my app had consumed about 1/4 gig of page+RAM, killed the app and went
about my work.


David LeBlanc           |Why would you want to have your desktop user,
dleblanc () mindspring com |your mere mortals, messing around with a 32-bit
                        |minicomputer-class computing environment?
                        |Scott McNealy