From owner-cvs-src@FreeBSD.ORG  Fri Sep 29 21:09:55 2006
Return-Path: <owner-cvs-src@FreeBSD.ORG>
X-Original-To: cvs-src@FreeBSD.org
Delivered-To: cvs-src@FreeBSD.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 9C12F16A407;
	Fri, 29 Sep 2006 21:09:55 +0000 (UTC) (envelope-from mb@imp.ch)
Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 6EC3843D6B;
	Fri, 29 Sep 2006 21:09:29 +0000 (GMT) (envelope-from mb@imp.ch)
Received: from godot.imp.ch (godot.imp.ch [157.161.4.8])
	by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id k8TL9M9U032814; 
	Fri, 29 Sep 2006 23:09:25 +0200 (CEST) (envelope-from mb@imp.ch)
Date: Fri, 29 Sep 2006 23:09:22 +0200 (CEST)
From: Martin Blapp <mb@imp.ch>
To: Bruce Evans <bde@zeta.org.au>
In-Reply-To: <20060930044711.H96144@delplex.bde.org>
Message-ID: <20060929230809.Q91466@godot.imp.ch>
References: <200609290952.k8T9qvcU053566@repoman.freebsd.org>
	<20060929202338.W91466@godot.imp.ch>
	<20060930044711.H96144@delplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Scanned-By: MIMEDefang 2.57 on 157.161.9.65
Cc: cvs-src@FreeBSD.org, Martin Blapp <mbr@FreeBSD.org>, cvs-all@FreeBSD.org,
	src-committers@FreeBSD.org
Subject: Re: cvs commit: src/sys/kern tty_pty.c
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Sep 2006 21:09:55 -0000


Hi,

> 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 ?

Martin