On 24/02/15 15:09, Richard W.M. Jones wrote: >> On 24/02/15 14:36, Richard W.M. Jones wrote: >>> I can probably bisect this given time, but I'm going to try putting >>> some debug into the userspace process to find out which system call >>> fails first. > > Perhaps not surprisingly, it's the init_module syscall which causes > the failure, ie. this line of code: > > https://github.com/libguestfs/supermin/blob/master/src/init.c#L436 > > I've no idea why that code would call copy_to_user. It should be > copying the other way ... > > It also fails on the first call to init_module, so the fact that it's > loading crc32-arm64.ko may just be a coincidence. > > There are no other userspace processes running, but just to be sure > that it's not some other process in the guest, I also added a sleep > before the call to init_module, but same result as above. > > I also looked at the implementation of init_module in glibc, but > AFAICT init_module is a straight syscall and glibc is not involved. > > I also looked to see if I was calling init_module correctly on aarch64 > (in case it has a different # of arguments of something) but it's > called in the same way in the libkmod code, so I think we're OK. > > Next up, I will have a go at bisecting the guest kernel. Patch posted there: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/325445.html M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
