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
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
