Commit Graph

13 Commits

Author SHA1 Message Date
John Baldwin
0f180a7cce Change msleep() and tsleep() to not alter the calling thread's priority
if the specified priority is zero.  This avoids a race where the calling
thread could read a snapshot of it's current priority, then a different
thread could change the first thread's priority, then the original thread
would call sched_prio() inside msleep() undoing the change made by the
second thread.  I used a priority of zero as no thread that calls msleep()
or tsleep() should be specifying a priority of zero anyway.

The various places that passed 'curthread->td_priority' or some variant
as the priority now pass 0.
2006-04-17 18:20:38 +00:00
Paul Saab
efbbe8fa79 Remove GIANT from device random.
Submitted by:	ups
2005-12-20 21:41:52 +00:00
Mark Murray
3a0323d92f Revert to the more correct array size, and correct a KASSERT to
only allow proper values. ENTROPYSOURCE is a maxval+1, not an
allowable number.

Suggested loose protons in the solution:	phk
Prefers to keep the pH close to seven:		markm
2005-03-29 11:08:45 +00:00
Poul-Henning Kamp
f7e6cbd933 Fix off-by-one (too little!) array size problem.
Detected by:	Coverity (ID#661)
2005-03-18 07:13:35 +00:00
Poul-Henning Kamp
4c4a94cefe Check O_NONBLOCK not IO_NDELAY.
Don't include vnode.h
2004-12-22 17:29:37 +00:00
John Baldwin
6ac27fe1e6 Don't change the priority to PUSER when sleeping, just keep the current
priority.
2004-11-05 20:15:06 +00:00
Robert Watson
b899bc84c5 (1) Move from O(n) list copies to O(1) list concatenation, which is
supported for STAILQ via STAILQ_CONCAT().

(2) Maintain a count of the number of entries in the thread-local entropy
    fifo so that we can keep the other fifo counts in synch.

MFC after:	3 weeks
MFC with:	randomdev_soft.c revisions 1.5 and 1.6
Suggested by:   jhb (1)
2004-11-03 10:02:50 +00:00
Robert Watson
f5c3a74502 Assert that the entropy source category provided by a caller submitting
entropy is valid, as an invalid source will cause dereferencing of an
array of queues to an incorrect memory location.
2004-10-12 14:57:14 +00:00
Robert Watson
a28ce935d9 Modify entropy harvesting locking strategy:
- Trade off granularity to reduce overhead, since the current model
  doesn't appear to reduce contention substantially: move to a single
  harvest mutex protecting harvesting queues, rather than one mutex
  per source plus a mutex for the free list.

- Reduce mutex operations in a harvesting event to 2 from 4, and
  maintain lockless read to avoid mutex operations if the queue is
  full.

- When reaping harvested entries from the queue, move all entries from
  the queue at once, and when done with them, insert them all into a
  thread-local queue for processing; then insert them all into the
  empty fifo at once.  This reduces O(4n) mutex operations to O(2)
  mutex operations per wakeup.

In the future, we may want to look at re-introducing granularity,
although perhaps at the granularity of the source rather than the
source class; both the new and old strategies would cause contention
between different instances of the same source (i.e., multiple
network interfaces).

Reviewed by:	markm
2004-10-09 22:04:13 +00:00
Robert Watson
38c9c1708b Perform a lockless read to test whether an entropy havesting fifo is
full, avoiding the cost of mutex operations if it is.  We re-test
once the mutex is acquired to make sure it's still true before doing
the -modify-write part of the read-modify-write.  Note that due to
the maximum fifo depth being pretty deep, this is unlikely to improve
harvesting performance yet.

Approved by:	markm
2004-08-11 03:33:32 +00:00
Mark Murray
587d5fc63b Start the entropy device insecure/unblocked. I'll be handing over
responsibility for critical randomness requirements (like sshd)
to rc.d/*

Requested by: many
2004-07-18 09:07:58 +00:00
Mark Murray
2a8b87d883 Default to harvesting everything. This is to help give a faster
startup. harvesting can be turned OFF in etc/rc.d/* if it is a
burden.
2004-04-16 17:07:11 +00:00
Mark Murray
e7806b4c0e Reorganise the entropy device so that high-yield entropy sources
can more easily be used INSTEAD OF the hard-working Yarrow.
The only hardware source used at this point is the one inside
the VIA C3 Nehemiah (Stepping 3 and above) CPU. More sources will
be added in due course. Contributions welcome!
2004-04-09 15:47:10 +00:00