Date: Sun, 19 Oct 2003 17:08:09 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: David Malone <dwmalone@maths.tcd.ie> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: cvs commit: src/sys/dev/streams streams.c src/sys/kern kern_descrip.c kern_event.c sys_pipe.c uipc_syscalls.c vfs_syscalls.c src/sys/opencrypto cryptodev.c Message-ID: <Pine.NEB.3.96L.1031019165954.4181F-100000@fledge.watson.org> In-Reply-To: <200310192154.aa57999@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 19 Oct 2003, David Malone wrote: > > Does this fix the filedesc LORs that have been seen for the past few months? > > Nope, 'fraid not. I was trying to make sure that we wouldn't need Giant > in syscalls that allocate file descriptors. Can you point me at a > backtrace? I can take a look, but I'm not sure I'll be able to fix them. There's fairly extensive discussion of the problem in the -current mailing list archives. My recollection is a little vague right now, but I seem to recall that there are instances of Giant being grabbed both before and after the file descriptor lock, as well as calls to fo_poll() and SYSCTL_OUT() while holding the file descriptor lock. It seemed like there was an effort to push the file descriptor lock grab before Giant, and that this was substantially complicated by some of the "deep" use of file descriptor locks in the socket and file system code. For example, some of the file descriptor handling during execve(), in kqueue_register(), unp_externalize(), the /dev/fd code, et al. We need to either pick to have the file descriptor locks in the lock order before Giant, or after Giant, and right now we're in limbo, so Witness generates lock order warnings... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1031019165954.4181F-100000>