but only the processes that emulate threads (with LINUX_CLONE_THREAD
set).
This fix a problem for child processes that share address space with
the parent. At exit, the child will die silently, leaving the parent
waiting indefinitely for its end ...
pushing the syncer before considering rate limiting the deletes. We hold
vnodes locked and it's likely that the syncer will try to lock them while
flushing, leading to the syncer and remover proceeding in lockstep and
making very little forward progress. XXX this is not a solution.
- Use atomic ops directly, since rwlocks work the same way on all platforms.
- Try to make it a bit more cache efficient, and use branch hints.
- Fix a bug in rw_downgrade() where the turnstile lock was not released.
- Remove a couple of redundant assertions.
- Use atomic_swap instead of atomic_cas where it's safe to do so.
- After acquiring the turnstile lock in rw_vector_enter, check if the
owner is running again and spin if so.
- Introduce and use rw_onproc() instead of abusing mutex_onproc().
- Change the handoff/release algorithm to reduce the window when a rwlock
can held, but the owner not on a CPU.
* Asynchronous operation with result retrieval via select/poll
* Mutliple-request submit/retrieve ioctls
* Mutliple-session create-destroy ioctls
Revise/rewrite crypto.4 manual page. It should now be much easier to write
new applications to this API.
Measured performance for trivial requests: 84,000 very short modular math
operations/sec, 120,000 very short md5 hashes per sec (with a hardware
accellerator of moderate performance but very low latency, whose driver
will be contributed at a later date).
Contributed to TNF by Coyote Point Systems, Inc.
The BN_from_montgomery function in crypto/bn/bn_mont.c in OpenSSL 0.9.8e and
earlier does not properly perform Montgomery multiplication, which might
allow local users to conduct a side-channel attack and retrieve RSA
private keys.
