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 CC4E6C678D7 for ; Tue, 17 Jan 2023 15:47:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D8626B0071; Tue, 17 Jan 2023 10:47:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2AF966B0073; Tue, 17 Jan 2023 10:47:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1778F6B0074; Tue, 17 Jan 2023 10:47:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 09A046B0071 for ; Tue, 17 Jan 2023 10:47:18 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C34841404CB for ; Tue, 17 Jan 2023 15:47:17 +0000 (UTC) X-FDA: 80364720114.01.A846BD1 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf18.hostedemail.com (Postfix) with ESMTP id CB6641C0019 for ; Tue, 17 Jan 2023 15:47:15 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Qv1lqyxp; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673970436; 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=NUiY3CvLapMFEuYfFsjZYssRcX9vLmzM+egf4tjCh/M=; b=B9JFwTRuFIQQY6PD0KnxBIDGGTrSSoxMbfX39jEiu9tmO2TXSIqL7a2FUDsK9dqiDmu8NB xnkaYYZu7GjAygXiiCGvbVDUfnAgMBJRhVKGl1gkZessI593pZv8XsTg1YJA5eTcPbagd0 1k5w5Hh2447Hdlk085YCF9B5mumexnU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=Qv1lqyxp; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673970436; a=rsa-sha256; cv=none; b=YnDvHKk/fhLe0GPmXP3ib9VmhFSpUmybTypS7AEuf7cJOy5VVBCIY/O60D8IytF15MfUsM /j4GtGe06MpLCJ+qh3uo9tfD6Q1tk7YrtlN8fPD/3nD5siYQ8gurnav0De2LrkCY1Nm/kD +ggKBcyJVN2gxVTR/kubQzPqelegj3Q= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 94DC01FFC8; Tue, 17 Jan 2023 15:47:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1673970434; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NUiY3CvLapMFEuYfFsjZYssRcX9vLmzM+egf4tjCh/M=; b=Qv1lqyxpDwXRzDUPml0XrcqNLd00O/evBot2GOJJTEbg8kJoL+1NNpW8AGe8s85Qy7rKgT IKfZPE0bOq46JT9nRsm3QoIayz6ls5r1TSRklkTtUb/jqlrjKXHMK7sp5RYeoUrbe61ayn wIIQLGaFJngLhJyENWqGvAEUPsP0UFI= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6D8AA1390C; Tue, 17 Jan 2023 15:47:14 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id iP1IGgLDxmOAVwAAMHmgww (envelope-from ); Tue, 17 Jan 2023 15:47:14 +0000 Date: Tue, 17 Jan 2023 16:47:13 +0100 From: Michal Hocko To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.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, jannh@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 Subject: Re: [PATCH 28/41] mm: introduce lock_vma_under_rcu to be used from arch-specific code Message-ID: References: <20230109205336.3665937-1-surenb@google.com> <20230109205336.3665937-29-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230109205336.3665937-29-surenb@google.com> X-Rspamd-Queue-Id: CB6641C0019 X-Stat-Signature: 43i4tpbqdq9r5n3ddb9jju79jr9x86zc X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1673970435-354255 X-HE-Meta: U2FsdGVkX186yxgXBqh75dKFJ3DCJpfR/4fab0GiL5BikO6OE6z4MhTKCjxtg3c7enonQaTH8ipybEwQJc5H91eH1zs+CnPGHzboJBDebtqNzcabSY++Qz578u3sPCU+5ajwAvn4uhiHSF9hbXkiPUD0UBd6Dke2LRV76XyKrP4B+dsf2HbJq6h06cooH75A2YgnQA7MRuF09HlrQDkDnjSeu9i6UgPa1GfLYX5SKy0JYXy1jcpvP4uAUnwTfsPDLMtOvFUHD1hoRM3aDAHypMNcrNGwCo00ZJftOnQyrUQUTx9FK+nKB84yYEgdATTRp8z9Tz2eynzdCFRjW4BBjWqNKHTsH7rqWbmFw3bCU9uAHCmuc0G6McslvgXaT3kT+FT7SoySshAIJDwkMjDa6pUTTlsDAGbWhzGfgvqcJOH6QwzT2u+DWnPL9f3tqe0y19QFSXKWNr4glZfqjjdbAFcllT600XU8zWjzHwxgTXay/IdaG6nXUAjneEeck6yYjH1pfIkwQQcA3N/r/Be/wFZep4y36Lqv1RpAYyzoyStj8BW/M7l/RuqC6say5Wn8pC95u46bPtOS4pIY3uc0IlaWtd/OLEUdQGgtGoJXYtWQ7FQ8jqWS78LPowCQDUU+5Jvg2aVrHbV7Vt3sPFkKFnJvDGvgr2GyX2VcJVJgdQJvRnHXMZ51YfoqFvqiDGCYbUNAs+Ow8eMHQok7hBhGnJNTCsmbII56ycDd7vJ+PTx11IK3UgvghhtEIoyc8XMD0qZ0y53aS6fA3QsRn2OY7kl6er7DQ7xen5mO/+Loq+a2A6i3+jsS0x+oz0i0XQkYnOr2N6mumgQpusgzu2DNw0SwIM3oOsMVC7U/5DhhWC4tDEoT1OcT3xwiYNz4C/NZ/CjpCQkh+zOPAPKst4g47HwM12adwv4K 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 Mon 09-01-23 12:53:23, Suren Baghdasaryan wrote: > Introduce lock_vma_under_rcu function to lookup and lock a 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. > For now only anonymous VMAs can be searched this way. In other cases the > function returns NULL. Could you describe why only anonymous vmas are handled at this stage and what (roughly) has to be done to support other vmas? lock_vma_under_rcu doesn't seem to have any anonymous vma specific requirements AFAICS. Also isn't lock_vma_under_rcu effectively find_read_lock_vma? Not that the naming is really the most important part but the rcu locking is internal to the function so why should we spread this implementation detail to the world... > Signed-off-by: Suren Baghdasaryan > --- > include/linux/mm.h | 3 +++ > mm/memory.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 54 insertions(+) > > diff --git a/include/linux/mm.h b/include/linux/mm.h > index c464fc8a514c..d0fddf6a1de9 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -687,6 +687,9 @@ static inline void vma_assert_no_reader(struct vm_area_struct *vma) > vma); > } > > +struct vm_area_struct *lock_vma_under_rcu(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 9ece18548db1..a658e26d965d 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -5242,6 +5242,57 @@ 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 > +/* > + * Lookup and lock a VMA under RCU protection. Returned VMA is guaranteed to be > + * stable and not isolated. If the VMA is not found or is being modified the > + * function returns NULL. > + */ > +struct vm_area_struct *lock_vma_under_rcu(struct mm_struct *mm, > + unsigned long address) > +{ > + MA_STATE(mas, &mm->mm_mt, address, address); > + struct vm_area_struct *vma, *validate; > + > + rcu_read_lock(); > + vma = mas_walk(&mas); > +retry: > + if (!vma) > + goto inval; > + > + /* Only anonymous vmas are supported for now */ > + if (!vma_is_anonymous(vma)) > + goto inval; > + > + if (!vma_read_trylock(vma)) > + goto inval; > + > + /* Check since vm_start/vm_end might change before we lock the VMA */ > + if (unlikely(address < vma->vm_start || address >= vma->vm_end)) { > + vma_read_unlock(vma); > + goto inval; > + } > + > + /* Check if the VMA got isolated after we found it */ > + mas.index = address; > + validate = mas_walk(&mas); > + if (validate != vma) { > + vma_read_unlock(vma); > + count_vm_vma_lock_event(VMA_LOCK_MISS); > + /* The area was replaced with another one. */ > + vma = validate; > + goto retry; > + } > + > + rcu_read_unlock(); > + return vma; > +inval: > + rcu_read_unlock(); > + count_vm_vma_lock_event(VMA_LOCK_ABORT); > + return NULL; > +} > +#endif /* CONFIG_PER_VMA_LOCK */ > + > #ifndef __PAGETABLE_P4D_FOLDED > /* > * Allocate p4d page table. > -- > 2.39.0 -- Michal Hocko SUSE Labs