kern/49261: cpu_info::ci_want_resched locking protocol

[uebayasi%gmail.com@localhost]

>Number:         49261
>Category:       kern
>Synopsis:       cpu_info::ci_want_resched locking protocol
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 07 14:25:00 +0000 2014
>Originator:     Masao Uebayashi
>Release:        NetBSD 7.99.1
>Organization:
>Environment:
>Description:
Some time ago I found inconsistency about cpu_info::ci_want_resched and asked ad@.  Here is the answer:

When cpu_need_resched() is called from a foreign CPU then spc_lock for the target CPU must be held. When it is called locally, no lock is required. When ci_need_resched is cleared in nextlwp() the local CPU's spc_lock is held. This is sufficient because only the local CPU can reset ci_want_resched back to zero, and we don't care about the true value of ci_want_resched. We just need to know if somebody has tried to set it non-zero. Those locking semantics are enough. However if the individual bits of ci_want_resched were significant, then we would need to hold spc_lock everywhere it is used. 

There are two minor bugs.. We should not be ORing bit values into ci_want_resched like x86 does because the only semantic we support is storing 1 (nonzero). We should also not be using atomics like powerpc does, because there is no need. 
>How-To-Repeat:

>Fix: