Re: [fuse-devel] FUSE version for Linux 2.6.22-19

[Jorgen L. <lu...@lu...>]

So following the initial thread:

# hello /tmp/a -d -f &
<4>fill_super: 1
<4>new_conn: enter
<4>new_conn: blocked = 1
<4>new_conn: exit
<4>fuse_send_init: calling request_send_background
<4>request_send_nowait: enter
<4>request_send_nowait: 2
<4>request_send_nowait: 3
<4>queue_request: enter
<4>queue_request: 2
<4>queue_request: 3
<4>queue_request: 4
<4>queue_request: leave
<4>request_send_nowait: 4
<4>request_send_nowait: 5
<4>request_send_nowait: leave
<4>fill_super: finished
FUSE library version: 2.8.1

How annoying. So the posting of the event all goes according to plan, but 
unfortunately, process_init_reply() is never called.

Not I have no idea what's wrong, if it hangs somewhere I can dig deeper, but if 
everything goes ok, I'm not entirely sure why the queue is never emptied.

I suspect even if I clear "->blocked" there is larger issues at play, if a 
simple lock/wait does not work, it will probably not work in the greater scheme 
of things. Presumably it must be some difference in CONFIG for.. linked list? 
locking? threads? Hmmm




Jorgen Lundman wrote:
>
> Moving further a field, I find that if I mount "hello", and then do a "df", it
> hangs here:
>
>
> struct fuse_req *fuse_get_req(struct fuse_conn *fc)
> {
>       struct fuse_req *req;
>       sigset_t oldset;
>       int intr;
>       int err;
>
>       atomic_inc(&fc->num_waiting);
>       block_sigs(&oldset);
>       intr = wait_event_interruptible(fc->blocked_waitq, !fc->blocked);
>
>
>
> I'm not sure if there are any CONFIG options that determine how
> wait_event_interruptible works. But tracing the "fc->blocked" mutex, I get the
> following output:
>
> # hello /tmp/a -d -f&
> 26502
> <4>fill_super: 1
> <4>new_conn: enter
> <4>new_conn: blocked = 1
> <4>new_conn: exit
> <4>fill_super: finished
> FUSE library version: 2.8.1
> nullpath_ok: 0
>
> # df -h
> fuse_statfs: enter
> <4>fuse_statfs: 0.5
> <4>fuse_get_req: enter
> <4>fuse_get_req: 1
> <4>fuse_get_req: 2
>
> So blocked is set in fill_super(new_conn()), and never cleared.
>
> At my best guess, fuse_send_init() calls request_send_background() with ".end =
> process_init_reply",
>
> and process_init_reply() will set "blocked = 0" if it were to be called.
>
> I'm using kernel 2.6.22-19 fuse.ko, but userland fuse-2.8.1. I was under the
> impression that it should be capable of talking to an older kernel.
>
>
>
>
>
> Jorgen Lundman wrote:
>> Ah I see. I have CONFIG_SLAB defined, and it should be CONFIG_SLOB apparently.
>> Great feedback there, Linux!
>>
>> So now it passes all of the fuse_fill_super and does not panic. It does appear
>> to hang, but i will have to explore why that is next.
>>
>>
>> Jorgen Lundman wrote:
>>> Actually, tried a few versions and they all die in the same way. So, back to
>>> original 2.6.22-19 fuse kernel sources, and peppered prints all over the place
>>> to figure out where it dies;
>>>
>>>
>>>         printk("fill_super: 3\n");
>>>
>>>         fc = new_conn();
>>>         if (!fc)
>>>             return -ENOMEM;
>>>
>>>         printk("fill_super: 3.1\n");
>>>
>>>
>>>
>>> static struct fuse_conn *new_conn(void)
>>> {
>>>         struct fuse_conn *fc;
>>>
>>>         printk("new_conn: enter\n");
>>>         fc = kzalloc(sizeof(*fc), GFP_KERNEL);
>>>         printk("new_conn: 1\n");
>>>
>>>
>>>
>>> fill_super: 3
>>> new_conn: enter
>>> CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
>>> 84088e7c, ra == c02683cc
>>>
>>> Which is strange. That is a fairly vanilla call to kzalloc, so I do not
>>> understand why it would crash. Plenty other modules call this function, so it is
>>> somewhat confusing it would mind so much.
>>>
>>>
>>>
>>> Jorgen Lundman wrote:
>>>>
>>>> Hello list,
>>>>
>>>> I can not change the kernel, just compile modules for it.
>>>>
>>>>
>>>> When I compile the FUSE version that comes with a pure 2.6.22-19 kernel version,
>>>> I get the following panic:
>>>>
>>>> NTFS volume version 3.1.
>>>> CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
>>>> 84088e7c, ra == c023038c
>>>> Oops[#1]:
>>>>
>>>> epc   : 84088e7c kmem_cache_zalloc+0x24/0xa0     Tainted: PF
>>>> ra    : c023038c fuse_fill_super+0x2e0/0x650 [fuse]
>>>> Status: 11001c02    KERNEL EXL
>>>>
>>>> Process ntfs-3g (pid: 17079, threadinfo=8a3d4000, task=898d2278)
>>>>
>>>> Call Trace:
>>>> [<84088e7c>] kmem_cache_zalloc+0x24/0xa0
>>>> [<c023038c>] fuse_fill_super+0x2e0/0x650 [fuse]
>>>> [<8408fe30>] get_sb_bdev+0x26c/0x2cc
>>>> [<c022f9d4>] fuse_get_sb_blk+0x28/0x34 [fuse]
>>>> [<8408e1c8>] vfs_kern_mount+0x5c/0x120
>>>> [<8408e2e8>] do_kern_mount+0x4c/0x134
>>>> [<840ae918>] do_mount+0x19c/0x76c
>>>> [<840aefb0>] sys_mount+0xc8/0x1c8
>>>> [<84012be4>] stack_done+0x20/0x3c
>>>>
>>>>
>>>> If I fetch the latest fuse package, I find the kernel sources are no longer
>>>> included. Oh well.
>>>>
>>>> If I get the kernel sources from the latest/stable kernel 2.6.31.5 it does not
>>>> compile:
>>>>
>>>> In file included from fs/fuse/dev.c:9:
>>>> fs/fuse/fuse_i.h:264: error: field 'cuse_init_in' has incomplete type
>>>> fs/fuse/fuse_i.h:265: error: field 'cuse_init_out' has incomplete type
>>>>
>>>>
>>>> Is there a recommended FUSE version that may fix the panic problem, but might
>>>> also still compile on 2.6.22-19 ?
>>>>
>>>> Please advice,
>>>>
>>>> Lund
>>>>
>>>
>>
>

-- 
Jorgen Lundman       | <lu...@lu...>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)