storing the extra state for this is not worth it.. and consider that it
opens up the door for the same attitude and approach to things to be 
reapplied to other system calls, and soon a whole horde of weird extra 
bits of state are being kept for this call and that call.. if someone 
wants to go down that route, the best place for it is probably in a 
system that's going to end up being very different from a normal unix 
system... or else be a whole hive of kludges. 
fork bombs can be adequately dealt with from userland, as long as root
has a reserved slot in the process table to get a shell and send signals. 
isildur
On Fri, 6 Dec 2002, Greywolf wrote:

> On Fri, 6 Dec 2002, Jaromir Dolecek wrote:
> 
> # The thttpd (IMO broken) behaviour is exactly why I earlier said it
> # wouldn't help to check rate with which fork() is called by process,
> # since even 'innocent' daemons would trigger the rate check and be
> # put to sleep anyway.
> 
> # Perhaps there is some disagreement on the purpose of user/system
> # limits.
> 
> Perhaps instead of looking at apps which don't have the sense to play nice
> and then pointing to the kernel for responsibility, perhaps it's time to
> fix the apps.
> 
> Idea, though:  How about a one-off 'pseudo-slot' per process (read: bit
> flag) which says 'this process wanted to create more processes after it
> hit its/the limit; begin enforcing delays on process creation', with a
> backoff somewhere which will clear said flag after a suitable amount of
> time?
> 
> # IMHO the limits are there to ensure fair resource usage among users.
> # The limits should be set in a way that the user (or daemon) never
> # really reaches it during normal operation, but so that it would
> # provide safety net should things unexpectedly (due to software bug,
> # malicious user or attack) start behaving oddly and tried to consume
> # unexpected amount of resources.
> 
> This seems reasonable...
> 
> # IMHO the thttpd behaviour is broken. It should really have some
> # limit of 'maximum or running spawned children', rather than spawning
> # unlimited number of childs to serve any incoming requests.
> 
> "Fix the app, or don't port it."
> 
> On another tangent:  Someone mentioned a process getting reniced after
> consuming a significant amount of CPU time.   This only occurs for procs
> which maintain a nice value of 0; if a proc gets reniced to 1 (well, 21
> (which impact is minimal)), the CPU time nice self-adjust never happens.
> So you can see where that goes in the face of a tight-spin process.
> 
> [and yet another tangent, something I've thought on for years:  I note
>  that there is no way to re-renice a process once the priority gets
>  lowered.  Has it occurred to anyone else that it might be useful to have
>  a saved p_nice (p_hnice) to which the original nice value gets saved,
>  which only gets adjusted when the superuser calls setpriority(2), but could
>  otherwise allow a process to readjust its nice value?  Or is this too open
>  to DoS?]
> 
> 				--*greywolf;
> --
> NetBSD: No Sh;t!
> 
>