From: Stef B. <st...@gm...> - 2014-03-19 20:29:34
|
Hi, I'm trying to make fsnotify work with fuse. See earlier posts. I'm struggling to see how to send a request to userspace. Now I have the function which sends to userspace: void fuse_send_fsnotify_mark(struct inode *inode) { struct fuse_conn *fc = get_fuse_conn(inode); struct fuse_inode *fi = get_fuse_inode(inode); if (fc) { struct fuse_req *req=fuse_get_req_nopages(fc); if (! IS_ERR(req) ) { struct fuse_fsnotify_in inarg; memset(&inarg, 0, sizeof(inarg)); inarg.mask = inode->i_fsnotify_mask; req->in.h.opcode = FUSE_FSNOTIFY; req->in.h.nodeid = fi->nodeid; req->in.numargs = 1; req->in.args[0].size = sizeof(inarg); req->in.args[0].value = &inarg; req->isreply = 0; req->background = 0; printk(KERN_INFO "fuse_send_fsnotify_mark: mask %i\n", inode->i_fsnotify_mask); fuse_request_send(fc, req); fuse_put_request(fc, req); } } } where: FUSE_FSNOTIFY = 45 (first free one) and struct fuse_fsnotify_in { uint64_t mask; } This leads to kernel BUGS: Mar 19 13:24:15 localhost kernel: fuse_send_fsnotify_mark: mask 134262783 Mar 19 13:24:15 localhost kernel: BUG: scheduling while atomic: inotifywait/11722/0x00000003 Mar 19 13:24:15 localhost kernel: Modules linked in: xt_conntrack iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat ip Mar 19 13:24:15 localhost kernel: CPU: 4 PID: 11722 Comm: inotifywait Not tainted 3.14.0-rc6+ #6 Mar 19 13:24:15 localhost kernel: Hardware name: System manufacturer System Product Name/SABERTOOTH X58, BIOS 0702 11/16/2010 Mar 19 13:24:15 localhost kernel: 00000004 c153af56 f7bc2240 c1538c04 c15dc768 e607cdc8 00002dca 00000003 Mar 19 13:24:15 localhost kernel: c153cbcd 00000001 00000000 c1068e56 c1751240 c1751240 e589d740 00000000 Mar 19 13:24:15 localhost kernel: e589d720 f7223500 00000000 00000046 c1068e97 00000000 00000046 c11312c1 Mar 19 13:24:15 localhost kernel: Call Trace: Mar 19 13:24:15 localhost kernel: [<c153af56>] ? 0xc153af56 Mar 19 13:24:15 localhost kernel: [<c1538c04>] ? 0xc1538c04 Mar 19 13:24:15 localhost kernel: [<c153cbcd>] ? 0xc153cbcd Mar 19 13:24:15 localhost kernel: [<c1068e56>] ? 0xc1068e56 Mar 19 13:24:15 localhost kernel: [<c1068e97>] ? 0xc1068e97 Mar 19 13:24:15 localhost kernel: [<c11312c1>] ? 0xc11312c1 Mar 19 13:24:15 localhost kernel: [<c1068e56>] ? 0xc1068e56 Mar 19 13:24:15 localhost kernel: [<c1069300>] ? 0xc1069300 Mar 19 13:24:15 localhost kernel: [<c1218611>] ? 0xc1218611 Mar 19 13:24:15 localhost kernel: [<c1069360>] ? 0xc1069360 Mar 19 13:24:15 localhost kernel: [<c12189c1>] ? 0xc12189c1 Mar 19 13:24:15 localhost kernel: [<c1538e91>] ? 0xc1538e91 Mar 19 13:24:15 localhost kernel: [<c121ba20>] ? 0xc121ba20 Mar 19 13:24:15 localhost kernel: [<c112d7e2>] ? 0xc112d7e2 Mar 19 13:24:15 localhost kernel: [<c112dcd6>] ? 0xc112dcd6 Mar 19 13:24:15 localhost kernel: [<c112f297>] ? 0xc112f297 Mar 19 13:24:15 localhost kernel: [<c154017e>] ? 0xc154017e So this is not good. I've tried also: void fuse_send_fsnotify_mark(struct inode *inode) { struct fuse_conn *fc = get_fuse_conn(inode); struct fuse_inode *fi = get_fuse_inode(inode); if (fc) { struct fuse_req *req=fuse_get_req_nopages(fc); if (! IS_ERR(req) ) { struct fuse_fsnotify_in inarg; memset(&inarg, 0, sizeof(inarg)); inarg.mask = inode->i_fsnotify_mask; req->in.h.opcode = FUSE_FSNOTIFY; req->in.h.nodeid = fi->nodeid; req->in.numargs = 1; req->in.args[0].size = sizeof(inarg); req->in.args[0].value = &inarg; req->isreply = 0; req->background = 1; printk(KERN_INFO "fuse_send_fsnotify_mark: mask %i\n", inode->i_fsnotify_mask); fuse_request_send_nowait(fc, req); } } } (note: here the function fuse_request_send_nowait is used) But this leads to incorrect values of the mask received by the userspace. What is the best function? Note that this function does not require a reply. Stef Bon |
From: Brian F. <bf...@re...> - 2014-03-20 14:28:31
|
On Wed, Mar 19, 2014 at 09:29:27PM +0100, Stef Bon wrote: > Hi, > > I'm trying to make fsnotify work with fuse. See earlier posts. > > I'm struggling to see how to send a request to userspace. > > Now I have the function which sends to userspace: > > void fuse_send_fsnotify_mark(struct inode *inode) > { > struct fuse_conn *fc = get_fuse_conn(inode); > struct fuse_inode *fi = get_fuse_inode(inode); > > if (fc) { > struct fuse_req *req=fuse_get_req_nopages(fc); > > if (! IS_ERR(req) ) { > struct fuse_fsnotify_in inarg; > > memset(&inarg, 0, sizeof(inarg)); > inarg.mask = inode->i_fsnotify_mask; > > req->in.h.opcode = FUSE_FSNOTIFY; > req->in.h.nodeid = fi->nodeid; > req->in.numargs = 1; > req->in.args[0].size = sizeof(inarg); > req->in.args[0].value = &inarg; > req->isreply = 0; > req->background = 0; > > printk(KERN_INFO "fuse_send_fsnotify_mark: mask %i\n", > inode->i_fsnotify_mask); > > fuse_request_send(fc, req); > > fuse_put_request(fc, req); > > } > > } > > } > > where: > > FUSE_FSNOTIFY = 45 (first free one) > and > > struct fuse_fsnotify_in { > uint64_t mask; > } > > This leads to kernel BUGS: > > Mar 19 13:24:15 localhost kernel: fuse_send_fsnotify_mark: mask 134262783 > Mar 19 13:24:15 localhost kernel: BUG: scheduling while atomic: > inotifywait/11722/0x00000003 > Mar 19 13:24:15 localhost kernel: Modules linked in: xt_conntrack > iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat ip > Mar 19 13:24:15 localhost kernel: CPU: 4 PID: 11722 Comm: inotifywait > Not tainted 3.14.0-rc6+ #6 > Mar 19 13:24:15 localhost kernel: Hardware name: System manufacturer > System Product Name/SABERTOOTH X58, BIOS 0702 11/16/2010 > Mar 19 13:24:15 localhost kernel: 00000004 c153af56 f7bc2240 c1538c04 > c15dc768 e607cdc8 00002dca 00000003 > Mar 19 13:24:15 localhost kernel: c153cbcd 00000001 00000000 c1068e56 > c1751240 c1751240 e589d740 00000000 > Mar 19 13:24:15 localhost kernel: e589d720 f7223500 00000000 00000046 > c1068e97 00000000 00000046 c11312c1 > Mar 19 13:24:15 localhost kernel: Call Trace: > Mar 19 13:24:15 localhost kernel: [<c153af56>] ? 0xc153af56 > Mar 19 13:24:15 localhost kernel: [<c1538c04>] ? 0xc1538c04 > Mar 19 13:24:15 localhost kernel: [<c153cbcd>] ? 0xc153cbcd > Mar 19 13:24:15 localhost kernel: [<c1068e56>] ? 0xc1068e56 > Mar 19 13:24:15 localhost kernel: [<c1068e97>] ? 0xc1068e97 > Mar 19 13:24:15 localhost kernel: [<c11312c1>] ? 0xc11312c1 > Mar 19 13:24:15 localhost kernel: [<c1068e56>] ? 0xc1068e56 > Mar 19 13:24:15 localhost kernel: [<c1069300>] ? 0xc1069300 > Mar 19 13:24:15 localhost kernel: [<c1218611>] ? 0xc1218611 > Mar 19 13:24:15 localhost kernel: [<c1069360>] ? 0xc1069360 > Mar 19 13:24:15 localhost kernel: [<c12189c1>] ? 0xc12189c1 > Mar 19 13:24:15 localhost kernel: [<c1538e91>] ? 0xc1538e91 > Mar 19 13:24:15 localhost kernel: [<c121ba20>] ? 0xc121ba20 > Mar 19 13:24:15 localhost kernel: [<c112d7e2>] ? 0xc112d7e2 > Mar 19 13:24:15 localhost kernel: [<c112dcd6>] ? 0xc112dcd6 > Mar 19 13:24:15 localhost kernel: [<c112f297>] ? 0xc112f297 > Mar 19 13:24:15 localhost kernel: [<c154017e>] ? 0xc154017e > I couldn't say why this happens. But it might be hard for others to comment as well without posting the full context in the form of a patch. > So this is not good. I've tried also: > > void fuse_send_fsnotify_mark(struct inode *inode) > { > struct fuse_conn *fc = get_fuse_conn(inode); > struct fuse_inode *fi = get_fuse_inode(inode); > > if (fc) { > struct fuse_req *req=fuse_get_req_nopages(fc); > > if (! IS_ERR(req) ) { > struct fuse_fsnotify_in inarg; > > memset(&inarg, 0, sizeof(inarg)); > inarg.mask = inode->i_fsnotify_mask; > > req->in.h.opcode = FUSE_FSNOTIFY; > req->in.h.nodeid = fi->nodeid; > req->in.numargs = 1; > req->in.args[0].size = sizeof(inarg); > req->in.args[0].value = &inarg; > req->isreply = 0; > req->background = 1; > > printk(KERN_INFO "fuse_send_fsnotify_mark: mask %i\n", > inode->i_fsnotify_mask); > > fuse_request_send_nowait(fc, req); > > } > > } > > } > > (note: here the function fuse_request_send_nowait is used) > > But this leads to incorrect values of the mask received by the > userspace. What is the best function? > Note that this function does not require a reply. > You pointed out in the other thread that you had conflicting types. Had you tested whether resolving that changes anything? I also pointed out you're sending an async request using data on the stack. In other words, if you follow fuse_request_send_nowait(), you'll see it eventually puts the request on a list to be handled later. The argument for this request is on the current stack and becomes "invalid" once the function returns, however. So by the time the request is actually sent to userspace, who knows what argument data the request points to. If you look into some of the other usages of fuse_request_send_nowait(), you'll see that they will use argument structures that are embedded into the request itself (req->misc) to deal with this. Brian > Stef Bon > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/13534_NeoTech > _______________________________________________ > fuse-devel mailing list > fus...@li... > https://lists.sourceforge.net/lists/listinfo/fuse-devel |
From: Stef B. <st...@gm...> - 2014-03-23 13:52:05
|
2014-03-20 15:28 GMT+01:00 Brian Foster <bf...@re...>: > On Wed, Mar 19, 2014 at 09:29:27PM +0100, Stef Bon wrote: >> Hi, >> >> Mar 19 13:24:15 localhost kernel: [<c112dcd6>] ? 0xc112dcd6 >> Mar 19 13:24:15 localhost kernel: [<c112f297>] ? 0xc112f297 >> Mar 19 13:24:15 localhost kernel: [<c154017e>] ? 0xc154017e >> > > I couldn't say why this happens. But it might be hard for others to > comment as well without posting the full context in the form of a patch. > Well I thought that there enough developers present on the dev maillist who know howto deal with sending a nopriority no reply message. >> But this leads to incorrect values of the mask received by the >> userspace. What is the best function? >> Note that this function does not require a reply. >> > > You pointed out in the other thread that you had conflicting types. Had > you tested whether resolving that changes anything? > Yes I've tried before. That did not make a difference. > I also pointed out you're sending an async request using data on the > stack. In other words, if you follow fuse_request_send_nowait(), you'll > see it eventually puts the request on a list to be handled later. The > argument for this request is on the current stack and becomes "invalid" > once the function returns, however. So by the time the request is > actually sent to userspace, who knows what argument data the request > points to. > > If you look into some of the other usages of fuse_request_send_nowait(), > you'll see that they will use argument structures that are embedded into > the request itself (req->misc) to deal with this. Ok I'll check that. Thanks Stef Bon |
From: Stef B. <st...@gm...> - 2014-03-24 11:13:50
|
We'll your suggestion about using the req->misc field worked. I did not understand directly what meant, but of course the locally declared struct fsnotify_in is not valid anymore when the req is processed, which will be probably later when put on a queue. I've added an extra field to the union misc fsnotify_in, and made req->in point to that. Now it works. An extra notion, the removal of an file (like /tmp/somefile) while the overlaysfs simpleoverlayfs is watching /tmp because a watch has been set on ~/Mount/tmp works also as expected. The adding of a file does not work yet also as expected. Thanks for suggestions, Stef Bon Voorburg (near The Hague, where the nuclear security sunmmit is right now, nobody can do a thing here) |