Date: Sun, 19 Oct 2003 15:57:01 -0500 From: "Alan L. Cox" <alc@imimic.com> To: David Malone <dwmalone@FreeBSD.org> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/streams streams.csrc/sys/kernkern_descrip.c src/sys/opencrypto cryptodev.c Message-ID: <3F92FA9D.F25F3CFB@imimic.com> References: <200310192041.h9JKf712075632@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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? Additionally, we declare dup2(2) to be MPSAFE, but not dup(2). Given their implementations that seems odd. Regards, Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F92FA9D.F25F3CFB>