Re: tty-related panic on "init 0" - race?

On Wed, 1 Dec 2004, Gavin Atkinson wrote:
> Just got a tty-related panic when running "init 0" over a serial console
> on FreeBSD 6.0-CURRENT #2: Fri Nov 26 16:59:28 GMT 2004.  I was unable
> to obtain a dump, but have a debug kernel available.

Oops, i've had a busy week and forgot all about investigating this
further.  Looks like this might be a race to me.

> foo# init 0
> foo# Shutting down daemon processes:.
> Stopping cron.
> Shutting down local daemons:.
> Writing entropy file:.
> .
> Dec  1 16:39:47
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 00
> fault virtual address   = 0x4
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xc0639bd6

addr2line 0xc0639bd6 -e kernel.debug
/usr/src/sys/kern/tty.c:1653

File is src/sys/kern/tty.c,v 1.242 2004/11/16 17:41:16 dds
Function is ttymodem():

  1643                  /*
  1644                   * Lost carrier.
  1645                   */
  1646                  CLR(tp->t_state, TS_CARR_ON);
  1647                  if (ISSET(tp->t_state, TS_ISOPEN) &&
  1648                      !ISSET(tp->t_cflag, CLOCAL)) {
  1649                          SET(tp->t_state, TS_ZOMBIE);
  1650                          CLR(tp->t_state, TS_CONNECTED);
  1651                          if (tp->t_session) {
  1652                                  sx_slock(&proctree_lock);
  1653   -->                            if (tp->t_session->s_leader) {
  1654                                          struct proc *p;
  1655
  1656                                          p = tp->t_session->s_leader;
  1657                                          PROC_LOCK(p);
  1658                                          psignal(p, SIGHUP);
  1659                                          PROC_UNLOCK(p);

So, assuming that line is correct, it looks like tp->t_session became null
between testing it (on line 1651) and using it (1653). Disassembling the
kernel.debug confirms it is this - that t_session has to be null.

c0639bce:       e8 a1 90 fd ff          call   c0612c74 <_sx_slock>
c0639bd3:       8b 46 74                mov    0x74(%esi),%eax
c0639bd6**      8b 78 04                mov    0x4(%eax),%edi
c0639bd9:       83 c4 0c                add    $0xc,%esp
c0639bdc:       85 ff                   test   %edi,%edi
c0639bde:       75 1c                   jne    c0639bfc <ttymodem+0x114>

So are we looking at a race here?  Otherwise I cannot seem to see any way
this could have happened.

> [thread pid 3483 tid 100148 ]
> Stopped at      ttymodem+0xee:  movl    0x4(%eax),%edi
> db> tr
> Tracing pid 3483 tid 100148 td 0xc3b6fc00
> ttymodem(c35da000) at ttymodem+0xee
> ptcclose(c44c5200,7,2000,c3b6fc00,c3b6fc00) at ptcclose+0x1a
> devfs_close(ecd10bc0,c08b78e0,c930c564,7,c4029a80) at devfs_close+0x1ba
> vn_close(c930c564,7,c4029a80,c3b6fc00,85a) at vn_close+0x5d
> vn_closefile(c5137a5c,c3b6fc00,c44c6c00,0,ecd10cc0) at vn_closefile+0x44
> fdrop_locked(c5137a5c,c3b6fc00,c0870164,c3b6fc70,407) at fdrop_locked+0x79
> closef(c5137a5c,c3b6fc00,0,ecd10d40,7) at closef+0x1e
> close(c3b6fc00,ecd10d14,1,23,246) at close+0x149
> syscall(2f,2f,2f,80aa000,80aa000) at syscall+0x128
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (6, FreeBSD ELF32, close), eip = 0x2816766f, esp = 0xbfbfe06c, ebp = 0xbfbfe088 ---

Anything else I can do?

Gavin