Proposed fix; stage 1 (Was: svn commit: r239569 - head/etc/rc.d)

[John Baldwin]

On Wednesday, September 19, 2012 6:08:19 pm David O'Brien wrote:
> Also, I'm having trouble finding the source for 'swi' harvesting.
> Do you know where it is?

It has certainly not been used since 5.0.  I wasn't able to find it
in my limited grubbing around in 4.x sources either.

The untested change below would add it so that all calls to swi_sched() would 
harvest something similar to what happens for hardware interrupts.  Note that 
the current code already explicitly forbids INTR_ENTROPY from being set for 
swi handlers, so the current random_harvest() call in intr_schedule_thread() 
should never trigger for an swi.  I just copied the random_harvest() code from 
the hardware interrupt case.  I leave it up to someone else to explicitly ok 
that this data goes into the RANDOM_INTERRUPT queue with the claim of 2 bits 
of entropy:

Index: sys/kern/kern_intr.c
===================================================================
--- kern_intr.c	(revision 240605)
+++ kern_intr.c	(working copy)
@@ -1144,11 +1144,21 @@ swi_sched(void *cookie, int flags)
 {
 	struct intr_handler *ih = (struct intr_handler *)cookie;
 	struct intr_event *ie = ih->ih_event;
+	struct intr_entropy entropy;
 	int error;
 
 	CTR3(KTR_INTR, "swi_sched: %s %s need=%d", ie->ie_name, ih->ih_name,
 	    ih->ih_need);
 
+	if (harvest.swi) {
+		CTR3(KTR_INTR, "swi_sched: pid %d (%s) gathering entropy",
+		    curproc->p_pid, curthread->td_name);
+		entropy.event = (uintptr_t)ih;
+		entropy.td = curthread;
+		random_harvest(&entropy, sizeof(entropy), 2, 0,
+		    RANDOM_INTERRUPT);
+	}
+
 	/*
 	 * Set ih_need for this handler so that if the ithread is already
 	 * running it will execute this handler on the next pass.  Otherwise,

-- 
John Baldwin