Re: [Qemu-devel] javac crash in user-mode emulation: races on page_unprotect()

[Paolo Bonzini <pbonzini@redhat.com>]

On 27/11/2017 16:06, Peter Maydell wrote:
> On 27 November 2017 at 15:53, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> On 27/11/2017 15:47, Peter Maydell wrote:
>>> I have a patch from rth based on an idea he and I came up with:
>>> we add a field to the PageDesc struct to store the thread id of
>>> the thread that last touches the flags. If you come into the
>>> segv handler and the page flags/last-modified-by field say "should be
>>> writeable and somebody else updated it" then you mark the page as
>>> "last modified by this thread" and retry the access. If the
>>> flags say "should be writeable, last modified by this thread"
>>> then you know the page state hasn't changed since this thread
>>> last saw it as "definitely not causing segvs because of cached TBs",
>>> and so that should be passed on as a guest SEGV.
>> Clever, but why would si_code not work?...
> Do we have a guarantee that it's absolutely never the case that
> you can get a SEGV with si_code SEGV_ACCERR for an access to memory
> that's mapped writeable (and conversely that we'll always get
> SEGV_ACCERR for the "mapped nonwriteable" case)? If it's ever possible
> then the guest will go into an infinite loop of taking segfaults that
> should be delivered to the guest but which we just retry the failing
> access for forever...

At least for x86, yes.

For ARM, the syndrome values that trigger SEGV_ACCERR are 9-11 and
13-15, which seems sane to me but I know much less about ARM than x86.

So I would say "yes except for kernel bugs".

Paolo