Ned Bass [Thu, 22 Jul 2010 01:53:14 +0000 (18:53 -0700)]
Add extra guard space if needed
Some buggy NPTL threading implementations include the guard area within
the stack size allocations. In this case we need to allocate an extra
page to account for the guard area since we only have two pages of usable
stack on Linux. Added an autoconf test that detects such implementations
by running a test program designed to segfault if the bug is present.
Set a flag NPTL_GUARD_WITHIN_STACK that is tested to decide if extra
stack space must be allocated for the guard area.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Brian Behlendorf [Tue, 29 Jun 2010 06:45:08 +0000 (23:45 -0700)]
Additional pthread related fixes for ztest
There are 3 fixes in thie commit. First, update ztest_run() to store
the thread id and not the address of the kthread_t. This will be freed
on thread exit and is not safe to use. This is pretty close to how
things were done in the original ztest code before I got there.
Second, for extra paranoia update thread_exit() to return a special
TS_MAGIC value via pthread_exit(). This value is then verified in
pthread_join() to ensure the thread exited cleanly. This can be
done cleanly because the kthread doesn't provide a return code
mechanism we need to worry about.
Third, replace the ztest deadman thread with a signal handler. We
cannot use the previous approach because the correct behavior for
pthreads is to wait for all threads to exit before terminating the
process. Since the deadman thread won't call exit by design we
end up hanging in kernel_exit(). To avoid this we just setup a
SIGALRM signal handle and register a deadman alarm. IMHO this
is simpler and cleaner anyway.
Brian Behlendorf [Sun, 27 Jun 2010 22:06:49 +0000 (15:06 -0700)]
Allow joinable threads
There was previous discussion of a race with joinable threads but to
be honest I can neither exactly remember the race, or recrease the
issue. I believe it may have had to do with pthread_create() returning
without having set kt->tid since this was done in the created thread.
If that was the race then I've 'fixed' it by ensuring the thread id
is set in the thread AND as the first pthread_create() argument. Why
this wasn't done originally I'm not sure, with luck Ricardo remembers.
Additionally, explicitly set a PAGESIZE guard frame at the end of the
stack to aid in detecting stack overflow. And add some conditional
logic to set STACK_SIZE correctly for Solaris.
Brian Behlendorf [Mon, 14 Jun 2010 23:20:44 +0000 (16:20 -0700)]
Add fix-pthreads topic branch
This is a portability change which removes the dependence of the Solaris
thread library. All locations where Solaris thread API was used before
have been replaced with equivilant Solaris kernel style thread calls.
In user space the kernel style threading API is implemented in term of
the portable pthreads library. This includes all threads, mutexs,
condition variables, reader/writer locks, and taskqs.
Along with the addition of signed kernel modules in newer kernel
we have a few new build products we need to ignore. LKLM has the
whole thread for those interested: http://lkml.org/lkml/2007/2/14/164
Brian Behlendorf [Sat, 12 Dec 2009 00:15:33 +0000 (16:15 -0800)]
Pull in latest man pages as part of update-zfs.sh
The script has been updated to download the latest documentations
packages for Solaris and extract the needed ZFS man pages. These
will still need a little markup to handle changes between the
Solaris and Linux versions of ZFS. Howver, they should be pretty
minor I've tried hard to keep the interface the same.
In additional to the script update the zdb, zfs, and zpool man
pages have been added to the repo.
Brian Behlendorf [Wed, 10 Dec 2008 20:43:20 +0000 (12:43 -0800)]
Remove libumem, we will try and remove this dependency entirely. If we can't then the best move will simply be to use the official library, or build it as a convenience library
Rebase to OpenSolaris b103, in the process we are removing any code which did not originate from the OpenSolaris source. These changes will be reintroduced in topic branches for easier tracking
Brian Behlendorf [Wed, 26 Nov 2008 22:06:23 +0000 (14:06 -0800)]
Additional buidl system cleanup. Starting to move all
of the kernel specific build info in to config/kernel,
likewise and user specific build flags should go in
config/user. This seems like a reasonable way to go.