On Thu, May 28, 2015 at 09:36:55PM +0000, Antti Kantee wrote: > On 28/05/15 20:09, Patrick Welche wrote: > >On Thu, May 28, 2015 at 10:59:52AM +0000, Antti Kantee wrote: > >>On 28/05/15 10:30, Patrick Welche wrote: > >>>I'm having an entertaining time trying to debug vnd by running vnconfig > >>>against a rump kernel. It seems that my HIJACK incantation of a year ago: > >>> > >>> export RUMPHIJACK=path=/rump,blanket=/dev/vnd:/dev/rvnd > >>> > >>>no longer works. The problem seems to be because vnconfig does > >>> > >>>opendisk() want vnd0 -> rump's /dev/rvnd0d > >>>open() want e.g. /tmp/foo.img (works if add /tmp/foo.img to blanket) > >>> in vnconfig vnd0 /tmp/foo.img case > >>>ioctl() usually does run rump's vndioctl if we get that far > >> > >>You need to vnconfig /rump/tmp/foo.img, not /tmp/foo.img. > > > >OK, trying again with > > > >export RUMP_SERVER=unix:///tmp/sock > >export RUMPHIJACK=path=/rump,blanket=/dev/vnd:/dev/rvnd > >export RUMPHIJACK_RETRYCONNECT=inftime > >export LD_PRELOAD=/usr/lib/librumphijack.so > > > >$ dd if=/dev/zero of=/rump/tmp/foo.img count=12000 > >12000+0 records in > >12000+0 records out > >6144000 bytes transferred in 27.818 secs (220864 bytes/sec) > >$ ls -lh /rump/tmp > >total 5.9M > >-rw-r--r-- 1 root wheel 5.9M May 28 20:47 foo.img > >$ vnconfig -l > >vnd0: not in use > >vnd1: not in use > >vnd2: not in use > >vnd3: not in use > >$ vnconfig vnd0 /rump/tmp/foo.img > >vnconfig: /dev/rvnd0d: VNDIOCSET: No such file or directory > > Ah, you're right, you do need to blanket /tmp/foo.img since the path is > passed to syscalls both via opendisk (which I assume uses open() or > something like that) and via ioctl() which just hides the path in some > covert ioctl protocol. Since rumphijack doesn't see inside the ioctl > parameter -- and let's not start teaching hijack about all gazillion ioctl > parameters -- it cannot adjust the path.
In my original hijack.sh, I had /tmp/foo.img in blanket - I see that it is my changes to vnd.c which broke things. Original vnd.c passes the above with the extra /tmp/foo.img. My vnd.c fails with $ vnconfig -l vnconfig: open: vnd0: Unknown error: 32639 As it was a problem with open(), I wrongly assumed I still hadn't got hijack right - now we are exactly where I need to be: debugging vndopen() locking :-) Thank you! > btw, dd in your use case will be a lot faster if you specify bs=1m or so. > 512 bytes is rather small since every call to write() is min 4 full context > switches. Indeed! > >>>To try to avoid needing to solve the correct RUMPHIJACK incantation, I just > >>>tried building a > >>> > >>>RUMPPRG= vnconfig > >... > >>That looks like a missing prog_init(). > > > >Indeed - thanks! And then I get stuck down that avenue as NetBSD gdb > >can't cope with pthread_sigmask as per PR bin/49662, so it seems that > >HIJACK incantation is the only way forward... (or linux gdb I suppose) > > Hijack or not, the syscall path on the client side is exactly the same > (through rumpclient_syscall), so using a different route to get there will > do nothing for solving the problem. Oddly, with original (working) vnd.c, I get $ obj.amd64/rump.vnconfig -l rump.vnconfig: VNDIOCGET: Bad file descriptor > I thought I filed a PR on the subject of gdb+sigprocmask() failing like 4+ > years ago, and I also thought it was fixed. I just tried PR bin/49662 again, and get the 100% CPU usage (takes a couple more "next"s, but it's still alive and kicking) > Why do you want to single-step the syscall path on the client side anyway? > It does practically nothing interesting. What am I missing? I expect rump.vnconfig to connect to RUMP_SERVER and DTRT without the need for hijacking - is that correct? rump.vnconfig gives me an error about VNDIOCGET, so I should expect that a breakpoint in rump_allserver at vndioctl() should fire? I don't see that... (Tracing rump.vnconfig, I do step into rumpclient_init() and it parses RUMP_SERVER correctly, unit fd is now 11, vn_ioctl -> rump__sysimpl_ioctl, rsys_syscall returns an error, and breakpoint in vndioctl doesn't fire) (probably should try again that this really is with the original vnd.c...) Thanks, Patrick
