Date: Sat, 6 Nov 1999 16:47:32 -0500 (EST) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Cc: FreeBSD Current Users' list <freebsd-current@FreeBSD.org> Subject: Re: Serious locking problem in CURRENT Message-ID: <Pine.BSF.4.10.9911061644340.1075-100000@green.myip.org> In-Reply-To: <199911062057.XAA03228@tejblum.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 6 Nov 1999, Dmitrij Tejblum wrote: > Brian Fundakowski Feldman wrote: > > There were zero comments about what order things happen in; in fact, > > the ordering in this case is Just Plain Lame (TM). It's much more > > correct to explicitly check for fp->f_count == 1. > > Not sure what you mean. The commit clearly states that POSIX and BSD > locking intentionally handled in different ways here. Frankly, I see > nothing lame in the ordering. The second VOP_ADVLOCK just should be > moved to fdrop(). Yes, but you implied that there was some part of the commenting that I must have missed in rev.1.68, but there was nothing about that. I think I'll get an okay from bruce and move the unlock to fdrop(); I have still been pondering which is more correct, actually. > > > > BTW, I have another little concern with that commit: It make possible for > > > last close() of a file descriptor to return 0 instead of the error from > > > VOP_CLOSE(), and the error from VOP_CLOSE() to be ignored. > > When a process do closef() on a descriptor "held" by another process > (by fhold(), e.g. the process do read() on the descriptor), it will > just return 0 without the call to fo_close(). Then, when the other > process drop the descriptor, fdrop() call fo_close() but the error is > thrown away. No? Yes, this is what I thought you could have meant. But would you rather lose that error in a corner case or do locking on the fd/fdtable or just let the system crash in that case? I'm open for a better solution. > > Dima > > > -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / green@FreeBSD.org `------------------------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911061644340.1075-100000>