On Thu, Dec 12, 2002 at 11:10:48PM +0100, Jaromir Dolecek wrote:
> Hi,
> I'm currently trying to address port-i386/1635. Since the same issue
> might be present on other archs, and this needs change to generic
> code in any case, I'm cross-posting both port-i386@ and tech-kern@.
> 
> There is a problem presented in the PR that NetBSD/i386 can actually
> run maximum 8192 processes at the same time due to how many GDT
> slots are allocated. If kern.maxproc limit is set high enough to
> allow more than 8192 processes, kernel would panic in gdt_get_slot()
> once there is enough running processes. Easy way to trigger this
> panic would be to set kern.maxproc=10000, change current process
> limits high enough and run forkbomb like:
> 
> > cat me.c
> int
> main() {
> 	while(1) {
> 		if (fork() == 0)
> 			execl("./me", "me", NULL);
> 	}
> }
> >
> 
> My solution to this is adding optional arch-specific hook
> to kern_sysctl.c, which would not allow setting maxproc to
> higher than arch-specific maximum. Patch is below.
> It does not deal with maxproc being bumped via NPROC kernel
> option; I assume that people using NPROC option know what
> they are doing. Perhaps a #ifdef DEBUG check in init_main() might
> be appropriate for this.
> 
> Comments?

Looks reasonable to me.

> Is the ((MAXGDTSIZ - NGDT)/2) really needed in USER_LDT case for i386?

AFAIK, USER_LDT is only used by Wine. Each Windows app can have up to 2
LDT entries in GDT, one for app itself, and optionally, one for DPMI
int 0x31 interface. However, I don't think "/ 2" is necessary, since
very few Windows apps actually use DPMI and hardly anybody is running
such program under Wine & NetBSD these days (if someone _really_ wanted
to run one, I'd recommend that he buy a copy of Win9X).

Jun-Young

-- 
Bang Jun-Young <junyoung@netbsd.org>