From: Luca R. <luc...@st...> - 2012-08-26 19:49:57
|
Hello, I have installed libfuse 2.9.1 under Linux. The version of the kernel is 3.2.0. If the "videodev" kernel module is present in memory, when I run the cusexmp example under fuse-2.9.1/example with the following options, the specified device node is never created, although from the output everything seems okay: # modprobe cuse (required) fuse-2.9.1/example$ ./cusexmp -d --maj=81 --min=0 -f --name=video0 FUSE library version: 2.9.1 unique: 1, opcode: CUSE_INIT (4096), nodeid: 0, insize: 56, pid: 8007 CUSE_INIT: 7.17 flags=0x00000001 CUSE_INIT: 7.19 flags=0x00000001 max_read=0x00020000 max_write=0x00020000 dev_major=81 dev_minor=0 dev_info: DEVNAME=video0 unique: 1, success, outsize: 103 While the output from the kernel is CUSE: failed to register chrdev region Note the "success" word at the end of the output from fuse, although no /dev/video0 is really created and the program does not exit with an error. I would like to know if that is a bug. Should not the program terminate with an error from fuse after intercepting the error from the kernel? No matter what names and minor numbers you specify, the problem will be still the same whenever the major number is 81: no device nodes will be created. It's likely that once the "videodev" kernel module is present in memory, it reserves all the possible minor numbers the video4linux subsystem can handle. In facts, to make the example work, first you have to unload the videodev module. Let me know if you need more informations. Thanks in advance. |
From: Miklos S. <mi...@sz...> - 2012-08-29 21:21:12
|
Luca Risolia <luc...@st...> writes: > Hello, > > I have installed libfuse 2.9.1 under Linux. The version of the kernel is > 3.2.0. > > If the "videodev" kernel module is present in memory, when I run the > cusexmp example under fuse-2.9.1/example with the following options, the > specified device node is never created, although from the output > everything seems okay: > > # modprobe cuse (required) > fuse-2.9.1/example$ ./cusexmp -d --maj=81 --min=0 -f --name=video0 > > FUSE library version: 2.9.1 > unique: 1, opcode: CUSE_INIT (4096), nodeid: 0, insize: 56, pid: 8007 > CUSE_INIT: 7.17 > flags=0x00000001 > CUSE_INIT: 7.19 > flags=0x00000001 > max_read=0x00020000 > max_write=0x00020000 > dev_major=81 > dev_minor=0 > dev_info: DEVNAME=video0 > unique: 1, success, outsize: 103 > > While the output from the kernel is > > CUSE: failed to register chrdev region > > Note the "success" word at the end of the output from fuse, although no > /dev/video0 is really created and the program does not exit with an error. > > I would like to know if that is a bug. Should not the program terminate > with an error from fuse after intercepting the error from the kernel? Yes, it should. This (untested) patch should fix it. Thanks, Miklos diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c index 3426521..58fb7c3 100644 --- a/fs/fuse/cuse.c +++ b/fs/fuse/cuse.c @@ -396,7 +396,7 @@ err_device: err_region: unregister_chrdev_region(devt, 1); err: - fc->conn_error = 1; + fuse_conn_kill(fc); goto out; } |
From: Luca R. <luc...@st...> - 2012-08-30 00:34:27
|
On 29/08/2012 23:20, Miklos Szeredi wrote: > Luca Risolia <luc...@st...> writes: >> I would like to know if that is a bug. Should not the program terminate >> with an error from fuse after intercepting the error from the kernel? > > Yes, it should. > > This (untested) patch should fix it. > diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c > index 3426521..58fb7c3 100644 > --- a/fs/fuse/cuse.c > +++ b/fs/fuse/cuse.c > @@ -396,7 +396,7 @@ err_device: > err_region: > unregister_chrdev_region(devt, 1); > err: > - fc->conn_error = 1; > + fuse_conn_kill(fc); > goto out; > } I have applied your change to my current kernel sources (3.2.0), but now I get a kernel failure when running the cuse example: [ 153.590658] Linux video capture interface: v2.00 [ 160.973828] CUSE: failed to register chrdev region --- [ 160.974132] general protection fault: 0000 [#1] SMP [ 160.974182] CPU 1 [ 160.974196] Modules linked in: videodev v4l2_compat_ioctl32 cuse(O) parport_pc rfcomm ppdev bnep joydev snd_usb_audio binfmt_misc snd_hda_codec_idt snd_usbmidi_lib dell_wmi sparse_keymap dell_laptop dcdbas psmouse snd_hda_intel snd_hda_codec snd_hwdep snd_pcm r592 memstick snd_seq_midi snd_rawmidi r852 sm_common nand nand_ids mtd nand_bch bch nand_ecc snd_seq_midi_event arc4 btusb serio_raw snd_seq bluetooth snd_timer snd_seq_device i915 iwl3945 iwl_legacy mac80211 drm_kms_helper drm i2c_algo_bit mac_hid snd cfg80211 wmi soundcore video snd_page_alloc lp parport usbhid hid firewire_ohci firewire_core crc_itu_t b44 ssb sdhci_pci sdhci [last unloaded: v4l2_compat_ioctl32] [ 160.974740] [ 160.974752] Pid: 2233, comm: lt-cusexmp Tainted: G O 3.2.0-29-generic #46-Ubuntu Dell Inc. MM061 /0KD882 [ 160.974832] RIP: 0010:[<ffffffff812831e2>] [<ffffffff812831e2>] fuse_conn_kill+0xb2/0x100 [ 160.974888] RSP: 0018:ffff8800a6ddbe78 EFLAGS: 00010246 [ 160.974920] RAX: dead000000200200 RBX: ffff8800b6512010 RCX: 0000000000000000 [ 160.974960] RDX: dead000000100100 RSI: dead000000100100 RDI: dead000000200200 [ 160.975000] RBP: ffff8800a6ddbe88 R08: 0000000000000000 R09: 0000000000000000 [ 160.975039] R10: ffff8800a6d1c610 R11: 0000000000000293 R12: ffff8800a6d1c600 [ 160.975079] R13: ffff8800ab2b76d0 R14: ffff8800ab2b76d0 R15: ffff8800ab2b76d0 [ 160.975119] FS: 00007fb295faf700(0000) GS:ffff8800cf500000(0000) knlGS:0000000000000000 [ 160.975165] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 160.975198] CR2: 00007f09c36a99b8 CR3: 00000000b668f000 CR4: 00000000000006e0 [ 160.975238] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 160.975278] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 160.975318] Process lt-cusexmp (pid: 2233, threadinfo ffff8800a6dda000, task ffff8800b37c5c00) [ 160.975365] Stack: [ 160.975379] ffff8800b6512010 ffff8800a6d1c600 ffff8800a6ddbeb8 ffffffffa028b109 [ 160.975434] 0000000000000008 ffff8800a6d1c600 0000000000000008 ffff8800af86e900 [ 160.975489] ffff8800a6ddbf08 ffffffff81178f1e ffff8800a6d1c610 ffff8800c6c75d00 [ 160.975545] Call Trace: [ 160.975566] [<ffffffffa028b109>] cuse_channel_release+0x99/0xc0 [cuse] [ 160.975607] [<ffffffff81178f1e>] __fput+0xbe/0x210 [ 160.975636] [<ffffffff81179095>] fput+0x25/0x30 [ 160.975666] [<ffffffff81175c76>] filp_close+0x66/0x90 [ 160.975697] [<ffffffff81175d52>] sys_close+0xb2/0x120 [ 160.975731] [<ffffffff81661ec2>] system_call_fastpath+0x16/0x1b [ 160.975766] Code: 40 99 c5 81 e8 00 52 3d 00 48 8b 93 d0 03 00 00 48 8b 83 d8 03 00 00 48 be 00 01 10 00 00 00 ad de 48 bf 00 02 20 00 00 00 ad de <48> 89 42 08 48 89 10 48 89 b3 d0 03 00 00 48 89 bb d8 03 00 00 [ 160.976146] RIP [<ffffffff812831e2>] fuse_conn_kill+0xb2/0x100 [ 160.976192] RSP <ffff8800a6ddbe78> [ 161.003425] ---[ end trace d38996cd9fa76ce2 ]--- Thanks |
From: Miklos S. <mi...@sz...> - 2012-08-30 16:26:22
|
Luca Risolia <luc...@st...> writes: > On 29/08/2012 23:20, Miklos Szeredi wrote: >> Luca Risolia <luc...@st...> writes: >>> I would like to know if that is a bug. Should not the program terminate >>> with an error from fuse after intercepting the error from the kernel? >> >> Yes, it should. >> >> This (untested) patch should fix it. > >> diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c >> index 3426521..58fb7c3 100644 >> --- a/fs/fuse/cuse.c >> +++ b/fs/fuse/cuse.c >> @@ -396,7 +396,7 @@ err_device: >> err_region: >> unregister_chrdev_region(devt, 1); >> err: >> - fc->conn_error = 1; >> + fuse_conn_kill(fc); >> goto out; >> } > > I have applied your change to my current kernel sources (3.2.0), but > now I get a kernel failure when running the cuse example: Thanks for the report. There were, it seems, more problems in this area. The following patch should be better, tested this time. There's still no message on the terminal about the failure reason, only a kernel message. Thanks, Miklos diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c index 3426521..ee8d550 100644 --- a/fs/fuse/cuse.c +++ b/fs/fuse/cuse.c @@ -396,7 +396,7 @@ err_device: err_region: unregister_chrdev_region(devt, 1); err: - fc->conn_error = 1; + fuse_conn_kill(fc); goto out; } @@ -532,8 +532,6 @@ static int cuse_channel_release(struct inode *inode, struct file *file) cdev_del(cc->cdev); } - /* kill connection and shutdown channel */ - fuse_conn_kill(&cc->fc); rc = fuse_dev_release(inode, file); /* puts the base reference */ return rc; diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c index ce0a283..fca222d 100644 --- a/fs/fuse/inode.c +++ b/fs/fuse/inode.c @@ -367,11 +367,6 @@ void fuse_conn_kill(struct fuse_conn *fc) wake_up_all(&fc->waitq); wake_up_all(&fc->blocked_waitq); wake_up_all(&fc->reserved_req_waitq); - mutex_lock(&fuse_mutex); - list_del(&fc->entry); - fuse_ctl_remove_conn(fc); - mutex_unlock(&fuse_mutex); - fuse_bdi_destroy(fc); } EXPORT_SYMBOL_GPL(fuse_conn_kill); @@ -380,7 +375,14 @@ static void fuse_put_super(struct super_block *sb) struct fuse_conn *fc = get_fuse_conn_super(sb); fuse_send_destroy(fc); + fuse_conn_kill(fc); + mutex_lock(&fuse_mutex); + list_del(&fc->entry); + fuse_ctl_remove_conn(fc); + mutex_unlock(&fuse_mutex); + fuse_bdi_destroy(fc); + fuse_conn_put(fc); } |
From: Luca R. <luc...@st...> - 2012-08-30 17:35:01
|
On 30/08/2012 18:27, Miklos Szeredi wrote: > The following patch should be better, tested this time. It works. Will you also submit the bugfix to the mainline kernel? Thanks you very much. > diff --git a/fs/fuse/cuse.c b/fs/fuse/cuse.c > index 3426521..ee8d550 100644 > --- a/fs/fuse/cuse.c > +++ b/fs/fuse/cuse.c > @@ -396,7 +396,7 @@ err_device: > err_region: > unregister_chrdev_region(devt, 1); > err: > - fc->conn_error = 1; > + fuse_conn_kill(fc); > goto out; > } > > @@ -532,8 +532,6 @@ static int cuse_channel_release(struct inode *inode, struct file *file) > cdev_del(cc->cdev); > } > > - /* kill connection and shutdown channel */ > - fuse_conn_kill(&cc->fc); > rc = fuse_dev_release(inode, file); /* puts the base reference */ > > return rc; > diff --git a/fs/fuse/inode.c b/fs/fuse/inode.c > index ce0a283..fca222d 100644 > --- a/fs/fuse/inode.c > +++ b/fs/fuse/inode.c > @@ -367,11 +367,6 @@ void fuse_conn_kill(struct fuse_conn *fc) > wake_up_all(&fc->waitq); > wake_up_all(&fc->blocked_waitq); > wake_up_all(&fc->reserved_req_waitq); > - mutex_lock(&fuse_mutex); > - list_del(&fc->entry); > - fuse_ctl_remove_conn(fc); > - mutex_unlock(&fuse_mutex); > - fuse_bdi_destroy(fc); > } > EXPORT_SYMBOL_GPL(fuse_conn_kill); > > @@ -380,7 +375,14 @@ static void fuse_put_super(struct super_block *sb) > struct fuse_conn *fc = get_fuse_conn_super(sb); > > fuse_send_destroy(fc); > + > fuse_conn_kill(fc); > + mutex_lock(&fuse_mutex); > + list_del(&fc->entry); > + fuse_ctl_remove_conn(fc); > + mutex_unlock(&fuse_mutex); > + fuse_bdi_destroy(fc); > + > fuse_conn_put(fc); > } > > |
From: Miklos S. <mi...@sz...> - 2012-08-30 18:05:06
|
Luca Risolia <luc...@st...> writes: > On 30/08/2012 18:27, Miklos Szeredi wrote: >> The following patch should be better, tested this time. > > It works. Will you also submit the bugfix to the mainline kernel? Yes, fixes pushed to: git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-linus Thanks, Miklos |