Kernel Panic: vnode_reclaim_internal: cleaned vnode isn't

[GoogleCodeExporter]

Hi,

I'm using the first publicly available version of MacFuse and SSHFS on Mac OS X 
10.4.7 on 
PowerBook G4. 

I've got a kernel panic while unmounting remote SSHFS filesystem. I suspect 
this might be due to 
the error messages "Bad file descriptor" that I've been getting during working 
on the remote 
filesystem. The remote filesystem that was mounted over SSH might be buggy 
since I develop it 
for myself. But I guess it shouldn't cause panic on the host.

There is the full panic description:

Thu Jan 25 10:59:08 2007
panic(cpu 0 caller 0x000E89A8): vnode_reclaim_internal: cleaned vnode isn't
Latest stack backtrace for cpu 0:
      Backtrace:
         0x00095718 0x00095C30 0x0002683C 0x000E89A8 0x000E5F10 0x000EC480 0x000
         0x000ABF30 0xFFFFFFFF
Proceeding back via exception chain:
   Exception state (sv=0x21140280)
      PC=0x9006424C; MSR=0x0000D030; DAR=0xA000C55C; DSISR=0x40000000; LR=0x0000

Kernel version:
Darwin Kernel Version 8.7.0: Fri May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj
*********

Thu Jan 25 11:06:11 2007
panic(cpu 0 caller 0x000E89A8): vnode_reclaim_internal: cleaned vnode isn't
Latest stack backtrace for cpu 0:
      Backtrace:
         0x00095718 0x00095C30 0x0002683C 0x000E89A8 0x000E5F10 0x000EC480 0x000
         0x000ABF30 0x743B266C
Proceeding back via exception chain:
   Exception state (sv=0x21821780)
      PC=0x9006424C; MSR=0x0000D030; DAR=0xA000C55C; DSISR=0x40000000; LR=0x0000

Kernel version:
Darwin Kernel Version 8.7.0: Fri May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj
*********

Original issue reported on code.google.com by Kirill.K...@gmail.com on 25 Jan 2007 at 8:45

[GoogleCodeExporter]

By first available version, do you mean "0.1.0b004"? If so, please upgrade to 
the most recent release and see if 
you still have this problem. There *was* a panic condition in that release, so 
we must make sure if we are 
looking at a new problem or an old one that's already been fixed.

Original comment by si...@gmail.com on 25 Jan 2007 at 5:50

[GoogleCodeExporter]

Can you also tell me what your setup is? You have a host and a client. These 
are two different machines, right 
(you are not connecting to the same machine)? Which one is running MacFUSE and 
which one is running your file 
system. Is your file system an in-kernel VFS?

Original comment by si...@gmail.com on 25 Jan 2007 at 5:52

[GoogleCodeExporter]

I've just tried the latest version (0.1.7) but, unfortunately, the bug is still 
shown under the same conditions. 
The panic message is the same too.

I have the following setup:

The host machine runs Mac OS X 10.4.7. 
The remote machine runs NetBSD 3.1 and my filesystem. Again, it is buggy, it 
may represent files not 100% 
correct (in fact, it doesn't care about permissions/date and some other things, 
so that probably SSHFS couldn't  
obtain all necessary information about the remote file). BUT however the remote 
filesystem works, it must not 
damage the host.

I think the key point is those appearing error messages - "Bad file descriptor" 
that appear when I issue, for 
instance, the ls command on the remote file system. I don't know under which 
conditions ls(1) prints "Bad file 
descriptor", but it doesn't matter anyway. 

According to the Darwin source code (xnu-792.6.76/bsd/vfs/vfs_subr.c) the given 
panic occurs if vp->v_data 
isn't  NULL. Looks like that due to some reason fuse doesn't set it to NULL. 

Original comment by Kirill.K...@gmail.com on 26 Jan 2007 at 3:17

[GoogleCodeExporter]

I need a way to reproduce this. Would it be possible to have access to your 
file system?

Original comment by si...@gmail.com on 26 Jan 2007 at 6:33

[GoogleCodeExporter]

In any case, what's the minimum set of operations (exact sequence) that you can 
do in your setup to cause this?

Original comment by si...@gmail.com on 26 Jan 2007 at 7:01

[GoogleCodeExporter]

OK. Try to use the following commands:

(NB: asingh, check out your gmail mailbox - I've sent you all confidential 
information via email)

$ cd tmp; mkdir test
$ sshfs USERNAME@HOSTNAME:/ test
$ ls test/mnt/mp/
(NB: at this point you'll see "Bad file descriptor" messages)
$ umount test  
and this leads to panic.

Original comment by Kirill.K...@gmail.com on 27 Jan 2007 at 12:18

[GoogleCodeExporter]

Fixed in the upcoming release.

Original comment by si...@gmail.com on 28 Jan 2007 at 9:30

• Changed state: Fixed