From owner-freebsd-current@FreeBSD.ORG Fri Jul 13 08:22:02 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F420A16A401; Fri, 13 Jul 2007 08:22:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id D14B213C441; Fri, 13 Jul 2007 08:22:00 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.lan) by mailfe01.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 525531068; Fri, 13 Jul 2007 10:21:59 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, attilio@freebsd.org Date: Fri, 13 Jul 2007 10:21:59 +0200 User-Agent: KMail/1.9.5 References: <46970DF7.3000803@elischer.org> <46972B28.1010409@FreeBSD.org> In-Reply-To: <46972B28.1010409@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707131021.59966.hselasky@c2i.net> Cc: Julian Elischer , FreeBSD Current Subject: Re: crash in tty code in 6.1.. fixed since? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2007 08:22:02 -0000 On Friday 13 July 2007 09:35, Attilio Rao wrote: > Julian Elischer wrote: > > Does this crash look familiar to anyone? > > It's in 6.1 unfortunatly.. > > > > #6 0xc069ca6a in calltrap () at ../../../i386/i386/exception.s:139 > > #7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704) > > at ../../../kern/tty.c:1659 > > #8 0xc058b83e in ptcclose (dev=0x0, flags=7, fmt=8192, td=0xc6966d80) > > at linedisc.h:136 > > #9 0xc052bf77 in giant_close (dev=0xc7547c00, fflag=7, devtype=8192, > > td=0xc6966d80) at ../../../kern/kern_conf.c:266 > > #10 0xc051685f in devfs_close (ap=0xe706baa4) > > at ../../../fs/devfs/devfs_vnops.c:287 > > #11 0xc06c2a10 in VOP_CLOSE_APV (vop=0x0, a=0xc076af48) at vnode_if.c:426 > > #12 0xc05bf3ce in vn_close (vp=0xc764e550, flags=7, file_cred=0x0, > > td=0xc6966d80) at vnode_if.h:227 > > #13 0xc05c0212 in vn_closefile (fp=0xc7532510, td=0xc6966d80) > > at ../../../kern/vfs_vnops.c:852 > > #14 0xc0516887 in devfs_close_f (fp=0xc7532510, td=0xc6966d80) > > at ../../../fs/devfs/devfs_vnops.c:297 > > #15 0xc05361e8 in fdrop_locked (fp=0xc7532510, td=0xc6966d80) at > > file.h:289 #16 0xc0536135 in fdrop (fp=0xc7532510, td=0xc6966d80) > > at ../../../kern/kern_descrip.c:2122 > > #17 0xc05346d3 in closef (fp=0xc7532510, td=0xc6966d80) > > at ../../../kern/kern_descrip.c:1942 > > #18 0xc0533487 in fdfree (td=0xc6966d80) at > > ../../../kern/kern_descrip.c:1627 > > #19 0xc053cc88 in exit1 (td=0xc6966d80, rv=15) at > > ../../../kern/kern_exit.c:263 > > #20 0xc055b58b in sigexit (td=0xc6966d80, sig=15) > > at ../../../kern/kern_sig.c:2451 > > #21 0xc055b296 in postsig (sig=15) at ../../../kern/kern_sig.c:2326 > > #22 0xc0577fbe in ast (framep=0xe706bd38) at > > ../../../kern/subr_trap.c:266 #23 0xc069d3ad in doreti_ast () at > > ../../../i386/i386/exception.s:293 > > > > (kgdb) up > > #7 0xc0587012 in ttymodem (tp=0xc6990800, flag=-1065963704) > > at ../../../kern/tty.c:1659 > > 1659 if (tp->t_session->s_leader) { > > Current language: auto; currently c > > (kgdb) list > > 1654 !ISSET(tp->t_cflag, CLOCAL)) { > > 1655 SET(tp->t_state, TS_ZOMBIE); > > 1656 CLR(tp->t_state, TS_CONNECTED); > > 1657 if (tp->t_session) { > > 1658 sx_slock(&proctree_lock); > > 1659 if (tp->t_session->s_leader) { > > 1660 struct proc *p; > > 1661 > > 1662 p = > > tp->t_session->s_leader; > > 1663 PROC_LOCK(p); > > > > (kgdb) set print pretty > > (kgdb) p *tp > > $3 = { > > t_rawq = { > > c_cc = 0, > > [...] > > > > t_outcc = 119661, t_line = 0, t_dev = 0xc763fe00, t_mdev = 0x0, > > t_devunit = 0, t_state = 0, t_flags = 0, t_timeout = 300000, t_pgrp > > = 0x0, t_session = 0x0, t_sigio = 0x0, t_rsel = { > > si_thrlist = { > > tqe_next = 0x0, tqe_prev = 0x0 > > }, si_thread = 0x0, si_note = { > > [...] > > > > > > tp_session is NULL but it shouldn't have been able to have run that line > > (line 1659) if it had tested NULL 2 lines before.. > > this suggests a locking problem.. > > I think it has been fixed some months ago IIRC. > The problem here, should be that if sx_slock() let thread sleep, Giant > is released before to sleep and tp->t_session can be accessed in racy way. > Another nice side-effect about having tty Giant :) > If TTY was not Giant locked, you would have had an error there if another mutex was locked, and the problem would have been solved years ago :-) Maybe related: Regarding the keyboard system which is also Giant locked, we should add assert Giant statements, because I see several callers doing calls into the keyboard system without holding Giant! --HPS