Date: Sun, 19 Oct 2003 19:41:11 -0600 From: Scott Long <scottl@freebsd.org> To: "Alan L. Cox" <alc@imimic.com> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/streams streams.csrc/sys/kernkern_descrip.csrc/sys/opencrypto cryptodev.c Message-ID: <3F933D37.40906@freebsd.org> In-Reply-To: <3F92FA9D.F25F3CFB@imimic.com> References: <200310192041.h9JKf712075632@repoman.freebsd.org> <3F92FA9D.F25F3CFB@imimic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan L. Cox wrote: > David Malone wrote: > >>dwmalone 2003/10/19 13:41:07 PDT >> >> FreeBSD src repository >> >> Modified files: >> sys/dev/streams streams.c >> sys/kern kern_descrip.c kern_event.c sys_pipe.c >> uipc_syscalls.c vfs_syscalls.c >> sys/opencrypto cryptodev.c >> Log: >> falloc allocates a file structure and adds it to the file descriptor >> table, acquiring the necessary locks as it works. It usually returns >> two references to the new descriptor: one in the descriptor table >> and one via a pointer argument. >> >> As falloc releases the FILEDESC lock before returning, there is a >> potential for a process to close the reference in the file descriptor >> table before falloc's caller gets to use the file. I don't think this >> can happen in practice at the moment, because Giant indirectly protects >> closes. >> >> To stop the file being completly closed in this situation, this change >> makes falloc set the refcount to two when both references are returned. >> This makes life easier for several of falloc's callers, because the >> first thing they previously did was grab an extra reference on the >> file. >> > > > 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? > > Additionally, we declare dup2(2) to be MPSAFE, but not dup(2). Given > their implementations that seems odd. We likely need to do a review through the syscalls and weed out problems like this. Any volunteers? Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F933D37.40906>