CVS commit: [netbsd-6-1] src/sys/kern

["Soren Jacobsen" <snj%netbsd.org@localhost>]

Module Name:    src
Committed By:   snj
Date:           Thu Jul  6 15:19:01 UTC 2017

Modified Files:
        src/sys/kern [netbsd-6-1]: subr_xcall.c

Log Message:
Pull up following revision(s) (requested by ozaki-r in ticket #1419):
        sys/kern/subr_xcall.c: revision 1.19
Fix a race condition of low priority xcall
xc_lowpri and xc_thread are racy and xc_wait may return during/before
executing all xcall callbacks, resulting in a kernel panic at worst.
xc_lowpri serializes multiple jobs by a mutex and a cv. If all xcall
callbacks are done, xc_wait returns and also xc_lowpri accepts a next job.
The problem is that a counter that counts the number of finished xcall
callbacks is incremented *before* actually executing a xcall callback
(see xc_tailp++ in xc_thread). So xc_lowpri accepts a next job before
all xcall callbacks complete and a next job begins to run its xcall callbacks.
Even worse the counter is global and shared between jobs, so if a xcall
callback of the next job completes, the shared counter is incremented,
which confuses wc_wait of the previous job as all xcall callbacks of the
previous job are done and wc_wait of the previous job returns during/before
executing its xcall callbacks.
How to fix: there are actually two counters that count the number of finished
xcall callbacks for low priority xcall for historical reasons (I guess):
xc_tailp and xc_low_pri.xc_donep. xc_low_pri.xc_donep is incremented correctly
while xc_tailp is incremented wrongly, i.e., before executing a xcall callback.
We can fix the issue by dropping xc_tailp and using only xc_low_pri.xc_donep.
PR kern/51632


To generate a diff of this commit:
cvs rdiff -u -r1.13.10.1 -r1.13.10.1.2.1 src/sys/kern/subr_xcall.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.