From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60287C32793 for ; Wed, 18 Jan 2023 17:40:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC5236B007B; Wed, 18 Jan 2023 12:40:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E75596B007D; Wed, 18 Jan 2023 12:40:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D15A26B0082; Wed, 18 Jan 2023 12:40:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BF3316B007B for ; Wed, 18 Jan 2023 12:40:51 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8A8F7C0C4A for ; Wed, 18 Jan 2023 17:40:51 +0000 (UTC) X-FDA: 80368635102.12.64A6961 Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) by imf18.hostedemail.com (Postfix) with ESMTP id 11E3D1C0014 for ; Wed, 18 Jan 2023 17:40:49 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Ka6nVunr; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674063650; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=O+c3praop+F4hgZx9fYsgBqwRZyACPImTP4EJ0i5h+4=; b=1TRaZBUCeKnc1ZVZE1v1AsGSEsWCKob51vmB8DPrPUF4Tf9WpG3xJjK7F82jGZcD3F1rD3 ORuUogED7iPpFjg3qTqJmuCy1cs9M3HpdisJaY0FCUgVWzAAmyjuaF5B+Lc2W/akGQz4Ki hIqxx4gH+ifi4Cz1WSDc5pOcQlh3GJk= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Ka6nVunr; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.219.175 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674063650; a=rsa-sha256; cv=none; b=Ttmykip/F8sHN2uY9rkCyG6rZgGGTtDzs+hDdkA/NubFjMwmwIqx8q2hd8ZKDmv91yONVo H7z/Icpvu6XR8qDA2Nn9GiReUkKsKnvXJ26ccf2fyX9nt/eHTNekorCzKK5iyWSFb0selc jhJ7rjuy+5hjyfQj/vMaViRP4nxvRUs= Received: by mail-yb1-f175.google.com with SMTP id e202so15669734ybh.11 for ; Wed, 18 Jan 2023 09:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=O+c3praop+F4hgZx9fYsgBqwRZyACPImTP4EJ0i5h+4=; b=Ka6nVunrhz4AtVb4ez9bPbZMrA+BT0HLYjQWV2A83Am/7vZHMnwaJyxrzb3BG1Ge4V jClzWXorirsqV3khCBOP4ggO2Tn0WG07oU9lIclP9VHGeoB6qrpZtnGhe7bo/ttx6zDC TMjP/ThYyG7YcvLasV/vCtOVTAZsP1RDT6VNGtA88feNmFKy0+OV9yXL+HJ0AxWhqfSt pSmnW0q7C+E7rigeF6haineNjehNr7CNxIMAgv0g5lIonW0kqwLOFL/u5eriUgrmlkcF 2HtNHfIc9raNIqPYMX6fhNH4Ttqpzmn1gyvx4VhRfWtC7xh2fn/uQa3Wc5QgHD/pyLWB Ygag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=O+c3praop+F4hgZx9fYsgBqwRZyACPImTP4EJ0i5h+4=; b=3URtc5BR7dGTle3p9iuQPWr1jKkFJFLKVTd7UCnzNCW/9ChRX60A0fQjNP9qVXob0D Glr3MBqrsBghP94INeVYq/bTxuo3rQlySDDuHI1hvs9LL6fTn80CB3knZ26aBKliFmwj ojATqaqzcph7Mr7RvpFRo0pvTdQHB8eEIb8H0psf4Z6hzOt6Bt/o0aHP3Xy48h42+GjB /D+OiG4u/RQiBzBHkQsUbQaIoK4GAvirh6BKvyYzZ48YkWbA34a48whCrpVAgNn3u0tW lN7J8tw/VBQdod6oWJ0vjxSn3bdLYMl4laWdMFtDHD+J3qgyvdSjEhvDfLpTHDCEia9Z GtgQ== X-Gm-Message-State: AFqh2kqQs6U0dIqrgCpiZqGJfoD8uAy0Baq8j8EGYGL1ADI/mCP25a3d 7dDnbJS/HVO0Jh9b1xJtQw+IRz4qd7fnKZycw1lf9g== X-Google-Smtp-Source: AMrXdXs1k5W3HoVGCiUVOI7jTqOyluR9eRrHzCwGnTn1al/nkArE3wLdMkVcHMHmAcyunh8GSfVeJdebmQPCKJ8WsTw= X-Received: by 2002:a05:6902:685:b0:7e9:646d:2da3 with SMTP id i5-20020a056902068500b007e9646d2da3mr1102592ybt.340.1674063648863; Wed, 18 Jan 2023 09:40:48 -0800 (PST) MIME-Version: 1.0 References: <20230109205336.3665937-1-surenb@google.com> <20230109205336.3665937-28-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 18 Jan 2023 09:40:37 -0800 Message-ID: Subject: Re: [PATCH 27/41] mm/mmap: prevent pagefault handler from racing with mmu_notifier registration To: Jann Horn Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, hughlynch@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 11E3D1C0014 X-Stat-Signature: ps1pftrfmffwkxkn35zp8qm3s9n4wk1n X-Rspam-User: X-HE-Tag: 1674063649-747935 X-HE-Meta: U2FsdGVkX1+yYrfgBWhAZM7pZu7dzM2kMVDsPfp+x7TRMVNY+H4DTh6P8S8fzEb7Z4rPse7CKuaZ6n1S/iPF1XnQt4V9HQ89Mfl/ZQseoq/DapwfpTovj67fiyQfRygegY21rAwmqogXoaWclnc7RoKMCXhg5264yJ2Wq5QIrHq6t5MgKEkrj3AsC5dAjLOLS8v/qO3vxDp2Gb5LkndndSO9sHCDMiOhkAxpeE5EuZ/2DtLwNZYubreqBCuWUZFG3Qb9opOH2wQrQQKKQNQjXz8lIuK0NmAaoJyKx9k+KuoIFIO65+79JoCnmkbuAHwHOUFQQXNPPmyVQctzORqtwT8DddC74/ShfEmJ+Be26/+Vx6Q+S1xmp3NeLvE1wQNQ+BxxCt3vBJxm4gWQolCMkk5BvEr9JsO/eMs/U4egbaqDTcJrv9JGK11rEF3h42EOXVhqbNzTyqfQUdK7yEitlimUGPnOLO8PMDRd8B81bn8eaQVbFDSdXXkfyw53XPHagls+A2vQpmmfsZGeQfn7cnB5NBtac7IMqMLu6WweA0b92N2xW51PcXPCVykIyijhs6u8rkUz7iS+Zy3DTJQndw/uqUTj4BWyqiHnwoeQ2g3nwQGevmPtX2M7Q3c21G1wWcK3Hz6aPzvZpfU+tPclkFHrMMu5P2LcWV5Q5+1sDVLz39OfC7Whmhl9gdLtalLIa2Nz+cSi9SXCBHA3dn0I2HlVCfnOVvEnR1o6DAA8AbzWGjN/Js+zbbImqAmlBD47QBh9FsgJSFc94nS8p7vf/1iQcsVVcmS2RFz1QHyHh4lsPfe4K3MTTxaDDLuTmsWULY6J0XtQDAXVzKHQoeDvLFhMGjkS4AcwEMfxVngByLeeJd9G+7Trvtl622x3fx17OlQe87ccvXDxK66VPABREMnSHKNIE58Up5ryMNSh1PBxVWSNB0Xb2t1GR71cUN0Kman1nrFscE9qW/qdhgB YxTkTdTj SkkYTt6/4wyABriZRIXvWzzKCMRhgmhqIFdBCw5HhxlFqClESELLgxmwKZg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jan 18, 2023 at 4:51 AM Jann Horn wrote: > > On Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote: > > Page fault handlers might need to fire MMU notifications while a new > > notifier is being registered. Modify mm_take_all_locks to write-lock all > > VMAs and prevent this race with fault handlers that would hold VMA locks. > > VMAs are locked before i_mmap_rwsem and anon_vma to keep the same > > locking order as in page fault handlers. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > mm/mmap.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index 30c7d1c5206e..a256deca0bc0 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -3566,6 +3566,7 @@ static void vm_lock_mapping(struct mm_struct *mm, struct address_space *mapping) > > * of mm/rmap.c: > > * - all hugetlbfs_i_mmap_rwsem_key locks (aka mapping->i_mmap_rwsem for > > * hugetlb mapping); > > + * - all vmas marked locked > > The existing comment above says that this is an *ordered* listing of > which locks are taken. > > > * - all i_mmap_rwsem locks; > > * - all anon_vma->rwseml > > * > > @@ -3591,6 +3592,7 @@ int mm_take_all_locks(struct mm_struct *mm) > > mas_for_each(&mas, vma, ULONG_MAX) { > > if (signal_pending(current)) > > goto out_unlock; > > + vma_write_lock(vma); > > if (vma->vm_file && vma->vm_file->f_mapping && > > is_vm_hugetlb_page(vma)) > > vm_lock_mapping(mm, vma->vm_file->f_mapping); > > Note that multiple VMAs can have the same ->f_mapping, so with this, > the lock ordering between VMA locks and the mapping locks of hugetlb > VMAs is mixed: If you have two adjacent hugetlb VMAs with the same > ->f_mapping, then the following operations happen: > > 1. lock VMA 1 > 2. lock mapping of VMAs 1 and 2 > 3. lock VMA 2 > 4. [second vm_lock_mapping() is a no-op] > > So for VMA 1, we ended up taking the VMA lock first, but for VMA 2, we > took the mapping lock first. > > The existing code has one loop per lock type to ensure that the locks > really are taken in the specified order, even when some of the locks > are associated with multiple VMAs. > > If we don't care about the ordering between these two, maybe that's > fine and you just have to adjust the comment; but it would be clearer > to add a separate loop for the VMA locks. Oh, thanks for pointing out this detail. A separate loop is definitely needed here. Will do that in the next respin. > > > @@ -3677,6 +3679,7 @@ void mm_drop_all_locks(struct mm_struct *mm) > > if (vma->vm_file && vma->vm_file->f_mapping) > > vm_unlock_mapping(vma->vm_file->f_mapping); > > } > > + vma_write_unlock_mm(mm); > > > > mutex_unlock(&mm_all_locks_mutex); > > } > > -- > > 2.39.0 > >