Module Name: src
Committed By: riastradh
Date: Mon Aug 22 00:19:13 UTC 2022
Modified Files:
src/sys/dev/dkwedge: dk.c
Log Message:
dk(4): Serialize closing parent's dk_rawvp with opening it.
Otherwise, the following events might happen:
- process 123 had /dev/rdkN open, starts close, enters dk_close_parent
- process 456 opens /dev/rdkM (same parent, different wedge), calls
dk_open_parent
At this point, the block device hasn't yet closed, so dk_open_parent
will fail with EBUSY. This is incorrect -- the chardev is never
supposed to fail with EBUSY, and dkopen/dkclose carefully manage
state to avoid opening the block device while it's still open. The
problem is that dkopen in process 456 didn't wait for vn_close
in process 123 to finish before calling VOP_OPEN.
(Note: If it were the _same_ chardev /dev/rdkN in both processes,
then spec_open/close would prevent this. But since it's a
_different_ chardev, spec_open/close assume that concurrency is OK,
and it's the driver's responsibility to serialize access to the
parent disk which, unbeknownst to spec_open/close, is shared between
dkN and dkM.)
It appears that the vn_close call was previously moved outside
dk_rawlock in 2010 to work around an unrelated bug in raidframe that
had already been fixed in HEAD:
Crash pointing to dk_rawlock and raidclose:
https://mail-index.netbsd.org/tech-kern/2010/07/27/msg008612.html
Change working around that crash:
https://mail-index.netbsd.org/source-changes/2010/08/04/msg012270.html
Change removing raidclose -> mutex_destroy(&dk_rawlock) path:
https://mail-index.netbsd.org/source-changes/2009/07/23/msg223381.html
To generate a diff of this commit:
cvs rdiff -u -r1.112 -r1.113 src/sys/dev/dkwedge/dk.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
