Bug 130261 - [kernel] [panic] kernel panic in/below sys_pipe.c:knlist_cleardel
Summary: [kernel] [panic] kernel panic in/below sys_pipe.c:knlist_cleardel
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 6.4-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords: crash
Depends on:
Blocks:
 
Reported: 2009-01-07 11:30 UTC by Yvan Seth
Modified: 2022-10-17 12:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yvan Seth 2009-01-07 11:30:01 UTC
FreeBSD 6.4-RELEASE-p1 panics regularly below sys_pipe.c:knlist_cleardel.

System details:
# uname -a
FreeBSD dante.cam.zeus.com 6.4-RELEASE-p1 FreeBSD 6.4-RELEASE-p1 #5: Mon Jan  5 23:37:03 GMT 2009     root@dante.cam.zeus.com:/usr/obj/usr/src/sys/DEBUG  i386
# dmesg | grep -i cpu
CPU: Intel Celeron (697.74-MHz 686-class CPU)
cpu0: <ACPI CPU> on acpi0
# dmesg | grep -i memory
real memory  = 267124736 (254 MB)
avail memory = 247779328 (236 MB)

This occurs with both downloaded binary kernels, as well as a self-compiled debug kernel.  The kernel source used is vanilla FreeBSD.  (We originally hit this on an old 6.1 machine, and have upgraded through 6.1-p24, 6.2-RELEASE, and finally 6.4-p1 - the issue is present in all versions in this list - I haven't got the time/resources to test with 7.1 at the moment.)  My compiled DEBUG kernel config is GENERIC with these added lines:
   options DDB
   options KDB
   options GDB
   options KDB_TRACE

The problem has occurred on two different systems, the (rather old) Celeron one detailed above and another AMD Opteron 250 (2.4GHz) with 2GB RAM.  Both have been through, and passed, a full memcheck.

The panic closely resembles an issue, "knlsit_cleardel() panic", discussed here:
 http://lists.freebsd.org/pipermail/freebsd-current/2008-March/thread.html#83991
This email thread seems to come to a sudden close after the OP suggests a fix.

The panic always happens under sys_pipe.c:knlist_cleardel and, so far (about 15 noted panics), has always occurred below a perl process.  However, there's a lot of perl code running on the system so this latter point is probably a red herring.

I have crash dumps and am willing to delve into them as much as requested.  I have wandered around one of the crash dumps in kgdb, and include below as much data as seems immediately relevant.  However I'm no kernel hacker, most certainly when it comes to FreeBSD - I can just hope some of this is useful.

For starters here is a typical crash dump, loaded into kgdb:

------------------------------
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x1c
fault code              = supervisor write, page not present
instruction pointer     = 0x20:0xc069c946
stack pointer           = 0x28:0xd1898bc8
frame pointer           = 0x28:0xd1898bd8
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 2537 (perl)
panic: from debugger
KDB: stack backtrace:
Uptime: 20h44m58s
Dumping 254 MB (2 chunks)
  chunk 0: 1MB (159 pages) ... ok
  chunk 1: 254MB (64960 pages) 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14

Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/linux.ko...done.
Loaded symbols for /boot/kernel/linux.ko
#0  doadump () at pcpu.h:165
165   pcpu.h: No such file or directory.
   in pcpu.h
(kgdb) bt
   <SNIP content=trap/doadump calls/>
#12 0xc069c946 in knlist_cleardel (knl=0xc2dcd208, td=0x0, islocked=1, killkn=0) at atomic.h:149
#13 0xc06e2597 in pipeclose (cpipe=0xc2dcd198) at /usr/src/sys/kern/sys_pipe.c:1526
#14 0xc06e2216 in pipe_close (fp=0x4, td=0xc343e180) at /usr/src/sys/kern/sys_pipe.c:1443
#15 0xc06980d8 in fdrop_locked (fp=0xc32e1ca8, td=0xc343e180) at file.h:296
#16 0xc0698001 in fdrop (fp=0xc32e1ca8, td=0xc343e180) at /usr/src/sys/kern/kern_descrip.c:2173
#17 0xc069662f in closef (fp=0xc32e1ca8, td=0xc343e180) at /usr/src/sys/kern/kern_descrip.c:1993
#18 0xc06939c3 in kern_close (td=0xc343e180, fd=5) at /usr/src/sys/kern/kern_descrip.c:1083
#19 0xc06937b4 in close (td=0xc343e180, uap=0x4) at /usr/src/sys/kern/kern_descrip.c:1035
#20 0xc0937903 in syscall (frame=
      {tf_fs = 59, tf_es = 138281019, tf_ds = -1078001605, tf_edi = 0, tf_esi = 673782480, tf_ebp = -1077943144, tf_isp = -779514524, tf_ebx = 673694016, tf_edx = 0, tf_ecx = 0, tf_eax = 6, tf_trapno = 0, tf_err = 2, tf_eip = 673632627, tf_cs = 51, tf_eflags = 530, tf_esp = -1077943172, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984
#21 0xc09238df in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#22 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
---------------------------------------------------

The PC is at:

---------------------------------------------------
0xc069c946 <knlist_cleardel+66>: cmpxchg %edx,0x1c(%ebx)
---------------------------------------------------

Which is beneath a macro in knlist_cleardel:

---------------------------------------------------
kern/kern_event.c:1721:      KQ_LOCK(kq);
---------------------------------------------------

The value in question is (*):

---------------------------------------------------
(kgdb) print kq
$16 = (struct kqueue *) 0x0
(kgdb) print &(kq)->kq_lock
$17 = (struct mtx *) 0x0
(kgdb) print &(&(kq)->kq_lock)->mtx_lock  <--;---<<<< *
$18 = (volatile uintptr_t *) 0x1c  <--------'
---------------------------------------------------

Which comes from drilling down to the relevant macro under KQ_LOCK of:

---------------------------------------------------
i386/include/atomic.h:atomic_cmpset_int(volatile u_int *dst, ...)
---------------------------------------------------

Where the dst value passed in, 0x1c, is accessed by code equivalent to the PC:

---------------------------------------------------
   __asm __volatile (
   "  " __XSTRING(MPLOCKED) " "

How-To-Repeat: When our software test system is running this occurs regularly, sometimes a couple of times per day.  At best the machines last 48 hours between panics.

When no tests are running the machines seem to be fine.

The software test system uses a lot of perl code.  A lot of perl executing external programs (open X, "|foo") - possibly a lot of pipe(close) usage then I presume.

Unfortunately I have not been able to isolate the issue to a simple test case.  I'm working on finding a simple way to replicate, but haven't made much progress on this.
Comment 1 Yvan Seth 2009-01-07 12:37:51 UTC
I should clarify: "We originally hit this on an old 6.1 machine, and
have upgraded through 6.1-p24, 6.2-RELEASE, and finally 6.4-p1"

We:
* did a 6.1-RELEASE install and it panicked as described.
* upgraded it to 6.1-RELEASE-p24 and the panic persisted.
* did a fresh 6.2-RELEASE install, panic again.
* upgraded this to 6.2-RELEASE-p9 (customer version), panic.
* did a fresh 6.4-RELEASE install, panic.
* upgraded this fresh install to 6.4-RELEASE-p1, panic.

The important point being that we didn't upgrade between versions, 6.4
was a fresh install.

Thanks,
Yvan
Comment 2 Yvan Seth 2009-01-07 15:12:37 UTC
In trying to replicate this more simply (still using our complex test
scripts unfortunately) I'm seeing some slightly different panics.

I've seen the following one just a couple of times before, but figure it
must be related as it is also under knlist_cleardel.  To my untrained
eye things look to be in an even worse state in this case, should
knl->kl_list.slh_first->kn_kq.kq_lock.mtx_lock ever have a value of
0x06?  On all occurrences of this form of the panic this has value 0x06,
seemingly not random clobbering.

The 'kq' is in state 0x10 - KQ_CLOSING
The 'kn' has status 0x11 - KN_ACTIVE | KN_INFLUX

Notably: 0x78 = 0x04+0x74 - i.e. "mov 0x74(%ecx),%eax"

And: 0x04 = 0x06 & MTX_FLAGMASK (see #define mtx_owner)

Perhaps: mtx_lock = MTX_UNOWNED | MTX_CONTESTED = MTX_DESTROYED


More details:
-----------------------------------------------------------------------
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x78
fault code             = supervisor read, page not present
instruction pointer    = 0x20:0xc06dc281
stack pointer          = 0x28:0xd184cb64
frame pointer          = 0x28:0xd184cb68
code segment           = base rx0, limit 0xfffff, type 0x1b
                       = DPL 0, pres 1, def32 1, gran 1
processor eflags       = resume, IOPL = 0
current process        = 24539 (perl)
panic: from debugger
KDB: stack backtrace:
Uptime: 2h42m13s
<SNIP/>
#10 0xc092388a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#11 0xc06dc281 in turnstile_setowner (ts=0xc25124c0, owner=0x4) at /usr/src/sys/kern/subr_turnstile.c:456
#12 0xc06dc5de in turnstile_wait (lock=0xc2ec6600, owner=0x4, queue=0) at /usr/src/sys/kern/subr_turnstile.c:661
#13 0xc06b1a5e in _mtx_lock_sleep (m=0xc2ec6600, tid=3272086656, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:579
#14 0xc069c961 in knlist_cleardel (knl=0xc27bdb98, td=0x0, islocked=1, killkn=0) at /usr/src/sys/kern/kern_event.c:1730
#15 0xc06e2597 in pipeclose (cpipe=0xc27bdb28) at /usr/src/sys/kern/sys_pipe.c:1526
#16 0xc06e2216 in pipe_close (fp=0xc30814a0, td=0xc3081480) at /usr/src/sys/kern/sys_pipe.c:1443
#17 0xc06980d8 in fdrop_locked (fp=0xc2fa83a8, td=0xc3081480) at file.h:296
#18 0xc0698001 in fdrop (fp=0xc2fa83a8, td=0xc3081480) at /usr/src/sys/kern/kern_descrip.c:2173
#19 0xc069662f in closef (fp=0xc2fa83a8, td=0xc3081480) at /usr/src/sys/kern/kern_descrip.c:1993
#20 0xc06939c3 in kern_close (td=0xc3081480, fd=5) at /usr/src/sys/kern/kern_descrip.c:1083
#21 0xc06937b4 in close (td=0xc3081480, uap=0xc30814a0) at /usr/src/sys/kern/kern_descrip.c:1035
#22 0xc0937903 in syscall (frame=
      {tf_fs = 59, tf_es = 140116027, tf_ds = -1078001605, tf_edi = 0, tf_esi = 673782480, tf_ebp = -1077942568, tf_isp = -779825820, tf_ebx = 673694016, tf_edx = 0, tf_ecx = 0, tf_eax = 6, tf_trapno = 12, tf_err = 2, tf_eip = 673632627, tf_cs = 51, tf_eflags = 530, tf_esp = -1077942596, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:984
#23 0xc09238df in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#24 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
<SNIP/>
(kgdb) p/x *knl
st = {
    slh_first = 0xc2859770
  }, 
  kl_lock = 0xc069c7ec, 
  kl_unlock = 0xc069c820, 
  kl_locked = 0xc069c85c, 
  kl_lockarg = 0xc27bdc98
}
(kgdb) p/x *knl->kl_list.slh_first
$3 = {
  kn_link = {
    sle_next = 0x0
  }, 
  kn_selnext = {
    sle_next = 0x0
  }, 
  kn_knlist = 0xc27bdb98, 
  kn_tqe = {
    tqe_next = 0x0, 
    tqe_prev = 0xc285a848
  }, 
  kn_kq = 0xc2ec6600, 
  kn_kevent = {
    ident = 0x1, 
    filter = 0xfffe, 
    flags = 0x0, 
    fflags = 0x0, 
    data = 0x4000, 
    udata = 0x0
  }, 
  kn_status = 0x11, 
  kn_sfflags = 0x0, 
  kn_sdata = 0x0, 
  kn_ptr = {
    p_fp = 0x0, 
    p_proc = 0x0
  }, 
  kn_fop = 0x0, 
  kn_hook = 0x0
}
(kgdb) p/x *knl->kl_list.slh_first->kn_kq
$4 = {
  kq_lock = {
    mtx_object = {
      lo_class = 0xc0a32c84, 
      lo_name = 0xc09b8585, 
      lo_type = 0xc09b8585, 
      lo_flags = 0x420000, 
      lo_list = {
        tqe_next = 0x0, 
        tqe_prev = 0x0
      }, 
      lo_witness = 0x0
    }, 
    mtx_lock = 0x6,   <<<<======================= ???????
    mtx_recurse = 0x0
  }, 
  kq_refcnt = 0x1, 
  kq_list = {
    sle_next = 0x0
  }, 
  kq_head = {
    tqh_first = 0x0, 
    tqh_last = 0xc2ec662c
  }, 
  kq_count = 0x0, 
  kq_sel = {
    si_thrlist = {
      tqe_next = 0x0, 
      tqe_prev = 0x0
    }, 
    si_thread = 0x0, 
    si_note = {
      kl_list = {
        slh_first = 0x0
      }, 
      kl_lock = 0x0, 
      kl_unlock = 0x0, 
      kl_locked = 0xc069c85c, 
      kl_lockarg = 0x0
    }, 
    si_flags = 0x0
  }, 
  kq_sigio = 0x0, 
  kq_fdp = 0x0, 
  kq_state = 0x10, 
  kq_knlistsize = 0x100, 
  kq_knlist = 0xc268e800, 
  kq_knhashmask = 0x0, 
  kq_knhash = 0x0, 
  kq_task = {
    ta_link = {
      stqe_next = 0x0
    }, 
    ta_pending = 0x0, 
    ta_priority = 0x0, 
    ta_func = 0xc069b788, 
    ta_context = 0xc2ec6600
  }
}
-----------------------------------------------------------------------

Regards,
-Yvan
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:33 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 4 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:17:19 UTC
Keyword: 

    crash

– in lieu of summary line prefix: 

    [panic]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>