> On Jan 9, 2021, at 12:17 PM, ebied...@xmission.com wrote:
>
> Andy Lutomirski writes:
>
>> The implementation was rather buggy. It unconditionally marked PTEs
>> read-only, even for VM_SHARED mappings. I'm not sure whether this is
>> actually a problem, but it certainly seems unwise.
Andy Lutomirski writes:
> The implementation was rather buggy. It unconditionally marked PTEs
> read-only, even for VM_SHARED mappings. I'm not sure whether this is
> actually a problem, but it certainly seems unwise. More importantly, it
> released the mmap lock before flushing the TLB,
On Fri, Jan 08, 2021 at 10:55:05AM -0800, Andy Lutomirski wrote:
> The implementation was rather buggy. It unconditionally marked PTEs
> released the mmap lock before flushing the TLB, which could allow a racing
> CoW operation to falsely believe that the underlying memory was not
> writable.
>
Hi Andy,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tip/master]
[also build test WARNING on linux/master linus/master tip/x86/core v5.11-rc2
next-20210108]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
On Fri, Jan 8, 2021 at 1:59 PM Andy Lutomirski wrote:
>
> The implementation was rather buggy. It unconditionally marked PTEs
> read-only, even for VM_SHARED mappings. I'm not sure whether this is
> actually a problem, but it certainly seems unwise. More importantly, it
> released the mmap
On Fri, Jan 8, 2021 at 10:55 AM Andy Lutomirski wrote:
>
> I can't find any users at all of this mechanism, so just remove it.
Ack, as long as it sits in linux-next for a while.
Linus
The implementation was rather buggy. It unconditionally marked PTEs
read-only, even for VM_SHARED mappings. I'm not sure whether this is
actually a problem, but it certainly seems unwise. More importantly, it
released the mmap lock before flushing the TLB, which could allow a racing
CoW
7 matches
Mail list logo
