tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NFS experts: stale vnode pointer in ufs_fhtovp ?



On Sat, Aug 29, 2009 at 10:57:37PM +0000, David Holland wrote:
> On Sun, Aug 30, 2009 at 12:05:39AM +0200, Manuel Bouyer wrote:
>  > 187             if ((error = VFS_VGET(mp, ufhp->ufid_ino, &nvp)) != 0) {
>  > 188                     *vpp = NULLVP;
>  > 189                     return (error);
>  > 190             }
>  > 191             ip = VTOI(nvp);
>  > 192             if (ip->i_mode == 0 || ip->i_gen != ufhp->ufid_gen) {
>  > 193                     vput(nvp);
>  > 194                     *vpp = NULLVP;
>  > 195                     return (ESTALE);
>  > 196             }
>  > 
>  > It paniced because ip was NULL (cmpw   $0,0x80(%eax) is ip->i_mode == 0). 
> 
> I can't think of any reason a valid UFS vnode should have a null inode
> pointer. Maybe someone else can though?
> 
> My first guess would be that you got back some other fs's vnode and
> that something upstream, maybe the vnode cache, is/was all screwed
> up. My second guess would be that you've hit a(nother) bug in vnode
> reclaim/recycle, and you got what was a valid ufs vnode when it was
> fetched from the cache but has since been cleaned on you.
> 
> I don't know why either of these would be happening, thoughI got the same 
> panic again, this time I got a core dump:
#23 0xc010cc37 in calltrap ()
#24 0xc02ccc89 in ufs_fhtovp (mp=0xccf7b000, ufhp=0xcd585918, vpp=0xcd585b40)
    at /home/bouyer/src-5/src/sys/ufs/ufs/ufs_vfsops.c:191
#25 0xc02a5425 in ffs_fhtovp (mp=0xccf7b000, fhp=0xcd585ae0, vpp=0xcd585b40)
    at /home/bouyer/src-5/src/sys/ufs/ffs/ffs_vfsops.c:1992
#26 0xc039a6cc in VFS_FHTOVP (mp=0xccf7b000, a=0xcd585ae0, b=0xcd585b40)
    at /home/bouyer/src-5/src/sys/kern/vfs_subr.c:3034
#27 0xc026b518 in nfsrv_fhtovp (nsfh=0xcd585ad4, lockflag=1, vpp=0xcd585b40, 
    cred=0xcd7ff000, slp=0xcdb8feb0, nam=0xc2c0e800, rdonlyp=0xcd585b4c, 
    kerbflag=0, pubflag=0) at /home/bouyer/src-5/src/sys/nfs/nfs_subs.c:2515
#28 0xc0260d38 in nfsrv_write (nfsd=0xcd5ece10, slp=0xcdb8feb0, 
    lwp=0xccee92a0, mrq=0xcd585bd0)
    at /home/bouyer/src-5/src/sys/nfs/nfs_serv.c:872
#29 0xc0270134 in nfssvc_nfsd (nsd=0xcd585c38, argp=0xbb5ffc28, l=0xccee92a0)
    at /home/bouyer/src-5/src/sys/nfs/nfs_syscalls.c:685
#30 0xc0270de2 in sys_nfssvc (l=0xccee92a0, uap=0xcd585d00, retval=0xcd585d28)
    at /home/bouyer/src-5/src/sys/nfs/nfs_syscalls.c:349
#31 0xc03f6ec8 in syscall (frame=0xcd585d48)
    at /home/bouyer/src-5/src/sys/sys/syscallvar.h:49
#32 0xc010056e in syscall1 ()

c89 in ufs_fhtovp (mp=0xccf7b000, ufhp=0xcd585918, vpp=0xcd585b40)
    at /home/bouyer/src-5/src/sys/ufs/ufs/ufs_vfsops.c:191
191             ip = VTOI(nvp);
(gdb) print nvp
$1 = (struct vnode *) 0xd2e542e8
(gdb) print *nvp
$2 = {v_uobj = {vmobjlock = {u = {mtxa_owner = 4}}, pgops = 0xc04e7aa0,
    memq = {tqh_first = 0x0, tqh_last = 0xd2e542f0}, uo_npages = 0,
    uo_refs = 1, rb_tree = {rbt_root = 0x0, rbt_ops = 0xc04e79bc,
      rbt_minmax = {0xd2e54300, 0xd2e54300}}}, v_cv = {cv_opaque = {0x0,
      0xd2e54310}, cv_wmesg = 0xc05f036b "vnode"}, v_size = 0,
  v_writesize = 0, v_iflag = 524288, v_vflag = 16, v_uflag = 0,
  v_numoutput = 0, v_writecount = 0, v_holdcnt = 0, v_synclist_slot = 4,
  v_mount = 0xccf7b000, v_op = 0xc1ac0e00, v_freelist = {
    tqe_next = 0xd212e964, tqe_prev = 0xcf06c40c}, v_freelisthd = 0x0,
  v_mntvnodes = {tqe_next = 0xd2e4945c, tqe_prev = 0xcd3e2a90},
  v_cleanblkhd = {lh_first = 0x0}, v_dirtyblkhd = {lh_first = 0x0},
  v_synclist = {tqe_next = 0xd212e964, tqe_prev = 0xce765364}, v_dnclist = {
    lh_first = 0x0}, v_nclist = {lh_first = 0x0}, v_un = {
    vu_mountedhere = 0x0, vu_socket = 0x0, vu_specnode = 0x0,
    vu_fifoinfo = 0x0, vu_ractx = 0x0}, v_type = VREG, v_tag = VT_NON,
  v_lock = {vl_lock = {rw_owner = 3438187180}, vl_canrecurse = 0,
    vl_recursecnt = 0}, v_vnlock = 0xd2e54388, v_data = 0x0, v_klist = {
    slh_first = 0x0}}

The v_mount pointer matches what was passed to ufs_fhtovp, but
the VI_CLEAN flag is set ...

-- 
     NetBSD: 26 ans d'experience feront toujours la difference
--


Home | Main Index | Thread Index | Old Index