On Mon, 17 Jul 2023 at 19:25, Richard Henderson
wrote:
>
> On 7/17/23 11:12, Peter Maydell wrote:
> > On Sun, 16 Jul 2023 at 18:03, Richard Henderson
> > wrote:
> >>
> >> For user-only, the probe for page writability may race with another
> >> thread's mprotect. Take the mmap_lock around the
Richard Henderson writes:
> On 7/17/23 11:40, Alex Bennée wrote:
>> Richard Henderson writes:
>>
>>> For user-only, the probe for page writability may race with another
>>> thread's mprotect. Take the mmap_lock around the operation. This
>>> is still faster than the start/end_exclusive
On 7/17/23 11:40, Alex Bennée wrote:
Richard Henderson writes:
For user-only, the probe for page writability may race with another
thread's mprotect. Take the mmap_lock around the operation. This
is still faster than the start/end_exclusive fallback.
Did we have a bug report or
On 7/17/23 11:12, Peter Maydell wrote:
On Sun, 16 Jul 2023 at 18:03, Richard Henderson
wrote:
For user-only, the probe for page writability may race with another
thread's mprotect. Take the mmap_lock around the operation. This
is still faster than the start/end_exclusive fallback.
Remove
Richard Henderson writes:
> For user-only, the probe for page writability may race with another
> thread's mprotect. Take the mmap_lock around the operation. This
> is still faster than the start/end_exclusive fallback.
Did we have a bug report or replication for this?
>
> Remove the
On Sun, 16 Jul 2023 at 18:03, Richard Henderson
wrote:
>
> For user-only, the probe for page writability may race with another
> thread's mprotect. Take the mmap_lock around the operation. This
> is still faster than the start/end_exclusive fallback.
>
> Remove the write probe in
For user-only, the probe for page writability may race with another
thread's mprotect. Take the mmap_lock around the operation. This
is still faster than the start/end_exclusive fallback.
Remove the write probe in load_atomic8_or_exit. There we don't have
the same machinery for testing the
