[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
PR/51632 CVS commit: src/sys/kern
The following reply was made to PR kern/51632; it has been noted by GNATS.
From: "Ryota Ozaki" <ozaki-r%netbsd.org@localhost>
Subject: PR/51632 CVS commit: src/sys/kern
Date: Mon, 21 Nov 2016 00:54:21 +0000
Module Name: src
Committed By: ozaki-r
Date: Mon Nov 21 00:54:21 UTC 2016
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.
To generate a diff of this commit:
cvs rdiff -u -r1.18 -r1.19 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.
Main Index |
Thread Index |