Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1708315

Re: [PATCH 05/16] mm: Protect VMA modifications using VMA sequence count

From Laurent Dufour <ldufour@linux.vnet.ibm.com>
Newsgroups linux.kernel
Subject Re: [PATCH 05/16] mm: Protect VMA modifications using VMA sequence count
Date 2017-08-10 10:30 +0200
Message-ID <ucR0R-2S8-11@gated-at.bofh.it> (permalink)
References <ucdPQ-1fE-5@gated-at.bofh.it> <ucdPR-1fE-43@gated-at.bofh.it> <ucwfM-5MY-25@gated-at.bofh.it> <ucwIN-5WY-7@gated-at.bofh.it> <ucJZn-6H0-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 10/08/2017 02:58, Kirill A. Shutemov wrote:
> On Wed, Aug 09, 2017 at 12:43:33PM +0200, Laurent Dufour wrote:
>> On 09/08/2017 12:12, Kirill A. Shutemov wrote:
>>> On Tue, Aug 08, 2017 at 04:35:38PM +0200, Laurent Dufour wrote:
>>>> The VMA sequence count has been introduced to allow fast detection of
>>>> VMA modification when running a page fault handler without holding
>>>> the mmap_sem.
>>>>
>>>> This patch provides protection agains the VMA modification done in :
>>>> 	- madvise()
>>>> 	- mremap()
>>>> 	- mpol_rebind_policy()
>>>> 	- vma_replace_policy()
>>>> 	- change_prot_numa()
>>>> 	- mlock(), munlock()
>>>> 	- mprotect()
>>>> 	- mmap_region()
>>>> 	- collapse_huge_page()
>>>
>>> I don't thinks it's anywhere near complete list of places where we touch
>>> vm_flags. What is your plan for the rest?
>>
>> The goal is only to protect places where change to the VMA is impacting the
>> page fault handling. If you think I missed one, please advise.
> 
> That's very fragile approach. We rely here too much on specific compiler behaviour.
> 
> Any write access to vm_flags can, in theory, be translated to several
> write accesses. For instance with setting vm_flags to 0 in the middle,
> which would result in sigfault on page fault to the vma.

Indeed, just setting vm_flags to 0 will not result in sigfault, the real
job is done when the pte are updated and the bits allowing access are
cleared. Access to the pte is controlled by the pte lock.
Page fault handler is triggered based on the pte bits, not the content of
vm_flags and the speculative page fault is checking for the vma again once
the pte lock is held. So there is no concurrency when dealing with the pte
bits.

Regarding the compiler behaviour, there are memory barriers and locking
which should prevent that.

Thanks,
Laurent.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH 00/16] Speculative page faults Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-08 16:40 +0200
  [PATCH 08/16] mm: Try spin lock in speculative path Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-08 16:40 +0200
  [PATCH 10/16] powerpc/mm: Add speculative page fault Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-08 16:40 +0200
  [PATCH 05/16] mm: Protect VMA modifications using VMA sequence count Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-08 16:40 +0200
    Re: [PATCH 05/16] mm: Protect VMA modifications using VMA sequence  count "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-08-09 12:20 +0200
      Re: [PATCH 05/16] mm: Protect VMA modifications using VMA sequence  count Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-09 12:50 +0200
        Re: [PATCH 05/16] mm: Protect VMA modifications using VMA sequence  count "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-08-10 03:00 +0200
          Re: [PATCH 05/16] mm: Protect VMA modifications using VMA sequence  count Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-10 10:30 +0200
            Re: [PATCH 05/16] mm: Protect VMA modifications using VMA sequence  count "Kirill A. Shutemov" <kirill@shutemov.name> - 2017-08-10 15:50 +0200
              Re: [PATCH 05/16] mm: Protect VMA modifications using VMA sequence  count Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-10 20:20 +0200
  [PATCH 01/16] mm: Dont assume page-table invariance during faults Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2017-08-08 16:50 +0200

csiph-web