From owner-freebsd-current Sun Nov 7 9:34:35 1999 Delivered-To: freebsd-current@freebsd.org Received: from green.myip.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 37AF514C1C for ; Sun, 7 Nov 1999 09:34:26 -0800 (PST) (envelope-from green@FreeBSD.org) Received: from localhost ([127.0.0.1] ident=green) by green.myip.org with esmtp (Exim 3.02 #1) id 11kDgK-0000HT-00; Sat, 06 Nov 1999 16:47:32 -0500 Date: Sat, 6 Nov 1999 16:47:32 -0500 (EST) From: Brian Fundakowski Feldman X-Sender: green@green.myip.org To: Dmitrij Tejblum Cc: FreeBSD Current Users' list Subject: Re: Serious locking problem in CURRENT In-Reply-To: <199911062057.XAA03228@tejblum.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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