Bugtraq mailing list archives
Re: Linux inode.i_count overflow
From: dleblanc () MINDSPRING COM (David LeBlanc)
Date: Wed, 14 Jan 1998 16:42:14 -0500
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
Current thread:
- Linux inode.i_count overflow Aleph One (Jan 14)
- Re: Linux inode.i_count overflow Alan Cox (Jan 14)
- Re: Linux inode.i_count overflow David LeBlanc (Jan 14)
- Re: Linux inode.i_count overflow Pete (Jan 14)
- Re: Linux inode.i_count overflow Casper Dik (Jan 14)
- Re: Linux inode.i_count overflow Alan Cox (Jan 14)