kern/52533: swsensor module can panic the machine when unloaded

[paul%whooppee.com@localhost]

>Number:         52533
>Category:       kern
>Synopsis:       swsensor module can panic when being unloaded
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 09 05:10:00 +0000 2017
>Originator:     Paul Goyette
>Release:        NetBSD 8.99.2
>Organization:
+------------------+--------------------------+----------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:          |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee dot com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd dot org |
+------------------+--------------------------+----------------------------+
>Environment:
	
	
System: NetBSD speedy.whooppee.com 8.99.2 NetBSD 8.99.2 (SPEEDY 2017-08-30 21:55:55 UTC) #0: Thu Aug 31 03:05:47 UTC 2017 paul%speedy.whooppee.com@localhost:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
	With recent changes to the sysmon_envsys event handling, the
	swsensor module can now easily panic the system.  This seems to
	be the result of a call to callout_halt() specifying a callout
	that has never been initialized.

	This currently affects the running of atf tests (which use the
	swsensor(4) device to exercise sysmon_envsys functionality.
	
>How-To-Repeat:
	Boot a GENERIC kernel, run 'modload swsensor', and then run
	'modunload swsensor'.  BANG!
	
>Fix:
	(As discussed with msaitoh@ and ozaki-r@ in private Email)

	I really think we need to rework the access-control for the
	callout!  I think we might need a 3-state variable instead of a
	single flag bit:

		SME_CALLOUT_INVALID = 0
		SME_CALLOUT_READY   = 1
		SME_CALLOUT_HALTED  = 2

	INVALID is the initial state, before the call to callout_init().
	After we call callout_destroy(), the state gets reset to INVALID.

	READY means that we have successfully called callout_init() and
	we are prepared to schedule events and to service them.  We
	should test for this state before calling _any_ of the other
	callout_*() routines, (except callout_destroy() - see below).

	HALTED means that there are no events scheduled for this callout,
	but the data structure is still initialized and needs to be
	cleaned up.  We need to set this state before we call
	callout_halt() (or callout_stop() unless we intend to schedule a
	new event).  We should confirm we are in this state before we call
	callout_destroy().

	All accesses to the callout state (both read and write) need to
	be protected by the sme->sme_mtx mutex.
	

>Unformatted: