From owner-freebsd-stable@FreeBSD.ORG Mon Jun 26 14:33:47 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 8AF7E16A405 for ; Mon, 26 Jun 2006 14:33:47 +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 1A0F443FD5 for ; Mon, 26 Jun 2006 14:33:42 +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 k5QEXE81093333; Mon, 26 Jun 2006 16:33:17 +0200 (CEST) (envelope-from mb@imp.ch) Date: Mon, 26 Jun 2006 16:33:14 +0200 (CEST) From: Martin Blapp To: Gavin Atkinson In-Reply-To: <1151328755.80434.17.camel@buffy.york.ac.uk> Message-ID: <20060626154810.S14714@godot.imp.ch> References: <20060621202508.S17514@godot.imp.ch> <20060623133915.S14714@godot.imp.ch> <1151078632.62769.30.camel@buffy.york.ac.uk> <200606231928.58063.max@love2party.net> <20060626115110.O14714@godot.imp.ch> <20060626133540.G14714@godot.imp.ch> <20060626151138.C14714@godot.imp.ch> <1151328755.80434.17.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: freebsd-stable@freebsd.org, "Wojciech A. Koszek" , csjp@freebsd.org, Robert Watson , phk@freebsd.org, tmm@freebsd.org, Max Laier , Patrick Guelat 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: Mon, 26 Jun 2006 14:33:47 -0000 Hi, > Is the problem actually understood? Do we know what's racing with what? > Given there only ever seems to be a single backtrace involved, as far as > I can tell, it's ttymodem racing with tty_close - can those two > functions alone be locked? Correct: The only place there tp->t_session is set to NULL is in tty_close(). tp->t_pgrp = NULL; tp->t_session = NULL; tp->t_state = 0; But I've seen this comment on peters page (http://people.freebsd.org/~peter/smp.html) > At the moment I've hacked all the console code to obtain the scheduler mutex > instead of spltty()'ing all over the place, because in a word: it can't > spltty() any more. It's illegal because the console code may be called at any time (see > the next section). This is a hack because it isn't MP safe against tty > interrupts running on another cpu. Since the current tty interrupt is a fast > interrupt, I'm not sure that we're any worse off (fastints aren't masked by the > cpl anyway). IMHO it explains why we need the proctree_lock (in early SMP times scheduler mutex). Maybe this should be replaced with a proper tty subsystem mutex ...) After looking at our SMPnewgen Page, Poul Henning and Thomas Moestel are working on locking the tty subsystem. I'll CC those :-) Martin