Date: Sun, 15 Jan 2006 12:40:02 -0800 From: Frank Mayhar <frank@exit.com> To: hackers@freebsd.org Cc: FreeBSD-Current <current@freebsd.org> Subject: Panic in nfs_putpages() on 6-stable. Message-ID: <1137357602.1362.23.camel@realtime.exit.com>
next in thread | raw e-mail | index | archive | help
I've run into this panic a couple of times over the last few days, while
trying to rebuild ports using an NFS-mounted /usr/ports filesystem. It
happened again today and this time I had time to look at the dump.
The problem is a null pointer dereference in nfs_putpages(), when it
tries to look at np->n_size. It turns out that v_data is NULL on entry
to this routine. Looking at the stack I see why:
#6 0xc0674e4a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc05eb030 in nfs_putpages (ap=0xe81c6a14)
at /usr/src/sys/nfsclient/nfs_bio.c:301
#8 0xc0691148 in VOP_PUTPAGES_APV (vop=0x1000, a=0xe81c6a14) at
vnode_if.c:2164
#9 0xc064fd8e in vnode_pager_putpages (object=0xcafaa840, m=0x1000,
count=0x1000, sync=0x5, rtvals=0x1000)
at vnode_if.h:1119
During symbol reading, Attribute value is not a constant (DW_FORM_ref4).
#10 0xc064b99e in vm_pageout_flush (mc=0xe81c6ab0, count=0x1, flags=0x5)
at vm_pager.h:147
#11 0xc0647d0c in vm_object_page_collect_flush (object=0xcafaa840,
p=0xc19e5218, curgeneration=0x0, pagerflags=0x5)
at /usr/src/sys/vm/vm_object.c:950
#12 0xc0647800 in vm_object_page_clean (object=0xcafaa840, start=0x0,
end=Unhandled dwarf expression opcode 0x93
) at /usr/src/sys/vm/vm_object.c:753
#13 0xc0647525 in vm_object_terminate (object=0xcafaa840)
at /usr/src/sys/vm/vm_object.c:608
#14 0xc064e5ad in vnode_destroy_vobject (vp=0xcb58c110)
at /usr/src/sys/vm/vnode_pager.c:166
#15 0xc05ee075 in nfs_reclaim (ap=0x1000)
at /usr/src/sys/nfsclient/nfs_node.c:247
#16 0xc069095e in VOP_RECLAIM_APV (vop=0x1000, a=0xe81c6c90) at
vnode_if.c:1589
#17 0xc0587aa5 in vgonel (vp=0xcb58c110) at vnode_if.h:818
#18 0xc0584ac2 in vlrureclaim (mp=0xc9b2e400)
at /usr/src/sys/kern/vfs_subr.c:612
#19 0xc0584e8b in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:725
#20 0xc052034c in fork_exit (callout=0xc0584d00 <vnlru_proc>, arg=0x0,
frame=0xe81c6d38)
at /usr/src/sys/kern/kern_fork.c:789
#21 0xc0674eac in fork_trampoline ()
at /usr/src/sys/i386/i386/exception.s:208
In nfs_reclaim(), just before he calls vnode_destroy_vobject(), he
zfrees and clears vp->v_data. When, down in the guts of vm_object.c, he
tries to flush the associated pages, v_data is already NULL so he goes
boom.
Now, why does he do the zfree/clear before vnode_destroy_vobject()? Is
he assuming that there are no pages associated with this vnode that need
to be flushed? Should there be? I looked at some other file systems and
they do the same thing. The obvious fix is to move the zfree/clear to
after the vnode_destroy_vobject() but if there should be no pages that
need to be flushed on the vnode at this point, that would just hide the
problem.
I can keep looking at the code to answer my question but I thought I
would ask here first, in case there's someone who knows the answer right
away. Thanks.
--
Frank Mayhar frank@exit.com http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
http://www.exit.com/blog/frank/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1137357602.1362.23.camel>