From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f72.google.com (mail-pg0-f72.google.com [74.125.83.72]) by kanga.kvack.org (Postfix) with ESMTP id 4F38E6B02C3 for ; Thu, 10 Aug 2017 04:28:03 -0400 (EDT) Received: by mail-pg0-f72.google.com with SMTP id t80so760312pgb.0 for ; Thu, 10 Aug 2017 01:28:03 -0700 (PDT) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com. [148.163.156.1]) by mx.google.com with ESMTPS id 189si3811237pfc.500.2017.08.10.01.28.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 01:28:02 -0700 (PDT) Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7A8R3aT138171 for ; Thu, 10 Aug 2017 04:28:01 -0400 Received: from e06smtp14.uk.ibm.com (e06smtp14.uk.ibm.com [195.75.94.110]) by mx0a-001b2d01.pphosted.com with ESMTP id 2c8hdv81v6-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 10 Aug 2017 04:28:01 -0400 Received: from localhost by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 10 Aug 2017 09:27:58 +0100 Subject: Re: [PATCH 05/16] mm: Protect VMA modifications using VMA sequence count References: <1502202949-8138-1-git-send-email-ldufour@linux.vnet.ibm.com> <1502202949-8138-6-git-send-email-ldufour@linux.vnet.ibm.com> <20170809101241.ek4fqinqaq5qfkq4@node.shutemov.name> <20170810005828.qmw3p7d676hjwkss@node.shutemov.name> From: Laurent Dufour Date: Thu, 10 Aug 2017 10:27:50 +0200 MIME-Version: 1.0 In-Reply-To: <20170810005828.qmw3p7d676hjwkss@node.shutemov.name> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Message-Id: <4e552377-af38-3580-73b6-1edf685cb90d@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: "Kirill A. Shutemov" Cc: paulmck@linux.vnet.ibm.com, peterz@infradead.org, akpm@linux-foundation.org, ak@linux.intel.com, mhocko@kernel.org, dave@stgolabs.net, jack@suse.cz, Matthew Wilcox , benh@kernel.crashing.org, mpe@ellerman.id.au, paulus@samba.org, Thomas Gleixner , Ingo Molnar , hpa@zytor.com, Will Deacon , linux-kernel@vger.kernel.org, linux-mm@kvack.org, haren@linux.vnet.ibm.com, khandual@linux.vnet.ibm.com, npiggin@gmail.com, bsingharora@gmail.com, Tim Chen , linuxppc-dev@lists.ozlabs.org, x86@kernel.org 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org