NetBSD Problem Report #44336

From www@NetBSD.org  Fri Jan  7 12:11:04 2011
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id BF7AC63BAE7
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  7 Jan 2011 12:11:03 +0000 (UTC)
Message-Id: <20110107121102.B264163BA81@www.NetBSD.org>
Date: Fri,  7 Jan 2011 12:11:02 +0000 (UTC)
From: pooka@iki.fi
Reply-To: pooka@iki.fi
To: gnats-bugs@NetBSD.org
Subject: tests/fs/vfs/t_renamerace p2k_ffs_renamerace_dirs triggers KASSERT
X-Send-Pr-Version: www-1.0

>Number:         44336
>Category:       kern
>Synopsis:       tests/fs/vfs/t_renamerace p2k_ffs_renamerace_dirs triggers KASSERT
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 07 12:15:00 +0000 2011
>Closed-Date:    Mon Oct 07 05:00:40 +0000 2013
>Last-Modified:  Mon Oct 07 05:00:40 +0000 2013
>Originator:     Antti Kantee
>Release:        
>Organization:
>Environment:
>Description:
The rump_ffs component of the test occasionally dies, always in
the same place.  I'm not quite sure in which layer the problem lies.

panic: kernel diagnostic assertion "vp->v_size == ip->i_size" failed: file "/usr/allsrc/src/sys/rump/fs/lib/libffs/../../../../ufs/ufs/ufs_lookup.c", line 1262
rump kernel halting...
halted
failed: child died

(gdb) print ip->i_size
$3 = 524
(gdb) print vp->v_size
$4 = 512
(gdb) bt
#0  0xbba000d7 in _lwp_kill () from /usr/lib/libc.so.12
#1  0xbba0008e in raise () from /usr/lib/libc.so.12
#2  0xbb9ff914 in abort () from /usr/lib/libc.so.12
#3  0xbba5ec6b in rumpuser_exit (rv=-1) at rumpuser.c:517
#4  0xbbaf9179 in cpu_reboot (howto=4, bootstr=0x0) at rump.c:521
#5  0xbbac7ea8 in panic (
    fmt=0xbbb01218 "kernel %sassertion \"%s\" failed: file \"%s\", line %d")
    at /usr/allsrc/src/sys/rump/librump/rumpkern/../../../kern/subr_prf.c:302
#6  0xbbaab6bc in kern_assert (t=0xbbbe4b94 "diagnostic ", 
    f=0xbbbe4b4c "/usr/allsrc/src/sys/rump/fs/lib/libffs/../../../../ufs/ufs/ufs_lookup.c", l=1262, e=0xbbbe4cbf "vp->v_size == ip->i_size")
    at /usr/allsrc/src/sys/rump/librump/rumpkern/../../../lib/libkern/kern_assert.c:50
#7  0xbbbb353f in ufs_blkatoff (vp=0xbb8d1f0c, offset=512, res=0xbfbfd8fc, 
    bpp=0xbfbfd900, modify=true)
    at /usr/allsrc/src/sys/rump/fs/lib/libffs/../../../../ufs/ufs/ufs_lookup.c:1262
#8  0xbbbb2480 in ufs_direnter (dvp=0xbb8d1f0c, tvp=0xbb8d1e60, 
    dirp=0xbb84fc60, cnp=0xbb91bb60, newdirbp=0xbb8dddc8)
    at /usr/allsrc/src/sys/rump/fs/lib/libffs/../../../../ufs/ufs/ufs_lookup.c:841
#9  0xbbbc165d in ufs_mkdir (v=0xbfbfd9e8)
    at /usr/allsrc/src/sys/rump/fs/lib/libffs/../../../../ufs/ufs/ufs_vnops.c:1457
#10 0xbbabf24a in VOP_MKDIR (dvp=0xbb8d1f0c, vpp=0xbfbfda78, cnp=0xbb91bb60, 
    vap=0xb9e64a00)
    at /usr/allsrc/src/sys/rump/librump/rumpkern/../../../kern/vnode_if.c:836
#11 0xbbb3ceb8 in RUMP_VOP_MKDIR (dvp=0xbb8d1f0c, vpp=0xbfbfda78, 
    cnp=0xbb91bb60, vap=0xb9e64a00) at rumpvnode_if.c:383
#12 0xbbb8bc3a in p2k_node_remove () from /usr/lib/libp2k.so.2
#13 0xbba4d4fe in puffs_dispatch_create ()
   from /home/pooka/src/curpuffs/libpuffs//libpuffs.so.2
#14 0xbba4d5dc in puffs__ml_dispatch ()
   from /home/pooka/src/curpuffs/libpuffs//libpuffs.so.2
#15 0xbba4bfa5 in puffs__fsframe_gotframe ()
   from /home/pooka/src/curpuffs/libpuffs//libpuffs.so.2
#16 0xbba4fdcc in puffs__framev_input ()
   from /home/pooka/src/curpuffs/libpuffs//libpuffs.so.2
#17 0xbba50e93 in puffs__theloop ()
   from /home/pooka/src/curpuffs/libpuffs//libpuffs.so.2
#18 0xbba507b7 in puffs_cc_continue ()
   from /home/pooka/src/curpuffs/libpuffs//libpuffs.so.2
