From owner-cvs-all@FreeBSD.ORG Sat Sep 30 15:05:13 2006 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C158616A403; Sat, 30 Sep 2006 15:05:13 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 310DA43D46; Sat, 30 Sep 2006 15:05:13 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 0448D24D248; Sun, 1 Oct 2006 01:05:12 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k8UF59tL021522; Sun, 1 Oct 2006 01:05:10 +1000 Date: Sun, 1 Oct 2006 01:00:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Martin Blapp In-Reply-To: <20060929230809.Q91466@godot.imp.ch> Message-ID: <20061001001335.R1840@epsplex.bde.org> References: <200609290952.k8T9qvcU053566@repoman.freebsd.org> <20060929202338.W91466@godot.imp.ch> <20060930044711.H96144@delplex.bde.org> <20060929230809.Q91466@godot.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, Martin Blapp , src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/kern tty_pty.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2006 15:05:13 -0000 On Fri, 29 Sep 2006, Martin Blapp wrote: >> I think I found the bug while looking for problems near vgonel(). We're >> nowhere near ready to free devices in in last-close, since vgonel() doesn't >> do anything to evict processes from device functions before it forces the >> device closed. Drivers must be aware of the problem. The tty driver >> already is. See the comments about t_gen near tty_close() and ttysleep(). >> t_gen must live across close so that any processes in device functions can >> check it after they wake up, and the tty and device data structures must >> live across last- close to hold t_gen and anything else needed for the >> device functions to return. Sleeping device functions normally wake up >> after last-close returns. > > So what can we do to destroy devices after last close ? Mark them with some > flag and handle this during device operations ? Destroy them after a timeout. More accurate counts of device use would still be needed to ensure that the device is not in use when the timeout fires, but it would be fairly safe to just assume that the device is not in use if it has been closed for some time. Note that the device may still be in use when close completes even for normal closes. This can happen when the close blocks. When close completes, it can't destroy things since it doesn't really know what is in use. However, if the device is still in use, if it is open then it won't be destroyed later (a new open would have reset the timeout), and if it is not open then any activity on the device should complete soon after the close completes since one of close's functions (especially for revoke()) is unblock other activity on the device by flushing any i/o that it gave up on. Bruce