On 27 Aug 2015, at 07:51, Michael van Elst <mlel...@netbsd.org> wrote:
> Module Name: src
> Committed By: mlelstv
> Date: Thu Aug 27 05:51:50 UTC 2015
>
> Modified Files:
> src/sys/arch/xen/xen: xbd_xenbus.c
> src/sys/dev: cgd.c dksubr.c dkvar.h ld.c
>
> Log Message:
> Make dksubr use a spin-mutex again, since some drivers still call dk_done
> from hardware interrupt. Instead, release mutex while calling start routine.
>
> The buffer peek/use/get sequence which can no longer be atomic. So consume
> the buffer directly and on error privately save and retry the buffer later.
> The dk_drain function is used to flush such a deferred buffer together with
> the buffer queue.
> Adjust drivers to use dk_drain.
>
> Fix an error path where dk_done was called while the lock was already held.
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.72 -r1.73 src/sys/arch/xen/xen/xbd_xenbus.c
> cvs rdiff -u -r1.103 -r1.104 src/sys/dev/cgd.c
> cvs rdiff -u -r1.73 -r1.74 src/sys/dev/dksubr.c
disk_busy(&dksc->sc_dkdev);
+ mutex_exit(&dksc->sc_iolock);
error = dkd->d_diskstart(dksc->sc_dev, bp);
+ mutex_enter(&dksc->sc_iolock);
if (error == EAGAIN) {
+ dksc->sc_deferred = bp;
disk_unbusy(&dksc->sc_dkdev, 0, (bp->b_flags & B_READ));
break;
}
Looks racy: what if two threads run dk_strategy() -> dk_start() and
both get EAGAIN. Will it leak a buffer when the second thread tries
to save bp and dksc->sc_deferred already holds the buffer from the
first thread?
> cvs rdiff -u -r1.21 -r1.22 src/sys/dev/dkvar.h
> cvs rdiff -u -r1.91 -r1.92 src/sys/dev/ld.c
>
> Please note that diffs are not public domain; they are subject to the
> copyright notices on the relevant files.
>
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
