Date: Wed, 17 Oct 2001 00:30:02 -0700 (PDT) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/31310: pthread broken with KVA_PAGES=512 Message-ID: <200110170730.f9H7U2O16639@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/31310; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: Jason Evans <jasone@canonware.com>
Cc: <freebsd-gnats-submit@FreeBSD.ORG>
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 <sys/param.h>) 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110170730.f9H7U2O16639>