Date: Mon, 20 Oct 2003 11:47:08 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: David Malone <dwmalone@maths.tcd.ie> Cc: cvs-src@freebsd.org Subject: Re: cvs commit: src/sys/dev/streams streams.c src/sys/kernkern_descrip.c kern_event.c sys_pipe.c uipc_syscalls.cvfs_syscalls.c src/sys/opencrypto cryptodev.c Message-ID: <Pine.NEB.3.96L.1031020114414.4181N-100000@fledge.watson.org> In-Reply-To: <200310200848.aa99929@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Oct 2003, David Malone wrote: > > > This reminds me that we still hold Giant around pipe(2) because it isn't > > > declared MPSAFE in the syscall table. Is this still necessary? > > > I've been suspicious of this too, and I was hoping that you would have > > an answer. Can we go ahead and correct this? > > I think we may need to check the calling of pipeclose() in pipe(), but > as this is only done in an error case, it is probably safe enough to > just grab Giant for that. (The mac_* calls may need to be checked too). The MAC Framework itself doesn't require Giant, but sometimes data used by the Framework is protected by locks outside the Framework, which sometimes requires Giant. In the case of the Pipe code, MAC labels in pipes are protected by the pipe mutex, so the MAC Framework asserts the pipe mutex. It should be fine to drop Giant in the pipe code for the purposes of the MAC Framework. Currently, the MAC Framework depends on Giant in as much as VFS depends on Giant for vnode locking correctness. In addition, it depends on Giant for socket labels due to the lack of socket locking. In our development tree, we have some locking improvements for System V IPC and Posix IPC code that I believe prevents us from needing Giant for those entry points, but those changes are not yet in the base FreeBSD tree. 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.1031020114414.4181N-100000>