Re: kernel panic on smb activity

Alex Dupre wrote:
> Kris Kennaway wrote:
> 
> >What backtrace, or which source code line is it faulting at (use
> >addr2line)?
> >
> >P.S. Please try to be proactive with this kind of information
> 
> Just recompiled my kernel with debug symbols and DDB, these are the 
> relevant info:
> 
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0xc
> fault code              = supervisor write, page not present
> instruction pointer     = 0x8:0xc05b4805
> stack pointer           = 0x10:0xd3655a40
> frame pointer           = 0x10:0xd3655a8c
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 672 (cp)
> kernel: type 12 trap, code=0
> Stopped at      m_getm+0xa5:    movl    $0,0xc(%ecx)
> db> trace
> m_getm(c180fe00,508,2,1,c180fe6f) at m_getm+0xa5
> mb_put_mem(c1bba718,28163090,508,1,1) at mb_put_mem+0xb9
> mb_put_uio(c1bba718,d3655c80,598,0,4000) at mb_put_mem+0xb9
> smb_write(c1bba800,4000,d3655c80,d3655b80,c05cce88) at smb_write+0x414
> smbfs_writevnode(c1c15208,d3655c80,c1bf7b80,20001,0) at 
> smbfs_writevnode+0x1a1
> smbfs_write(d3655be4,20002,c1840dc0,c1626588,1) at smbfs_write+0x41
> vn_write(c1845bb0,d3655c80,c1bf7b80,0,c1840dc0) at vn_write+0x1bb
> dofilewrite(c1840dc0,c1845bb0,4,28163000,598) at dofilewrite+0xec
> write(c1840dc0,d3655d14,c,4,3) at write+0x7d
> syscall(2f,2f,2f,28163000,598) at syscall+0x1e0
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (4, FreeBSD ELF32, write), eip = 0x280cde8f, esp = 
> 0xbfbfea8c, ebp = 0xbfbfead8 ---
> 
> (kgdb) l *m_getm+0xa5
> 0xc05b4805 is in m_getm (/usr/src/sys/kern/uipc_mbuf.c:128).
> 123             if (num > 0) {
> 124                     if ((top = cur = m_getcl(how, type, 0)) == NULL)
> 125                             goto failed;
> 126             }
> 127             num--;
> 128             top->m_len = 0;
> 129
> 130             for (i = 0; i < num; i++) {
> 131                     mb = m_getcl(how, type, 0);
> 132                     if (mb == NULL)

Looking at m_getm(), it seems it will panic everytime it's called with
len < MCLBYTES.  In that case, top will stay NULL because num will be 0,
but top is dereferenced just after that.  This bug was introduced in the
mbuma commit.  From my quick reading of the m_getm() function before the
mbuma commit, I believe the attached patch should fix your issue.  I'm
Cc'ing Bosko so that he can comment of the correctness of this patch,
since I didn't test it at all.

Cheers,
Maxime