Re: kern/44336: tests/fs/vfs/t_renamerace p2k_ffs_renamerace_dirs triggers KASSERT

[Antti Kantee <pooka%iki.fi@localhost>]

The following reply was made to PR kern/44336; it has been noted by GNATS.

From: Antti Kantee <pooka%iki.fi@localhost>
To: gnats-bugs%NetBSD.org@localhost
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@localhost>
 > To: gnats-bugs%NetBSD.org@localhost
 > 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@localhost 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.