the target thread of the join operation. This allows the cancelled
thread to detach the target thread in its cancellation handler.
This bug was found by Butenhof's cancel_subcontract test.
Reviewed by: jasone
o) Since we unwrap the sendfile syscall, check the return value of
writev(2) to see if it didn't complete all the data.
Previously if only a partial writev() succeeded, it would proceed
to sendfile(2) even though the headers weren't completely sent.
o) Properly adjust the "bytes to send" to take into account sendfile(2)'s
behaviour of counting the headers against the bytes to be transfered
from the file.
o) Correct the problem where EAGAIN was being returned from _sys_sendfile(2)
however the wrapper didn't update the 'sent bytes' parameter to take into
account for it. This is because sendfile can return EAGAIN even though
it has actually transfered data.
Special thanks to Justin Erenkrantz <jerenkrantz@apache.org> for bringing
this to my attention and giving an excellent way to reproduce the problem.
PR: kern/32684
MFC After: 1 week
kernel #defines to figure out where the stack is located. This stops
libc_r from exploding when the kernel is compiled with a different
KVM size. IMHO this is all kinda bogus, it would be better to just
check %esp and work from that.
- uthread_signal.c; libc_r does not wrap signal() since 1998/04/29.
- uthread_attr_setprio.c; it was never connected to the build, and
pthread_attr_setprio() does not exist in POSIX.
- uthread_sigblock.c and uthread_sigsetmask.c; these were no-ops
bloating libc_r's space.
pthread_private.h:
- Removed prototypes of non-syscalls: send().
- Removed prototypes of unused syscalls: sigpending(), sigsuspend(),
and select().
- Fixed prototype of fork().
- MFS: Fixed prototypes of <sys/socket.h> syscalls.
Reviewed by: deischen
Approved by: deischen, jasone
In libc_r, if _FDLOCKS_ENABLED is not defined, there is no guarantee
in many of the sycall wrappers that _thread_fd_table[fd] is
initialized. This causes problems for programs that pass in file
descriptors and execve() another program; when the exec'ed program
tries to do an fcntl() or other syscall on the passed-in fd, it fails.
Add calls to initialize the FD table entry for _thread_fd_lock and
_thread_fd_lock_debug.
Submitted by: Peter S. Housel <housel@acm.org>
be malloc()ed, but they are now allocated using mmap(), just as the
default-size stacks are. A separate cache of stacks is kept for
non-default-size stacks.
Collaboration with: deischen
atomically:
1) Search _thread_list for the thread to join.
2) Search _dead_list for the thread to join.
3) Set the running thread as the joiner.
While we're at it, fix a race in the case where multiple threads try to
join on the same thread. POSIX says that the behavior of multiple joiners
is undefined, but the fix is cheap as a result of the other fix.
keep track of a joiner. POSIX only supports a single joiner, so this
simplification is acceptable.
At the same time, make sure to mark a joined thread as detached so that
its resources can be freed.
Reviewed by: deischen
PR: 24345
there is no need to wake all waiters to assure that the highest priority
thread is run. As the semaphore code is written, there was no correctness
problem, but the change improves sem_post() performance.
Pointed out by: deischen
process on fork(2).
It is the supposed behavior stated in the manpage of sigaction(2), and
Solaris, NetBSD and FreeBSD 3-STABLE correctly do so.
The previous fix against libc_r/uthread/uthread_fork.c fixed the
problem only for the programs linked with libc_r, so back it out and
fix fork(2) itself to help those not linked with libc_r as well.
PR: kern/26705
Submitted by: KUROSAWA Takahiro <fwkg7679@mb.infoweb.ne.jp>
Tested by: knu, GOTOU Yuuzou <gotoyuzo@notwork.org>,
and some other people
Not objected by: hackers
MFC in: 3 days
placed in any scheduling queue(s). The process of dispatching
signals to a thread can change its state which will attempt to add
or remove the thread from any scheduling queue to which it belongs.
This can break some assertions if the thread isn't in the queue(s)
implied by its state.
When adding dispatching a pending signal to a thread, be sure to
remove the signal from the threads set of pending signals.
PR: 27035
Tested by: brian
MFC in: 1 week
a "#pragma weak" directive linking the external symbol. This matches
the other pthread_* definitions, and ensures that users of this
function from within libc get the real version, not the stub.
Suggested by: deischen
Reviewed by: deischen, alfred
associated changes that had to happen to make this possible as well as
bugs fixed along the way.
Bring in required TLI library routines to support this.
Since we don't support TLI we've essentially copied what NetBSD
has done, adding a thin layer to emulate direct the TLI calls
into BSD socket calls.
This is mostly from Sun's tirpc release that was made in 1994,
however some fixes were backported from the 1999 release (supposedly
only made available after this porting effort was underway).
The submitter has agreed to continue on and bring us up to the
1999 release.
Several key features are introduced with this update:
Client calls are thread safe. (1999 code has server side thread
safe)
Updated, a more modern interface.
Many userland updates were done to bring the code up to par with
the recent RPC API.
There is an update to the pthreads library, a function
pthread_main_np() was added to emulate a function of Sun's threads
library.
While we're at it, bring in NetBSD's lockd, it's been far too
long of a wait.
New rpcbind(8) replaces portmap(8) (supporting communication over
an authenticated Unix-domain socket, and by default only allowing
set and unset requests over that channel). It's much more secure
than the old portmapper.
Umount(8), mountd(8), mount_nfs(8), nfsd(8) have also been upgraded
to support TI-RPC and to support IPV6.
Umount(8) is also fixed to unmount pathnames longer than 80 chars,
which are currently truncated by the Kernel statfs structure.
Submitted by: Martin Blapp <mb@imp.ch>
Manpage review: ru
Secure RPC implemented by: wpaul
application to provide locking for I/O operations. This doesn't
break any of my tests, but the old behavior can be restored by
compiling with _FDLOCKS_ENABLED. This will eventually be removed
when it is obvious it does not cause any problems.
Remove most of flockfile implementation, with the exception of
flockfile_debug.
Make error messages more informational (submitted by Mike Heffner
<spock@techfour.net>, who's now known as mikeh@FreeBSD.org).
Add another check for thread library initialization (jdp, we
really need a way to get _thread_init called at program start
before any constructors are run).
_foo - wrapped system call
foo - weak definition to _foo
and for cancellation points:
_foo - wrapped system call
__foo - enter cancellation point, call _foo(), leave
cancellation point
foo - weak definition to __foo
Change use of global _thread_run to call a function to get the
currently running thread.
Make all pthread_foo functions weak definitions to _pthread_foo,
where _pthread_foo is the implementation. This allows an application
to provide its own pthread functions.
Provide slightly different versions of pthread_mutex_lock and
pthread_mutex_init so that we can tell the difference between
a libc mutex and an application mutex. Threads holding mutexes
internal to libc should never be allowed to exit, call signal
handlers, or cancel.
Approved by: -arch
referenced to by libgcc.a.
This is needed when linking statically as SVR4 (ie, ELF) behavior is to only
link in a module if it satisfies an undefined strong reference from somewhere.
(this surprises a lot of people) Things are different when using shared libs,
the entire library and its modules and their symbols are available at run-time
(when the weak reference is seen to still be unsatisfied and is satisfied on
the spot), this is not the case with static libs.
Thus one can have a static binary with unresolved week references, and at
run-time dereference a NULL pointer.
Submitted by: eischen
Submitted by: "Peter Avalos" <pavalos@theshell.com>
Reviewed by: /sbin/md5 [*]
[*] This line appears courtesy of Mr. Warner Losch, all rights reversed.
global time of day. This costs us nothing, but is a bit of a hack
to work around a process blocking and not having the time updated
by an ITIMER_PROF signal.
PR: 23679
executed at least once, fixing pthread_mutex_lock() for recursive
mutex lock attempts.
Correctly set a threads signal mask while it is executing a signal
handler. The mask should be the union of its current mask, the
signal being handled, and the mask from the signal action.
Reported by: Dan Nelson <dnelson@emsphone.com>
MFC Candidate
was not getting properly initialized in pthread_cond_signal()
and pthread_cond_broadcast(). Reportedly, this can cause
an application to die.
MFC candidate
Submitted by: ade
the kernel to (re)use the alternate signal stack. In this
case, we don't return normally from the signal handler,
so the kernel still thinks we are using the signal stack.
The fixes a nasty bug where the signal handler can start
fiddling with the stack of a thread while the handler is
actually running on the same stack.
MFC candidate
