On 27/11/2017 16:06, Peter Maydell wrote:
> On 27 November 2017 at 15:53, Paolo Bonzini 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 la
On 27 November 2017 at 15:53, Paolo Bonzini 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
>> se
On 27/11/2017 15:47, Peter Maydell wrote:
> On 27 November 2017 at 15:38, Paolo Bonzini wrote:
>> On 24/11/2017 18:18, Peter Maydell wrote:
>>> * threads A & B both try to do a write to a page with code in it at
>>>the same time (ie which we've made non-writeable, so SEGV)
>>> * they race in
On 27 November 2017 at 15:38, Paolo Bonzini wrote:
> On 24/11/2017 18:18, Peter Maydell wrote:
>> * threads A & B both try to do a write to a page with code in it at
>>the same time (ie which we've made non-writeable, so SEGV)
>> * they race into the signal handler with this faulting address
On 24/11/2017 18:18, Peter Maydell wrote:
> * threads A & B both try to do a write to a page with code in it at
>the same time (ie which we've made non-writeable, so SEGV)
> * they race into the signal handler with this faulting address
> * thread A happens to get to page_unprotect() first a
I managed to track down the crash running javac in user-mode
emulation. The problem is that we can have several threads which
race in page_unprotect():
* threads A & B both try to do a write to a page with code in it at
the same time (ie which we've made non-writeable, so SEGV)
* they race in
