Skip site navigation (1)Skip section navigation (2)
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>