panic in fuse_vnop_mmap

[Andreas Guðmundsson]

This is the second day in a row that I've crashed my machine

by taking the following steps

 1. I mount a remote filesystem with sshfs

 2. I play some music

 3. I pause playback

 4. I go for a long coffee break 

    (in the meantime I guess the ssh connection goes down)

 5. I resume playback

My machine crashes!

I'm running OSXFUSE 2.4.2 and SSHFS 2.4.1.

(gdb) showkmod 0x00feb010

kmod        address     size        id    refs     version  name

0x00feb010  0x00fd6000  0x00016000  125      0       2.4.2  com.github.osxfuse.filesystems.osxfusefs

(gdb) bt

#0  Debugger (message=0x5dd7fc "panic") at /SourceCache/xnu/xnu-1504.15.3/osfmk/i386/AT386/model_dep.c:867

#1  0x0021b837 in panic (str=0xfe99f4 "\"OSXFUSE: fuse_vnop_mmap(): called on a dead file system\"@/Users/benjamin/Documents/Projekte/OSXFUSE/Repositories/osxfuse/kext/fuse_vnops.c:1705") at /SourceCache/xnu/xnu-1504.15.3/osfmk/kern/debug.c:303

#2  0x00fe3ef5 in fusefs_start () #My guess, fuse_vnop_mmap

#3  0x00fe6fc0 in fusefs_start () #          fuse_biglock_vnop_mmap

#4  0x002fca71 in VNOP_MMAP (vp=0x1494bce8, fflags=5, ctx=0x1c7616d4) at /SourceCache/xnu/xnu-1504.15.3/bsd/vfs/kpi_vfs.c:3840

#5  0x004aa555 in ubc_map (vp=0x1494bce8, flags=5) at /SourceCache/xnu/xnu-1504.15.3/bsd/kern/ubc_subr.c:1378

#6  0x00251562 in vnode_pager_map (mem_obj=0x14627f78, prot=5) at /SourceCache/xnu/xnu-1504.15.3/osfmk/vm/bsd_vm.c:943

#7  0x0026919c in vm_map_enter_mem_object_control (target_map=0x108c5c2c, address=0x108bf50, initial_size=1048576, mask=0, flags=1, control=0x13e8e938, offset=202375168, copy=1, cur_protection=3, max_protection=7, inheritance=1) at /SourceCache/xnu/xnu-1504.15.3/osfmk/vm/vm_map.c:2710

#8  0x004855ea in mmap (p=0x1c9b07e0, uap=0xfca8048, retval=0x1c761614) at /SourceCache/xnu/xnu-1504.15.3/bsd/kern/kern_mman.c:518

#9  0x004f82fb in unix_syscall64 (state=0xfca8044) at /SourceCache/xnu/xnu-1504.15.3/bsd/dev/i386/systemcalls.c:433

osxfuse/kext/fuse_vnops.c:1705

    if (fuse_isdeadfs_fs(vp)) {

        panic("OSXFUSE: fuse_vnop_mmap(): called on a dead file system");

    }

What about returning EBADF instead of panicking?

Can I download debug symbols for released kexts?

    

[Benjamin Fleischer]

Hi Andreas,

Thanks for the bug report.

Am 27.06.2012 um 19:31 schrieb Andreas Guðmundsson:

osxfuse/kext/fuse_vnops.c:1705

    if (fuse_isdeadfs_fs(vp)) {

        panic("OSXFUSE: fuse_vnop_mmap(): called on a dead file system");

    }

What about returning EBADF instead of panicking?

I agree, panicking is not a good idea. What do you think about ENXIO instead of EBADF? ENXIO is returned by NFS in case the share is no longer available.

The patch can be found on https://github.com/osxfuse/kext/commits/osxfuse-2.4 and was authored by Anatol Pomozov.

Can I download debug symbols for released kexts?    

The unstripped kernel extensions can be found on https://github.com/osxfuse/kext/downloads. The 10.6 kernel extension is used on 10.6, 10.7 and 10.8.

Regards,

Benjamin

[Andreas Guðmundsson]

On Wed, Jun 27, 2012 at 11:50 PM, Benjamin Fleischer <fle...@gmail.com> wrote:

> What about returning EBADF instead of panicking?
>
>
> I agree, panicking is not a good idea. What do you think about ENXIO instead
> of EBADF? ENXIO is returned by NFS in case the share is no longer available.

I'm not sure about ENXIO. According to errno.h(in POSIX.1-2008) ENXIO
means "No such device or address" and to me that seems like an
appropriate error for open[1], the file can't be opened since the
backing filesystem has gone away. But if you've already open an fd and
the backing filesystem goes away, then that fd has become invalid and
any operation on fd should return EBADF. That is just how I *feel*
about it though.

More importantly, I don't see how returning ENXIO in this situation
fits with the mmap documentation[2].


