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 231B5C54E76 for ; Tue, 17 Jan 2023 21:04:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8027A6B0073; Tue, 17 Jan 2023 16:03:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B2BD6B0074; Tue, 17 Jan 2023 16:03:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6A1326B0075; Tue, 17 Jan 2023 16:03:59 -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 5C0BF6B0073 for ; Tue, 17 Jan 2023 16:03:59 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1D798120BCB for ; Tue, 17 Jan 2023 21:03:59 +0000 (UTC) X-FDA: 80365518198.24.F1B2169 Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) by imf28.hostedemail.com (Postfix) with ESMTP id 87A07C000D for ; Tue, 17 Jan 2023 21:03:57 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Ugmy2ZqK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of jannh@google.com designates 209.85.166.44 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673989437; 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=nhao4yhxvo1b0ca4/4XXHiPX2DFuPMAuoXXjxRqWTzk=; b=DWP5d6JIBlJijirqxnwP48vgxGv8mKJIshm7oQNXKkH9uR7XbKv80ar0siMVIPTaEqyC1m Eml01T4u52mmfIqfz7tl8r7UaFJLf1O+Txt3XBjXeqr79UvKB1kQhXxlUxnHO4FDUGbnUu wJ/8ThONMKExbIstrjIXMuTkskRbnXQ= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=Ugmy2ZqK; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of jannh@google.com designates 209.85.166.44 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673989437; a=rsa-sha256; cv=none; b=4NTm85O1nIqQu6pn/bjxgeegN3NE3sArYrFZDoB6d9iVF6vLjxSRLsv89Ffh0F+UuAITDr jTZ8SyybjjtzJU5JjLv7xGADiviHlxTGauYfvjhaCCwItlACmYpqTHxjeqReexqMdHC6sn q3iNxNBbnKJhE6pBaaOuggd2mYACuGw= Received: by mail-io1-f44.google.com with SMTP id s26so7678955ioa.11 for ; Tue, 17 Jan 2023 13:03:57 -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=nhao4yhxvo1b0ca4/4XXHiPX2DFuPMAuoXXjxRqWTzk=; b=Ugmy2ZqKnLRTOnr8n+vgJmW7jKcWi4hXccBOn2Gki6Zrag7MoLWtZ+TwC6KAa1rMXw wXpyQ8nmNJOrUrseDG9EzHysaXMjM04aS5x2xNylWaAN9xvvdISifj6fE++htaLmbddR j81VjCX2xsB852mW5SqUWN0nd9IvIVdfgHX33Hh2tu0XchQY05liQxtto9CUhXsnf9k7 f6y6oOhGyoxCPLOEL45q+HGd9pmFyOS5F/LZR7OgkHsj8ga1IKTsgBSDZYIAGdZSdz8P SnaqeJ4jBFGrrKdUvkPzy7SEBae8MWN4qiEkG94kK43jVC7Q6PfwYVJUCo/XaiKekGkY 8s8g== 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=nhao4yhxvo1b0ca4/4XXHiPX2DFuPMAuoXXjxRqWTzk=; b=h0UylfOHeSBbR2c0zRasU1uOrEdC5hhGdsRgW4xJRWyU1AM+apP2QgkSAtLN9oNpB1 Qq7Y3VhKIyU3oUOGKxeunTzv4KvyWWEayYPLqLjxCWmzTZFgd9Z5lPh1O1Te1C5TLngF Wm7twuPgKwr0lSmZbL5TNx0Wnkcic1IrUrDQzyoVQDgYEpBPZptA8YoiZdcQhJnNqv2D 2FZQgXKQ9Pq9PZRnFA8fLXVBNE+/0f8uSyn2tSA4pb49o7N+xgcsTeJ7AiolIpEj+jsI ClbkBIcz4UmklCIhH4yZVAm0KGN7OrjxePgHVewB66VTXq8sBZoM/QGTrHd3gothikB/ 6aWQ== X-Gm-Message-State: AFqh2kqstVOzcRyZwigIT3z4uzznGfgqH+hJ2imuehtqnU+Jc1lWW5um RU3gdP4RWquAI/N6SijE+cYIw9zQQ7dwcIu8a1t1JA== X-Google-Smtp-Source: AMrXdXsMeP8M6U4I8iASTh2mqrZYLm+ikxBgVtUSVf76IGFGfS0Npq61yI+0jkuo5OgGYf5QPFQKrSgcpAZ1h7kJHBc= X-Received: by 2002:a02:cb45:0:b0:39e:6dd8:6c96 with SMTP id k5-20020a02cb45000000b0039e6dd86c96mr345507jap.246.1673989436533; Tue, 17 Jan 2023 13:03:56 -0800 (PST) MIME-Version: 1.0 References: <20230109205336.3665937-1-surenb@google.com> <20230109205336.3665937-29-surenb@google.com> In-Reply-To: <20230109205336.3665937-29-surenb@google.com> From: Jann Horn Date: Tue, 17 Jan 2023 22:03:20 +0100 Message-ID: Subject: Re: [PATCH 28/41] mm: introduce lock_vma_under_rcu to be used from arch-specific code To: Suren Baghdasaryan , willy@infradead.org, liam.howlett@oracle.com 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, 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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 87A07C000D X-Stat-Signature: up3pc4cx1fatawikd7ft1fw7wqu3kd9q X-HE-Tag: 1673989437-124358 X-HE-Meta: U2FsdGVkX18uMQCTNIzj1WxwlvUBxHmQfCC18fPkWN7CdflWWdRV+obL1sKgDdr9MlVtlVAdAJKQqpWDo4qsF0etWZHUN8t6orImBNChfOh5tF69Pb5RnC0riBjG5LgwO4ua7WAV4YkKqFQgb7Pn8WKdG7prZqkv7Bdeh81vCSSb52rBNjb+dp8PQvx9jhJ6WhE+XY69UKBxDKkERXfmio9uJMH1kTISeWGGk/VMzn6VMQYeUsVSMbxXpO+Qm64YrZ2qVOWNDSSvfLW0ArT1Fbf4jIK0FMevnWNlgFQA0RTu3KbBp1X+VOd3aSv7Q6AcTxpDzv66s+auCVudky04zEiKYmsAteYJTCF+eyAxzLGIcEeHzCbcH+MT19Z4ub0vEWJxQn2wVigCkLzY8WtuuLXGU9hJ+jas9ozey4NGAfbZBACfg9UyGf/c6ZcGy5zw2kPcHSv8xea8gz7Tovhsj+iGVZ1LDAReBGiAfdCYE3dRImepJff17c9WVffZt3Yl+IQey9jJt3/NWTG7sVcs8jcW/ZqrhYcUp4YLNx5rNqBetj/ZteCG3ukdCE8CH5z1KFQpvgDX+EKzowG+WV+K8RnhNm87uo+VD/KY7aj9XBNpGGPfQVI1pp/qXQflqjqJ2jaaqdiNGdN24hFm6h1mHEWh3cC+L4j66wyYd5VU6WiKMof5rgK4ULRnAteceViulzlo3jx4l0ZDdNpSYIiqKDfaFjpwqzs0+x4MP439zfUAvc/1wggGEP33pNNCYaYGudLUCAa9CivIOwhwpFU9/gnjFixmPRnGat1n+lg+yOWwNF6U2kng5h090gmupX98HT4ZCu4YcWbtydupeupnxyFDvJNJ0r8pEKwvh85fmBdGj74At21ZczLesZ6XDJsvK7UeWOXBLVZcJJsR5wkVMXzwBDuGeuvydly5j+RGxsCHNmjjj5oYqzrM3w7588zYyY0jO0vZeEDW8wsnpwt GKKWW24P I3ojGPrD6x2MWrcWKZemjTEa+WlZDomrBBfbn01yIOz0gtsqVohaxRsCi3w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000024, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jan 9, 2023 at 9:54 PM 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. [...] > +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); Question for Maple Tree experts: Are you allowed to use mas_walk() like this? If the first mas_walk() call encountered a single-entry tree, it would store mas->node = MAS_ROOT, right? And then the second call would go into mas_state_walk(), mas_start() would return NULL, mas_is_ptr() would be true, and then mas_state_walk() would return the result of mas_start(), which is NULL? And we'd end up with mas_walk() returning NULL on the second run even though the tree hasn't changed? > + 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; > +}