Re: crash in tty code in 6.1.. fixed since?

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 :)

Attilio

PS: I think I alredy documented these kinds of bugs in my locking 
documentation in perforce.