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