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

From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/32034
Date: Sat, 12 Nov 2005 18:08:03 -0500

 I ran ktrace during a failure scenario, involving /mnt (*not* /tmp) 
 mounted as tmpfs.  See http://www.machshav.com/~smb/soffice_tmpfs.txt
 I fired up openoffice2, let it quiesce, invoked ktrace on the process 
 that seemed to be the one accumulating cpu time during open requests, 
 typed ^O, typed /mnt/ into the dialog box, then hit ENTER.
 The same sequence, using an mfs-mounted /mnt, is in
 http://www.machshav.com/~smb/soffice_mfs.txt.  A quick comparison of 
 the two shows this for tmpfs:
 
   5172 soffice.bin CALL  open(0xbfbf9fc8,0x18800,0xbaaae010)
   5172 soffice.bin NAMI  "/emul/linux/mnt"
   5172 soffice.bin NAMI  "/mnt"
   5172 soffice.bin RET   open 24/0x18
   5172 soffice.bin CALL  fstat64(0x18,0xbfbf9f4c)
   5172 soffice.bin RET   fstat64 0
   5172 soffice.bin CALL  fcntl64(0x18,2,1)
   5172 soffice.bin RET   fcntl64 0
   5172 soffice.bin CALL  getdents64(0x18,0x8188888,0x1000)
   5172 soffice.bin RET   getdents64 76/0x4c
   5172 soffice.bin CALL  llseek(0x18,0,1,0xbfbfb120,0)
   5172 soffice.bin RET   llseek 0
   5172 soffice.bin CALL  getdents64(0x18,0x8188888,0x1000)
   5172 soffice.bin RET   getdents64 52/0x34
   5172 soffice.bin CALL  close(0x18)
 
 but this for mfs:
 
   6975 soffice.bin CALL  open(0xbfbf9fc8,0x18800,0xbaaae010)
   6975 soffice.bin NAMI  "/emul/linux/mnt"
   6975 soffice.bin NAMI  "/mnt"
   6975 soffice.bin RET   open 26/0x1a
   6975 soffice.bin CALL  fstat64(0x1a,0xbfbf9f4c)
   6975 soffice.bin RET   fstat64 0
   6975 soffice.bin CALL  fcntl64(0x1a,2,1)
   6975 soffice.bin RET   fcntl64 0
   6975 soffice.bin CALL  getdents64(0x1a,0x818ebd0,0x4000)
   6975 soffice.bin RET   getdents64 76/0x4c
   6975 soffice.bin CALL  lstat64(0xb6fe5c18,0xbfbfae70)
   6975 soffice.bin NAMI  "/emul/linux/mnt/foo.txt"
   6975 soffice.bin NAMI  "/mnt/foo.txt"
   6975 soffice.bin RET   lstat64 0
   6975 soffice.bin CALL  getuid
   6975 soffice.bin RET   getuid 54047/0xd31f
   6975 soffice.bin CALL  getgid
   6975 soffice.bin RET   getgid 54047/0xd31f
   6975 soffice.bin CALL  open(0xbaaa309c,0,0xbaaae010)
   6975 soffice.bin NAMI  "/emul/linux/proc/sys/kernel/ngroups_max"
   6975 soffice.bin NAMI  "/proc/sys/kernel/ngroups_max"
   6975 soffice.bin RET   open -1 errno -2 No such file or directory
   6975 soffice.bin CALL  getgroups(0x20,0xbfbfaf6c)
   6975 soffice.bin RET   getgroups 4
 
 In other words, both are doing getdents (which also resolves the 
 earlier issue), but the tmpfs instance is following that with an 
 llseek, while the mfs instance is diong lstat64.  It seems that it does 
 not like whatever it got back from getdents64.  I don't have a copy of 
 Linux readdir(3) around to see what would induce it to do llseeks -- 
 assuming, of course, that those are coming from the library and not 
 openoffice2 -- but that's where I'd look for the problem.