#19 0xbba51d65 in puffs_mainloop ()
   from /home/pooka/src/curpuffs/libpuffs//libpuffs.so.2
#20 0xbbb8c806 in p2k_mainloop () from /usr/lib/libp2k.so.2
#21 0xbbb8cc3d in p2k_run_diskfs () from /usr/lib/libp2k.so.2
#22 0x08048f8b in main ()

>How-To-Repeat:
run test
>Fix:

>Release-Note:

>Audit-Trail:
From: "Antti Kantee" <pooka@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/44336 CVS commit: src/tests/fs/vfs
Date: Fri, 7 Jan 2011 12:18:25 +0000

 Module Name:	src
 Committed By:	pooka
 Date:		Fri Jan  7 12:18:25 UTC 2011

 Modified Files:
 	src/tests/fs/vfs: t_renamerace.c

 Log Message:
 xfail PR kern/44336


 To generate a diff of this commit:
 cvs rdiff -u -r1.16 -r1.17 src/tests/fs/vfs/t_renamerace.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44336: tests/fs/vfs/t_renamerace p2k_ffs_renamerace_dirs
 triggers KASSERT
Date: Sat, 8 Jan 2011 06:28:52 +0000

 On Fri, Jan 07, 2011 at 12:15:01PM +0000, pooka@iki.fi wrote:
  > The rump_ffs component of the test occasionally dies, always in
  > the same place.  I'm not quite sure in which layer the problem lies.
  > 
  > panic: kernel diagnostic assertion "vp->v_size == ip->i_size" failed: file "/usr/allsrc/src/sys/rump/fs/lib/libffs/../../../../ufs/ufs/ufs_lookup.c", line 1262

 This is the same problem Manuel and I were seeing with the ufs_rename
 locking patches. Which is rather curious...

 -- 
 David A. Holland
 dholland@netbsd.org

From: Antti Kantee <pooka@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44336: tests/fs/vfs/t_renamerace p2k_ffs_renamerace_dirs triggers KASSERT
Date: Sat, 8 Jan 2011 12:06:46 +0200

 On Sat Jan 08 2011 at 06:30:05 +0000, David Holland wrote:
 > The following reply was made to PR kern/44336; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/44336: tests/fs/vfs/t_renamerace p2k_ffs_renamerace_dirs
 >  triggers KASSERT
 > Date: Sat, 8 Jan 2011 06:28:52 +0000
 > 
 >  On Fri, Jan 07, 2011 at 12:15:01PM +0000, pooka@iki.fi wrote:
 >   > The rump_ffs component of the test occasionally dies, always in
 >   > the same place.  I'm not quite sure in which layer the problem lies.
 >   > 
 >   > panic: kernel diagnostic assertion "vp->v_size == ip->i_size" failed: file "/usr/allsrc/src/sys/rump/fs/lib/libffs/../../../../ufs/ufs/ufs_lookup.c", line 1262
 >  
 >  This is the same problem Manuel and I were seeing with the ufs_rename
 >  locking patches. Which is rather curious...

 Hmm, curious indeed.  I was pretty sure the problem was somewhere in
 my code.

 Since the rename/mkdir/rmdir ops are executed in series, the only thing
 that can affect the behaviour is how they interleave before they are
 started.  The kernel exhibiting the problem gets only VOPs, so it might
 be missing some side-effect from e.g. namei, sys_rename, relookup etc.

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/44336: tests/fs/vfs/t_renamerace p2k_ffs_renamerace_dirs
 triggers KASSERT
Date: Mon, 10 Jan 2011 18:56:01 +0000

 On Sat, Jan 08, 2011 at 10:10:05AM +0000, Antti Kantee wrote:
  >  >  This is the same problem Manuel and I were seeing with the ufs_rename
  >  >  locking patches. Which is rather curious...
  >  
  >  Hmm, curious indeed.  I was pretty sure the problem was somewhere in
  >  my code.
  >  
  >  Since the rename/mkdir/rmdir ops are executed in series, the only thing
  >  that can affect the behaviour is how they interleave before they are
  >  started.  The kernel exhibiting the problem gets only VOPs, so it might
  >  be missing some side-effect from e.g. namei, sys_rename, relookup etc.

 I think the problem is related to dealing with the goop that ffs
 caches during lookup. But I don't know how exactly, and at the moment
 I'm pushing ahead with namei in the hopes that all that crud will go
 away entirely.

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 18 Jul 2011 06:54:28 +0000
State-Changed-Why:
I believe this is fixed, please check.

If not: the assertion is in fact caused by bad ufs_lookup_results (the
stuff left behind in the vnode by ufs_lookup) - the most likely causes
of this assertion are either calling ufs_direnter with information
prepared for ufs_dirrewrite, or calling ufs_direnter with information
that's stale because the directory got unlocked and was e.g. rmdir'
d and truncated behind your back.


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 30 Apr 2012 23:18:34 +0000
State-Changed-Why:
needs replacement pooka to check if this is fixed or not


State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 07 Oct 2013 05:00:40 +0000
State-Changed-Why:
Assume fixed.


>Unformatted:

Home	PR Database Search