PUFFS and existing file that get ENOENT

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Hello

I am tracking a rare bug with perfused, where an existing file is
reported as unexistent. It happens after a few hours of usage, and it
happens only once: if I retry accessing the file, I am successful.

Adding traces in perfused while performing ktrace on the calling
process, I am now confident that perfused is not the component that
raises the ENOENT. Here is what I get in the ktrace:

 14085      1 cc1      1326421055.211110998 CALL  close(4)
 14085      1 cc1      1326421055.214918302 RET   close 0
 14085      1 cc1      1326421055.215025195 CALL        
        open(0xbb960a90,4,0x1b6)
 14085      1 cc1      1326421055.215031533 NAMI  
        "/gfs/manu/netbsd/usr/src/sys/sys/featuretest.h"
 14085      1 cc1      1326421055.216282844 RET 
          open -1 errno 2 No such file or directory


In the PUFFS trace I collect in perfused, this open() only causes
LOOKUPs up to /manu/netbsd/usr, all successful, then nothing.

1326421055.215229913 LOOKUP "/" cn = "manu"  error = 0
1326421055.215396312 LOOKUP "/manu" cn = "netbsd" error = 0
1326421055.215749931 LOOKUP "/manu/netbsd"  cn = "usr" error = 0

That means the ENOENT is decided by the kernel on its own, perfused does
not produce it. The question is where can this come from? There are two
ENOENT occurences in sys/fs/puffs. One can happen at mount time, and I
ruled out the other in puffsop_flush() by adding a printf() that never
show up when the bug strikes.

There are also ENOENT in sys/dev/putter/putter.c, but they all have a
printf() that I would have seen, therefore it cannot come from there.

Hence I come to the conclusion that it may come from
sys/kern/vfs_lookup.c, but it is very unlikely that there is a bug there
that went unnoticed for other filesystems.

Anyone would have an idea of what can possibly be going on?


-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost