NFS, pefs panic: vputx: neg ref cnt

Rick Macklem rmacklem at uoguelph.ca
Tue Feb 24 22:56:48 UTC 2015


Benjamin Kaduk wrote:
> On Mon, 23 Feb 2015, Brett A Wiggins wrote:
> 
> > I am able to access the NFS share from OSX but when I try and
> > access it
> > via a Linux machine I get a kernel panic. The core dump is posted
> > below;
> >
> > http://pastebin.com/Da5bciWX
> >
> > I'm not sure how to read a core dump (I'm not a developer) but
> > there is
> > a line;
> >
> > Panic: vputx: neg ref cnt
> 
> This particular panic ~always means "programmer error".
> 
> Looking at the backtrace:
> 
> KDB: stack backtrace:
> #0 0xffffffff80963000 at kdb_backtrace+0x60
> #1 0xffffffff80928125 at panic+0x155
It doesn't make sense to call vputx() from VOP_RECLAIM(),
since the ref cnt is already 0.
vputx() derefs the vnode, making the ref cnt. -1, I think?
> #2 0xffffffff809c8b75 at vputx+0x2d5
> #3 0xffffffff8195b3fb at pefs_reclaim+0xdb
> #4 0xffffffff80e439a7 at VOP_RECLAIM_APV+0xa7
> #5 0xffffffff809c9951 at vgonel+0x1c1
> #6 0xffffffff809c9de9 at vrecycle+0x59
This call to pefs_inactive() indicates that the ref cnt.
would be 0 at this point.
> #7 0xffffffff8195b317 at pefs_inactive+0x87
> #8 0xffffffff80e43897 at VOP_INACTIVE_APV+0xa7
> #9 0xffffffff809c8722 at vinactive+0x102
> #10 0xffffffff809c8b12 at vputx+0x272
> #11 0xffffffff808811ee at nfsrvd_readdirplus+0x117e
> #12 0xffffffff80863d9e at nfsrvd_dorpc+0x6de
> #13 0xffffffff80872d94 at nfssvc_program+0x554
> #14 0xffffffff80b27957 at svc_run_internal+0xc77
> #15 0xffffffff80b26bee at svc_run+0x1de
> #16 0xffffffff8087321a at nfsrvd_nfsd+0x1ca
> #17 0xffffffff80883417 at nfssvc_nfsd+0x107
> 
> It seems that both NFS and PEFS are calling vputx on the same vnode.
> 
> Given the popularity of NFS, I would be more inclined to suspect PEFS
> than
> NFS, but it could still be a bug that only appears when both are used
> together.
> 
> Adding rmacklem to the cc list since he's the resident NFS expert.
> 
Now for the dumb question...where is the pefs stuff?
(I've never heard of it and a quick find/grep didn't locate it in the
 kernel source tree.)

I suspect that there is a bogus vput() call in pefs_reclaim(). Neither
pefs_inactive() nor pefs_reclaim() should have a vput() call in them,
from what I know of the VFS.

rick

> -Ben
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> 


More information about the freebsd-fs mailing list