From owner-freebsd-bugs Wed Oct 17 0:30:10 2001 Delivered-To: freebsd-bugs@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2955A37B409 for ; Wed, 17 Oct 2001 00:30:02 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f9H7U2O16639; Wed, 17 Oct 2001 00:30:02 -0700 (PDT) (envelope-from gnats) Date: Wed, 17 Oct 2001 00:30:02 -0700 (PDT) Message-Id: <200110170730.f9H7U2O16639@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Bruce Evans Subject: Re: kern/31310: pthread broken with KVA_PAGES=512 Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR kern/31310; it has been noted by GNATS. From: Bruce Evans To: Jason Evans Cc: Subject: Re: kern/31310: pthread broken with KVA_PAGES=512 Date: Wed, 17 Oct 2001 17:23:15 +1000 (EST) On Tue, 16 Oct 2001, Jason Evans wrote: > I'm not sure I understand what you're doing, so let me try to summarize my > understanding before guessing what the problem is. It sounds like you are > changing the amount of address space reserved for the kernel, which affects > where the userland stack is mapped. Look in > src/lib/libc_r/uthread/uthread_init.c for the mmap() call that creates the > red zone: > > /* > * Create a red zone below the main stack. All other stacks are > * constrained to a maximum size by the paramters passed to > * mmap(), but this stack is only limited by resource limits, so > * this stack needs an explicitly mapped red zone to protect the > * thread stack that is just beyond. > */ > if (mmap((void *) USRSTACK - PTHREAD_STACK_INITIAL - > PTHREAD_STACK_GUARD, PTHREAD_STACK_GUARD, 0, MAP_ANON, > -1, 0) == MAP_FAILED) > PANIC("Cannot allocate red zone for initial thread"); > > The code depends on the USRSTACK macro when determining where to create the > red zone, and I suspect that its value is somewhere in kernel memory in > your case. > > From src/sys/i386/include/vmparam.h: > > #define VM_MAXUSER_ADDRESS VADDR(UMAXPTDI, UMAXPTEOFF) > > #define USRSTACK VM_MAXUSER_ADDRESS > > Please let me know if after further diagnostic effort you discover this to > be an actual problem in libc_r. Code like this (actually mainly bogus definitions of non-constants as constant in ) is very broken. USRSTACK depends on the kernel option KVA_PAGES. Userland can't see kernel options headers, so USRSTACK should not be visible in userland. But i386/include/param.h provides a bogus default for KVA_PAGES and consequently USRSTACK to move the breakage from compile time to run time. Some other bogus non-constant constants: - OPEN_MAX and CHILD_MAX. - PAGE_SIZE and pgtok() leaked out to userland a long time ago, desipite the existence of syscall and a sysctl to insulate them. PAGE_SIZE is now an option on ia64's. - UPAGES. - MAXDSIZE, etc. There are now tunables. Anyone tuning them had better know all related magic addresses used deep in places like the above. There was some discussion of making them (variable) rlimits. This stalled on the complications for knowing all the magic addresses and keeping them separate. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message