Re: Possible NULL pointer deref in sched_add() via maybe_preempt() and kse_release()

I have a patch  in
http://www.freebsd.org/~julian/r.diff

that fixes one possible source of this problem.


Robert Watson wrote:

>Got this today on an SMP box running mysql:
>
>kernel trap 12 with interrupts disabled
> 
> Fatal trap 12: page fault while in kernel mode
>cpuid = 0; apic id = 00
>fault virtual address   = 0x150
>fault code              = supervisor read, page not present
>instruction pointer     = 0x8:0xc06224de
>stack pointer           = 0x10:0xef1b1b28
>frame pointer           = 0x10:0xef1b1b38
>code segment            = base 0x0, limit 0xfffff, type 0x1b
>                        = DPL 0, pres 1, def32 1, gran 1
>processor eflags        = resume, IOPL = 0
>current process         = 572 (mysqld)
>db> trace
>sched_add(0,3) at sched_add+0x16
>setrunqueue(c27867d0,3) at setrunqueue+0x15f
>sched_switch(c27867d0,c2a93af0,2) at sched_switch+0xf2
>mi_switch(2,c2a93af0,c2a93c44,c2a93af0,ef1b1bf4) at mi_switch+0x1b2
>maybe_preempt(c2a93af0) at maybe_preempt+0x93
>sched_add(c2a93af0,0) at sched_add+0x103
>setrunqueue(c2a93af0,0) at setrunqueue+0x15f
>turnstile_unpend(c2960c40,c2785c40,c27867d0,ef1b1c78,c062efdc) at
>turnstile_unpend+0x25f
>_mtx_unlock_sleep(c2785cac,0,0,0) at _mtx_unlock_sleep+0x6c
>sleepq_catch_signals(c26f0c80,0,0,100,c2930260) at
>sleepq_catch_signals+0x134
>msleep(c26f0c80,c2785cac,168,c081471e,7f) at msleep+0x239
>kse_release(c27867d0,ef1b1d14,1,8a,206) at kse_release+0x237
>syscall(a89002f,830002f,bfa9002f,8304000,0) at syscall+0x283
>Xint0x80_syscall() at Xint0x80_syscall+0x1f
>--- syscall (383, FreeBSD ELF32, kse_release), eip = 0x2833aa1b, esp =
>0x8308f88, ebp = 0x8308fc4 ---
>db> show pcpu
>cpuid        = 0
>curthread    = 0xc27867d0: pid 572 "mysqld"
>curpcb       = 0xef1b1da0
>fpcurthread  = none
>idlethread   = 0xc2260960: pid 14 "idle: cpu0"
>APIC ID      = 0
>currentldt   = 0x30
>
>The source code here is probably about a day old; the panic occurred
>during a kernel build using an NFS-mounted source tree and local object
>tree.  MySQL should have been basically idle, since no clients were active
>or had been active recently, but no doubt it wakes up once in a while to
>do something.
>
>Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
>robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research
>  
>