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 4E874C27C53 for ; Wed, 5 Jun 2024 16:14:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D3FB6B0082; Wed, 5 Jun 2024 12:14:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 784316B0083; Wed, 5 Jun 2024 12:14:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64B946B0085; Wed, 5 Jun 2024 12:14:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 478726B0082 for ; Wed, 5 Jun 2024 12:14:12 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id C44461A13FE for ; Wed, 5 Jun 2024 16:14:11 +0000 (UTC) X-FDA: 82197331902.02.CB6E4D7 Received: from mail-pj1-f54.google.com (mail-pj1-f54.google.com [209.85.216.54]) by imf07.hostedemail.com (Postfix) with ESMTP id 051E44000F for ; Wed, 5 Jun 2024 16:14:09 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=S8iSpycW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717604050; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=xShohQaQijNVnGBy0vSCe1Lri84br3jamfs3+AUmWoU=; b=PSIpkpMXUzIGXxUmDVoT61U1Ti8Mn0P9a4KRAaM4+TC2A+KA3pTnEPPT+LitIB+IlhwCct s9cZ/4c75+JQOxubvGK3ZCWVtS6eOar4qOCpyLUPWADKBA64n+RXf7aFFZELpDkYtRgJNo AqLVYnImBhna9EYwrKP8MO/kWcwMiMk= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=S8iSpycW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of andrii.nakryiko@gmail.com designates 209.85.216.54 as permitted sender) smtp.mailfrom=andrii.nakryiko@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717604050; a=rsa-sha256; cv=none; b=AQjZOsFS0ulPe3Tv5/Sak7xW9ioQriEINEuBdhWHt5Z5TUoffIRKGFKgltm0mu1rwYc3OW sbs+rHvffR1Ca0nW9yypGZrl7WX+TcIhzN+QpJLxHze1rY4OND2dCRz/rKfRpz98MlOWwm rTnwo5j8RfnqdznDXfHuHWMxsXAv10s= Received: by mail-pj1-f54.google.com with SMTP id 98e67ed59e1d1-2c1b45206abso5069485a91.1 for ; Wed, 05 Jun 2024 09:14:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717604049; x=1718208849; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xShohQaQijNVnGBy0vSCe1Lri84br3jamfs3+AUmWoU=; b=S8iSpycWsfu1ycWeWbG1JURWLeoUVGoq2lGw0jvtlUBK6APeZIyfHWPtQssahgoNnw yYEgUIrSz6B1CRTzaKPauxKVuHq1Z+84smk9k4VBpqpyfL1O5qI/8Nk2mpbFEq1FiOSk cb0Da8OnGqxhlF05DQ8QSX8jhlcEJJj7Mi94og5V0mNwe45ofWpZqgbIp5q1hGgJ5IS8 5afmWUiGyWnX4Rs8D5ko9K92awOc4fexCgXoJHxgoNc3p16rMCqx8EAhhzQLsZUojEoG /G7mSnlCwsW1Y4a7jI4CReNJi+18RUddorcJ7vc11AlGEaYdMwCiInMrQ0dHIN/gbVCx EnNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717604049; x=1718208849; h=content-transfer-encoding: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=xShohQaQijNVnGBy0vSCe1Lri84br3jamfs3+AUmWoU=; b=kJkk7os17NvD7/yPP8OeVtmO4CBv1FzmiWpsIrGSvCZsITWMgNj5j2zYjalMyxcwaa +owYjTj3qBlOJKua6WfzVmtBPGqqOXDeu8U9qECDAO0v8PxBY/rjKjT2ZnMzd/z4D9tW r5Rwexj2ue+pjZsG06uvnG2sQ39EFy2+Divzkiz6ZSxv6suaTUyPNSL6VkF24MBGBJrV G4CPQI3vBQL2OL3Pn4R/8OADFMXFCAvgI5Qps0GBsUZL1wLAZAz75xzv4RKE9T6cr5dO 67K9qetYrzOP/ZA3s48SZ8wBQ5NKPisxgjxmdyOb1fnwn9v1r7HkHF+o9xATEQDRV31y tQbw== X-Forwarded-Encrypted: i=1; AJvYcCX8zXzv5CKSnyeeXj6TXwu3FKKB8i+3uI94ZQ4jT4RujDE/ZLTBq6qJA3N4v+RJE+G2G+r3V867RW0KaYyvyHJkEkY= X-Gm-Message-State: AOJu0YxDrMq4M9DdftYW4rFHY7vTZtzdSs/ddkgBMzxejYid3VLgt9vt lGyuW4boj3zNTU4njPCrgb6GBLrLYlWDyB+31gJoYYaVSKJVBYBk5kmTDw3inFn4vkuVc+IBY3b dfLWaZG+76cpC+zje5lzJIpTQVa0= X-Google-Smtp-Source: AGHT+IHDIZeudf9hp58R/vptexzs1Mrowe6BNsnF5Wlb/7372cK0lZMZTfKDqKmYcNXTjsWoONoUvuThHOfGib955fE= X-Received: by 2002:a17:90a:d512:b0:2c2:8a67:96e4 with SMTP id 98e67ed59e1d1-2c28a6797c7mr1470005a91.7.1717604048552; Wed, 05 Jun 2024 09:14:08 -0700 (PDT) MIME-Version: 1.0 References: <20240605002459.4091285-1-andrii@kernel.org> <20240605002459.4091285-2-andrii@kernel.org> In-Reply-To: From: Andrii Nakryiko Date: Wed, 5 Jun 2024 09:13:56 -0700 Message-ID: Subject: Re: [PATCH v3 1/9] mm: add find_vma()-like API but RCU protected and taking VMA lock To: "Liam R. Howlett" , Matthew Wilcox , Andrii Nakryiko , linux-fsdevel@vger.kernel.org, brauner@kernel.org, viro@zeniv.linux.org.uk, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, gregkh@linuxfoundation.org, linux-mm@kvack.org, surenb@google.com, rppt@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 051E44000F X-Stat-Signature: ms6imxgkhdqagdi4s1nkwga58eahjywf X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1717604049-828362 X-HE-Meta: U2FsdGVkX1+4lheMMEJNSRMdf/Dk1WR9RncGJv3BwjDTwzGmvqI8MhgL9J1XQcBUhtz69/bhcWJYLkihCPdczI4geTDBPMk34s6zftXUlG2H4qU3bd2EB/HE5OYae9gdef1ZORw+OOEVKUMjXg6D7w07JIq0rYtIyfGXsUPHb/KGnDaCGUzF+4MLgFGpx8jygm0C7VaT3CbYcdYMAYsw4KdIh+VdGpcgAix38D9WeJMKIYh2+C0tE+5Y4DFqdMIYfaOgYi77dGGyvwroeaPMvT6Eab6zYfWgNfHpcYTWWQrjWtCGzSqOaPFNYVlJEKELr5kzWoLUaoBai+79/X5whIw8828jx9MESo0zG+zLjuNLJT2roFdcrU+xD3Ipz/COOvmON0rzqxqOzAG8Woe8iyH0aqriZ+lLEp64pZDEpmRua31Ngxnc+4pOKQZ2jBclNelhsoe0uxhQmiX8+weeUMNw0ItYzH05bRSGe05D/8OU4PPiohk2fOcsoYXq55WOlRS1rsIq4qv3TAi1Uaxh+ibn1+wpcTIYlP6ElKBrfqWRlfq/h4Ey/mnKSs1WqE1Cmx1BjMxSasOJxFPCLzzkAnrEQlxfOKTKlwnFJGnVMArpscrqjECa6QCxf4ZVQ1RmT8UU1hmLnrDQiJ7IRnT30W7pSFhVfd7o2BPBmNzBJwh+o6eRqSxUDjnwgxgEO+7yxmN0Q0YHFPsDO+aTEJ2iSL1NxTKpUQciQQvC4gYMd4pfll2mwQWnDdYNMW2jZmsZjJxbXanBhO4DHDZTbftnOk/bom7cxWPBsusy2a2oo459GGMPOqLE6gZPWWRVKgjRmLlUy6naiQS69ZNzXYMci6Po8j8V5D3fh9KvjMrFUSKGxqypvLzDIIS8alw09bPUedSmZOUKzToLw6Vjy+kSfcs+Q4IalrR4XLa37PZED0LFzDkppzrxejXlVG0o2QCJ51MuMIBysPY4kq7pk1g OIBANLPP 4BTZfOr/pmWcFTf+QuxyoRQI8rqkvmH2DmuzWytIFRemLtxzev3VjMvlCJzPCFmeBaqvy3BZZUffXq1XGiv7OWWEmnrSDiEzYRmDSvQZV/a8XY6g7BcsRH8fU4uAwULhP8YLSt9rVA1JsTF5+b5maoeXypPGvCfoU7jivKB0np+iaGozMBNmo/XU1we9BRemPCendK3zKk/EReScbKlui26VxLyLmZrpjslwKo4msUVCiQWAdPMkHRB4zqFcCKNwRJK1dDYtB7HcNF4aB3WXHRsvgqzDmKXPz//TXQZgSTJNRsRbZrgctUm+fQeo/Jw1GnzF2YzQzYRUS3LSQI3oXJlUGG/b0zomUtkjSqB6zcCnRc7Kr45ApoU+T6NsW0V9wzQP+ynZ1X3GDv/fJzPZWclOqfDl9dahmg70+4o5HfzHji1CKii1EzthHmL0abtpTWSWEO6tJF68OikY5MpIsoeTZGvgy5cJa7yM+RT6F0QAwgc8bA+L1cBwelZucUuS0kv8O 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: List-Subscribe: List-Unsubscribe: On Wed, Jun 5, 2024 at 6:33=E2=80=AFAM Liam R. Howlett wrote: > > * Matthew Wilcox [240604 20:57]: > > On Tue, Jun 04, 2024 at 05:24:46PM -0700, Andrii Nakryiko wrote: > > > +/* > > > + * find_and_lock_vma_rcu() - Find and lock the VMA for a given addre= ss, or the > > > + * next VMA. Search is done under RCU protection, without taking or = assuming > > > + * mmap_lock. Returned VMA is guaranteed to be stable and not isolat= ed. > > > > You know this is supposed to be the _short_ description, right? > > Three lines is way too long. The full description goes between the > > arguments and the Return: line. Sure, I'll adjust. > > > > > + * @mm: The mm_struct to check > > > + * @addr: The address > > > + * > > > + * Returns: The VMA associated with addr, or the next VMA. > > > + * May return %NULL in the case of no VMA at addr or above. > > > + * If the VMA is being modified and can't be locked, -EBUSY is retur= ned. > > > + */ > > > +struct vm_area_struct *find_and_lock_vma_rcu(struct mm_struct *mm, > > > + unsigned long address) > > > +{ > > > + MA_STATE(mas, &mm->mm_mt, address, address); > > > + struct vm_area_struct *vma; > > > + int err; > > > + > > > + rcu_read_lock(); > > > +retry: > > > + vma =3D mas_find(&mas, ULONG_MAX); > > > + if (!vma) { > > > + err =3D 0; /* no VMA, return NULL */ > > > + goto inval; > > > + } > > > + > > > + if (!vma_start_read(vma)) { > > > + err =3D -EBUSY; > > > + goto inval; > > > + } > > > + > > > + /* > > > + * Check since vm_start/vm_end might change before we lock the VM= A. > > > + * Note, unlike lock_vma_under_rcu() we are searching for VMA cov= ering > > > + * address or the next one, so we only make sure VMA wasn't updat= ed to > > > + * end before the address. > > > + */ > > > + if (unlikely(vma->vm_end <=3D address)) { > > > + err =3D -EBUSY; > > > + goto inval_end_read; > > > + } > > > + > > > + /* Check if the VMA got isolated after we found it */ > > > + if (vma->detached) { > > > + vma_end_read(vma); > > > + count_vm_vma_lock_event(VMA_LOCK_MISS); > > > + /* The area was replaced with another one */ > > > > Surely you need to mas_reset() before you goto retry? > > Probably more than that. We've found and may have adjusted the > index/last; we should reconfigure the maple state. You should probably > use mas_set(), which will reset the maple state and set the index and > long to address. Yep, makes sense, thanks. As for the `unlikely(vma->vm_end <=3D address)` case, I presume we want to do the same, right? Basically, on each retry start from the `address` unconditionally, no matter what's the reason for retry. > > > > > > > + goto retry; > > > + } > >