Date: Tue, 26 Oct 2004 11:53:12 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-arch@FreeBSD.org Cc: Poul-Henning Kamp <phk@phk.freebsd.dk> Subject: Re: REVIEW: handling kldload/kldunload of GEOM classes properly. Message-ID: <200410261153.12982.jhb@FreeBSD.org> In-Reply-To: <59920.1098481368@critter.freebsd.dk> References: <59920.1098481368@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 22 October 2004 05:42 pm, Poul-Henning Kamp wrote: > There are a number of system calls which starts events running in > GEOM and which for consistency should not return to userland until > those events have completed and GEOM has settled down. > > The typical example would be a shell-script doing: > > kldload md > mdconfig bla bla > > > Examples of such syscalls are: > > open(2) & close(2): can cause spoils and retastes > > mount(2)/umount(2): acts as open/close. > > (any other syscall doing a VOP_OPEN/VOP_CLOSE on a diskdevice.) > > ioctl(2): directed configuration can do almost anything. > > kldload(2)/kldunload(2): can load/unload GEOm classes. > > The last one is the most tricky one: The crude solution is to always > wait for geom to settle before returning to userland from kldload(2), > but there is no point in waiting for GEOM if you loaded a USB > serial driver and doing so would increase the risk of cascade > failures. > > A further complication is that we should not wait for geom to settle > until after we have dropped Giant again because the geom events > might need to grab giant to do their job. Just a note on this: If you sleep in your waiting function (i.e. call msleep() or cv_wait()), then Giant will be dropped automatically so that you don't need to worry about events needing Giant. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200410261153.12982.jhb>