On 24/02/15 14:36, Richard W.M. Jones wrote: > On Tue, Feb 24, 2015 at 02:10:28PM +0000, Marc Zyngier wrote: >> On 24/02/15 13:45, Richard W.M. Jones wrote: >>> On Tue, Feb 24, 2015 at 01:12:49PM +0000, Marc Zyngier wrote: >>>> Here's my theory: userspace is accessing something it should never >>>> access (outside of RAM, basically), and doing so via a kernel interface. >>>> >>>> Is this process accessing /dev/mem by any chance? dmidecode anyone? >>> >>> Not as far as I know. The userspace process is inserting modules. >>> >>> Here is the userspace function which is most likely to be running: >>> >>> https://github.com/libguestfs/supermin/blob/master/src/init.c#L292 >> >> Hmmm. That seems quite inoffensive indeed... >> >>> Unfortunately because of lack of a full stack trace, I can't be sure >>> exactly what system call is failing, but I'll probably add more debug >>> to the userspace program later. >>> >>> BTW this worked fine in 3.19. It's started failing in 3.20/4.0. It >>> also works fine on x86. >> >> Any chance you could find out whether that's a host or guest regression? > > Here is a summary of the test combinations that I have run: > > guest kernel host kernel result > -------------------------------------------------------- > 3.19.0-0.rc7 3.19.0-0.rc7 no bug seen > > 3.20.0-0.rc0 3.19.0-0.rc7 bug seen > > 3.19.0-0.rc7 4.0.0-0.rc1 no bug seen > > 4.0.0-0.rc1 4.0.0-0.rc1 bug seen > > So a guest regression, I think? Looks like it. Is your .config stashed somewhere? I'd like to give it a go on my own setup... > It's also possible the bug existed in old kernels but was masked > somehow, eg. different memory layout. > > 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. That'd be interesting indeed. M. -- Jazz is not dead. It just smells funny... _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
