From owner-freebsd-stable@FreeBSD.ORG Fri Jun 23 16:11:26 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2951816A49E; Fri, 23 Jun 2006 16:11:26 +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 ACD1B43D68; Fri, 23 Jun 2006 16:11:20 +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.7/8.13.7/Submit) with ESMTP id k5NGBFIu011491; Fri, 23 Jun 2006 18:11:18 +0200 (CEST) (envelope-from mb@imp.ch) Date: Fri, 23 Jun 2006 18:11:15 +0200 (CEST) From: Martin Blapp To: Gavin Atkinson In-Reply-To: <1151078632.62769.30.camel@buffy.york.ac.uk> Message-ID: <20060623181014.S14714@godot.imp.ch> References: <20060621202508.S17514@godot.imp.ch> <20060621193941.Y8526@fledge.watson.org> <20060622205806.GA6542@FreeBSD.czest.pl> <20060622223630.V17514@godot.imp.ch> <1151056731.62769.2.camel@buffy.york.ac.uk> <20060623133915.S14714@godot.imp.ch> <1151078632.62769.30.camel@buffy.york.ac.uk> 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: Robert Watson , Patrick Guelat , "Wojciech A. Koszek" , freebsd-stable@freebsd.org Subject: Re: Crash with FreeBSD 6.1 STABLE of today X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2006 16:11:26 -0000 Hi, > I'm not sure if t_session is supposed to be protected by the proctree Correct. > lock though. With an initial glance of the code, it would seem odd to > be protected by the proctree lock, although I can't see any other locks > Someone with more knowledge of this code will probably know the answer > to this. > > There does seem to be a worrying comment above tty_close (which is the > only place that t_session seems to be set to NULL): > > * XXX our caller should have done `spltty(); l_close(); tty_close();' > * and l_close() should have flushed, but we repeat the spltty() and > * the flush in case there are buggy callers. > > As I understand it, spltty() is now a no-op. Does this mean that this > code is now essentially running without any locks that were used to > serialise changes to struct tty in days gone by? Or is the whole tty > subsystem still running under Giant? I thought this too. Maybe Robert knows more. Martin