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 719F9ECAAA1 for ; Fri, 9 Sep 2022 16:10:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E9FF76B0071; Fri, 9 Sep 2022 12:10:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E283D6B0072; Fri, 9 Sep 2022 12:10:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA2928D0001; Fri, 9 Sep 2022 12:10:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B51D46B0071 for ; Fri, 9 Sep 2022 12:10:20 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 8A457A136A for ; Fri, 9 Sep 2022 16:10:20 +0000 (UTC) X-FDA: 79893034200.14.F077E69 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf25.hostedemail.com (Postfix) with ESMTP id 324DEA00AB for ; Fri, 9 Sep 2022 16:10:20 +0000 (UTC) Received: by mail-yb1-f176.google.com with SMTP id a67so3387833ybb.3 for ; Fri, 09 Sep 2022 09:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=f+8N/y8y23UZcEEw+aQnyU3DKfX0ieX6O82IRCC4HdM=; b=BiyE3pbFzAwYEbflQaZphZUwAl6tFqEKoxOSeraxpHXAycNAP3ER6hKVN7zFxfnZYI dmbHBcE6XaXCDmJB0eURxyjOS/LYAdTSVJQQgbSxedvGxksEGEwo8bnxbUL8mqNSiS0I HQyjMm7qR28Cy5F5ljGna6zDh1IiUsm0e6MqXa3HuxfjplJN7dSZ/Qs1dLgbietr0qPm aaeYBKFqiZMof8mnns8VIkOIM2RsE/1SOEkhSnGyg23sOandSiJu5QHwmXR0GZ62ahYH XGvfGR0+GC7EgWkb3KjP0ya0ZAmSu88fnl+kiUpJwLjqxUD63YfqwYHj3h/U+xX2yvGr 3QZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=f+8N/y8y23UZcEEw+aQnyU3DKfX0ieX6O82IRCC4HdM=; b=iZJSZDZymIIrFYAefUPPbiBP67odWOsg/DmnzDnKQ5Gxs/l5lXH7V4XT1/mbvCw05h xhc6g7UaL3hQcUdPKBm3OP9o5mKPcTNGy4JHsfOBP0uArRt053jvrSFKPik3OuAUQ3BJ y2ngykxipvlwXXN9N9aYcK5t38m8w1GjM4cn0xdaw8w7f1JyVzCfq+r7Dg90Tm5BhjvX chvAXdjZf0YmZGcKTvZzXHJ8dPXfguJ9WP2JA0kR5IOq89uV0pwEWfbKKDKUSbPgKJGk tFfcz93QE0hptFsE2BJVU2UwYhBJC51igWnpNLDSxOjc4Ql8SB98ynhoI5P0V2K3BPEN feEQ== X-Gm-Message-State: ACgBeo36uuEWL/3fh4QVopDp1i5Aq0tsG9pRn5nymfrDjH8j5X+iYA8f CdGGkGSJDbYfEoM8zOy8LJha/yV9FKAfxOc7VM9aSg== X-Google-Smtp-Source: AA6agR5mnVSQ1qQ+aIdXXXGAhOTMvHt8B37xrRYeRcCRdY1CnsLY6FiKvNQ4vPY3G6eYgyMHbEmwJurPorP8bkXzM8s= X-Received: by 2002:a25:424a:0:b0:6a9:2954:87fd with SMTP id p71-20020a25424a000000b006a9295487fdmr12075530yba.340.1662739819203; Fri, 09 Sep 2022 09:10:19 -0700 (PDT) MIME-Version: 1.0 References: <20220901173516.702122-1-surenb@google.com> <20220901173516.702122-22-surenb@google.com> <630714df-dec1-4a41-6af3-380181d11669@linux.ibm.com> In-Reply-To: <630714df-dec1-4a41-6af3-380181d11669@linux.ibm.com> From: Suren Baghdasaryan Date: Fri, 9 Sep 2022 09:10:08 -0700 Message-ID: Subject: Re: [RFC PATCH RESEND 21/28] mm: introduce find_and_lock_anon_vma to be used from arch-specific code To: Laurent Dufour Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, 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, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, kernel-team@android.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662739820; a=rsa-sha256; cv=none; b=7rjtWVjcNpvD1ZCI4GGIcR41dgxc08D7iJ8fPn4aA05tON5qeoBeToZJwkOht74pE93nKn vkp8jpr0rENuSwpwhrIg+af67YPNSKtgiQuKjQOd5oVLl23Lgh3zL2x2ZthW1+gcvhap50 M5lPBklu2xdv9nHdK5vN4MT0b1UtMM8= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BiyE3pbF; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 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=1662739820; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=f+8N/y8y23UZcEEw+aQnyU3DKfX0ieX6O82IRCC4HdM=; b=pb14P6xd89Zul/is4nu99GLw6e2wJxIN3+q/cghSzIoyxOABFgcNVysj6bgDRamJrQ0UXx xhyRrP6fneXSqnpDPVR2aZw3dwc/W/4A7o2LrFkpMG/bN02zRP4tcCHrmHnEP5uuw+w32L M7tJvvN3Tq9tskixZmYb0VoiJ85r+DQ= X-Stat-Signature: kkb3k4qgk4hx5d3kjj5kok6a7z6qmmb4 X-Rspam-User: X-Rspamd-Queue-Id: 324DEA00AB X-Rspamd-Server: rspam07 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BiyE3pbF; spf=pass (imf25.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1662739820-380086 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 Fri, Sep 9, 2022 at 7:38 AM Laurent Dufour wrote= : > > Le 01/09/2022 =C3=A0 19:35, Suren Baghdasaryan a =C3=A9crit : > > Introduce find_and_lock_anon_vma function to lookup and lock an anonymo= us > > VMA during page fault handling. When VMA is not found, can't be locked > > or changes after being locked, the function returns NULL. The lookup is > > performed under RCU protection to prevent the found VMA from being > > destroyed before the VMA lock is acquired. VMA lock statistics are > > updated according to the results. > > > > Signed-off-by: Suren Baghdasaryan > > --- > > include/linux/mm.h | 3 +++ > > mm/memory.c | 45 +++++++++++++++++++++++++++++++++++++++++++++ > > 2 files changed, 48 insertions(+) > > > > diff --git a/include/linux/mm.h b/include/linux/mm.h > > index 7c3190eaabd7..a3cbaa7b9119 100644 > > --- a/include/linux/mm.h > > +++ b/include/linux/mm.h > > @@ -684,6 +684,9 @@ static inline void vma_assert_no_reader(struct vm_a= rea_struct *vma) > > vma); > > } > > > > +struct vm_area_struct *find_and_lock_anon_vma(struct mm_struct *mm, > > + unsigned long address); > > + > > #else /* CONFIG_PER_VMA_LOCK */ > > > > static inline void vma_init_lock(struct vm_area_struct *vma) {} > > diff --git a/mm/memory.c b/mm/memory.c > > index 29d2f49f922a..bf557f7056de 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -5183,6 +5183,51 @@ vm_fault_t handle_mm_fault(struct vm_area_struct= *vma, unsigned long address, > > } > > EXPORT_SYMBOL_GPL(handle_mm_fault); > > > > +#ifdef CONFIG_PER_VMA_LOCK > > +static inline struct vm_area_struct *find_vma_under_rcu(struct mm_stru= ct *mm, > > + unsigned long add= ress) > > +{ > > + struct vm_area_struct *vma =3D __find_vma(mm, address); > > + > > + if (!vma || vma->vm_start > address) > > + return NULL; > > + > > + if (!vma_is_anonymous(vma)) > > + return NULL; > > + > > It looks to me more natural to first check that the VMA is part of the RB > tree before try read locking it. I think we want to check that the VMA is still part of the mm _after_ we locked it. Otherwise we might pass the check, then some other thread does (lock->isolate->unlock) and then we lock the VMA. We would end up with a VMA that is not part of mm anymore but we assume it is. > > > + if (!vma_read_trylock(vma)) { > > + count_vm_vma_lock_event(VMA_LOCK_ABORT); > > + return NULL; > > + } > > + > > + /* Check if the VMA got isolated after we found it */ > > + if (RB_EMPTY_NODE(&vma->vm_rb)) { > > + vma_read_unlock(vma); > > + count_vm_vma_lock_event(VMA_LOCK_MISS); > > + return NULL; > > + } > > + > > + return vma; > > +} > > + > > +/* > > + * Lookup and lock and anonymous VMA. Returned VMA is guaranteed to be= stable > > + * and not isolated. If the VMA is not found of is being modified the = function > > + * returns NULL. > > + */ > > +struct vm_area_struct *find_and_lock_anon_vma(struct mm_struct *mm, > > + unsigned long address) > > +{ > > + struct vm_area_struct *vma; > > + > > + rcu_read_lock(); > > + vma =3D find_vma_under_rcu(mm, address); > > + rcu_read_unlock(); > > + > > + return vma; > > +} > > +#endif /* CONFIG_PER_VMA_LOCK */ > > + > > #ifndef __PAGETABLE_P4D_FOLDED > > /* > > * Allocate p4d page table. >