[0] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html
[ENXIO] No such device or address.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html
[ENXIO] O_NONBLOCK is set, the named file is a FIFO, O_WRONLY is
set, and no process has the file open for reading.
[ENXIO] The named file is a character special or block special file,
and the device associated with this special file does not exist.

[2] http://pubs.opengroup.org/onlinepubs/9699919799/functions/mmap.html
[EBADF] The fildes argument is not a valid open file descriptor.
[ENXIO] Addresses in the range [off,off+len) are invalid for the
object specified by fildes.
[ENXIO] MAP_FIXED was specified in flags and the combination of
addr, len, and off is invalid for the object specified by fildes.
[ENXIO] [TYM] The fildes argument refers to a typed memory object
that is not accessible from the calling process.

>
> The patch can be found
> on https://github.com/osxfuse/kext/commits/osxfuse-2.4 and was authored by
> Anatol Pomozov.

Great!

> The unstripped kernel extensions can be found
> on https://github.com/osxfuse/kext/downloads. The 10.6 kernel extension is
> used on 10.6, 10.7 and 10.8.

Thank you.

[Greg Troxel]

What happens on other systems if you have a file open on a disk and the
disk goes away?
That seems to be the analogous case.

[Benjamin Fleischer]

Am 28.06.2012 um 14:36 schrieb Andreas Guðmundsson:

On Wed, Jun 27, 2012 at 11:50 PM, Benjamin Fleischer <fle...@gmail.com> wrote:

I agree, panicking is not a good idea. What do you think about ENXIO instead

of EBADF? ENXIO is returned by NFS in case the share is no longer available.

I'm not sure about ENXIO. According to errno.h(in POSIX.1-2008) ENXIO
means "No such device or address" and to me that seems like an
appropriate error for open[1], the file can't be opened since the
backing filesystem has gone away. But if you've already open an fd and
the backing filesystem goes away, then that fd has become invalid and
any operation on fd should return EBADF. That is just how I *feel*
about it though.

More importantly, I don't see how returning ENXIO in this situation
fits with the mmap documentation[2].

At least on Mac OS X a file system's mmap function is called solely by kernel function VNOP_MMAP. Besides ubc_map no other function calls VNOP_MMAP. Here is what ubc_map does:

error = VNOP_MMAP(vp, flags, vfs_context_current());

if (error != EPERM)

error = 0;

Therefore it does not really matter if we return EBADF or ENXIO, because the return code is ignored anyway. Syscall mmap gets its error codes from function mmap in kern/kern_mman.c, if I'm not mistaken.

Interesting fact: NFS returns ENXIO even for read or write operations (that require an open fd, too) if the backing filesystem went away.

[Andreas Guðmundsson]

I stand corrected :)

Look at kern/init_sysent.c
{AC(mmap_args), 0, 0, (sy_call_t *)mmap, munge_wwwwwl, munge_dddddd,
_SYSCALL_RET_ADDR_T, 28}, /* 197 = mmap */

The call-chain from mmap to VNOP_MMAP seems to be

bsd/dev/i386/systemcalls.c:unix_syscall
bsd/kern/kern_mman.c:mmap
osfmk/vm/vm_map.c:vm_map_enter_mem_object
osfmk/vm/memory_object.c: memory_object_map
osfmk/vm/bsd_vm.c:vnode_pager_map
bsd/kern/ubs_subr.c:ubc_map
bsd/vfs/kpi_vfs:VNOP_MMAP

Simplified from kern_mman.c:mmap
result = vm_map_enter_mem_object(...)
switch (result) {
case KERN_SUCCESS:
*retval = user_addr + pageoff;
error = 0;
break;
case KERN_INVALID_ADDRESS:
case KERN_NO_SPACE:
error = ENOMEM;
break;
case KERN_PROTECTION_FAILURE:
error = EACCES;
break;
default:
error = EINVAL;
break;
}
return error;

There's that. Do you know where in that call-chain the kernel detects
that VNOP_MMAP failed. I'm wondering since ubc_map suppresses all
errors except EPERM.

[Benjamin Fleischer]

I don't know but I don't think that a failure of VNOP_MMAP (besides EPERM) is detected directly. The ubc_map documentation states:

    

It [ubc_map()] is primarily used by:

    

        o mmap(), when mapping a file

        o The deprecated map_fd() interface, when mapping a file

        o When mapping a shared file (a shared library in the

          shared segment region)

        o When loading a program image during the exec process

    

        ...all of these uses ignore the return code, and any fault that

        results later because of a failure is handled in the fix-up path

        of the fault handler.

I have not tried to make sense of the call chain but I suppose the best point to start looking for this fault handler would be function mmap in bsd/kern/kern_mman.c.

[Andreas Guðmundsson]

On Wed, Jun 27, 2012 at 11:50 PM, Benjamin Fleischer <fle...@gmail.com> wrote:

> The patch can be found on
> https://github.com/osxfuse/kext/commits/osxfuse-2.4 and was authored by
> Anatol Pomozov.

I've used this patch without trouble for 2 weeks now. I'm happy with
it, thank you :)