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 780FDC48BF8 for ; Thu, 22 Feb 2024 16:13:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C6CB6B0080; Thu, 22 Feb 2024 11:13:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 04FF26B0081; Thu, 22 Feb 2024 11:13:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0B986B0082; Thu, 22 Feb 2024 11:13:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id CE1606B0080 for ; Thu, 22 Feb 2024 11:13:35 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 627C240EA2 for ; Thu, 22 Feb 2024 16:13:35 +0000 (UTC) X-FDA: 81819935190.15.2EEF29F Received: from mail-yw1-f178.google.com (mail-yw1-f178.google.com [209.85.128.178]) by imf04.hostedemail.com (Postfix) with ESMTP id 915944000E for ; Thu, 22 Feb 2024 16:13:32 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=V2MNEtr0; spf=pass (imf04.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708618412; 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=xP4/RDM5HizqveFeK+DZ+kKMIOhU3CKQ9ee/dhSsQmY=; b=xLcGFrObdOUhP9b8fCA3mPtZFL9d4i6UGA2RQpjC3z1Mgi42K0H+9+SkxsvkSHMEaLTiO+ tdkbXXKn8/nkifctRdTl+bFcXoXXzPgpuAw3XhzjQHDuzyVlexEU5icGIV8pq/hCKPEKEw s7WqbJ3Yx8iyW3ZUdSsPbxKzuRlhh9U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708618412; a=rsa-sha256; cv=none; b=E/93ITf0wguH2/CXzYOgCiIPIPghhxnwy6kAtJTYzECPOJQL0oVXb+3ffvcObVMell3JzH s2oykO5M3X8qyCeWLmFCUvBl/fvLhaX0imm6Xbb2m2WdcgDAnSLAvd6PPK0jWHlBMlZL/r 6hHUB6TJVmlbBzSwY6TyCqh+/dqxfuc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=V2MNEtr0; spf=pass (imf04.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.128.178 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-6080a3eecd4so61931627b3.2 for ; Thu, 22 Feb 2024 08:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708618411; x=1709223211; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xP4/RDM5HizqveFeK+DZ+kKMIOhU3CKQ9ee/dhSsQmY=; b=V2MNEtr0DZmV1ktb8QFmuwBdlsGauvP2zWX42t7S9UaeWIihvfk7W51nkL3BXK6Hjn QRyH5cLppDKkKrJ0dCtHl10iu3gXlXyu4sEvwa7s8lVaioWMOc4mUIFXfh4nsJf8GiK7 rmMLlI6EmmfUCu5nmEXvGchCF02LR4oueQfTxckafKdCx5d6o9HbRxJiTNoMhtRuL4Il 85Y1OTG834Cpbaadm751QhEPPl0XmHMucqpWWxsquNBUS2jV8wbeEAbk/zsb9kWbX9hc nI5pr3nZdStnsrXSMClsKWXQCMnC1GaIoX0L4yWhGhlZiG6wpeSNg3XHgBQCG4VAm8Yj j79w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708618411; x=1709223211; 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:message-id:reply-to; bh=xP4/RDM5HizqveFeK+DZ+kKMIOhU3CKQ9ee/dhSsQmY=; b=P4nVa25RX5LDVOSRRlChdl2JFuQa5pkAdyz44cE4JJLLXSWpaCZRaedLbBI/zqWLo4 n+3sBQbP6AE9hjr4EwdTSOM2fY8f22Z05HKbiNNFWy6lupCcgDd56qEBNFxQmD8eVNx1 vQ79VaXMT4Gfp/RcY0PLUcBnBtYp7pGQuazFzqCXZjuZY72T2Wcss6GFvRbzWVWp7Uke FejBq3DQysRAg5OJttqjDEKsKBTgJugnT8ACGpsEgBNPM7VDBJd5QWyAPQsGBqG57b9y i/7KOWmor0iuIQ+8zMmYlIthgXVvTfZ7z/fXNqaIufesZ4sI1Ad4mLkANJoZxX619Mmk TFSw== X-Gm-Message-State: AOJu0YwA+GsgxTKSAoQ4gnXwLjfqgYc2uLfaR3uPF6uhtb5zKEBLrJqS jVcVyazwVE13AMs1BJXgjdIOqzZTpfv14wdUKXTK1+iCds3t7/jvmgcf5nQM+UcmReI37stzlWQ sqr9yZIdB9TiSyK0cZ6hvB/oV84g= X-Google-Smtp-Source: AGHT+IH9kIJeyOpOZVfteyq45DpTp18LDeQptwiIY5qfuBiGUDqngg+AVGxfu1g9bVx8zb/FLJr2XlMnhmBvradAvlg= X-Received: by 2002:a0d:cb15:0:b0:608:b15e:4686 with SMTP id n21-20020a0dcb15000000b00608b15e4686mr345799ywd.16.1708618411559; Thu, 22 Feb 2024 08:13:31 -0800 (PST) MIME-Version: 1.0 References: <20240221234732.187629-1-vishal.moola@gmail.com> <20240221234732.187629-4-vishal.moola@gmail.com> In-Reply-To: From: Vishal Moola Date: Thu, 22 Feb 2024 08:13:20 -0800 Message-ID: Subject: Re: [PATCH v2 3/5] hugetlb: Pass struct vm_fault through to hugetlb_handle_userfault() To: Matthew Wilcox Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, muchun.song@linux.dev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 915944000E X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: x8s8wddfcg968s4ozbfew3rh466r1rpt X-HE-Tag: 1708618412-934386 X-HE-Meta: U2FsdGVkX1+YICJkkLy87ZXLSnxKfI8RXrt2Xao9zcKqBC42ZP4llDjWz6Su7xET182/d1kMRgafGPL+a+LFAHaBhMmK2OTZezx7U220xfD88SYIybQ8oCCSfQCx602PIMyGwxcv7XutfF5FjWHD99fFRSA7UywmpthHRj7JhqztW7MsRybVSBJkQI6HnZaERml2jOaoI7HH083oH4eCWSr8MAoYNG2jmd+jkAlu107phiASDbDP6jdLc7Ge82lkziafJKq9BF80yKanOmxA0K12TYFNBT1D4SjgzyyOTZmyHV5vbEu4LH2IB+v4jsieRQzsHmYceAox9TjkEBpBOzGUE/YHMnJkI2ZISbVi51IkW9BsPTDj1e9rEuQqEd1R9B2nqpEEu7vgfyig0PpTHKeci8wcMpSZOOWtbA5GflZEXz6XKECRJ6qlrywHg7UrGpuBJvn+OhKsgJd1dBCCDpAQJk7i6D5ngLRvpIXlYoux91XNlmTLjd8DmiW+pYGZBOLZBmmRfbYz3CPEh5TaVvHGUtd2hNF8HNKc9RNgQCUo8wawiJ2OL00fj1lixDYBaGj/fXBIBLFWdzjRIMM1QDWfnwfZZHOhwtt0Ulx0FNQzDAthv0wl9AAucld+KRWVm0jaMYGCl90aIG2GojCXaeNt/r3/gyeSP77X14j3k1ZmH1UXAMw7ugJCGPTZ3UVy1pCfE/GWYNMjqCSAqKlIyOA3+dBTMKE83F8F9Wj0njydSGuJhBssdZQysJ/w9mai59l+TvCQb4qqVAup4i+LC8337EVamEuBQDiQ14W/qSyp7+h0AAMORBscC9nZujsbxXm8c+zomr8qbWoliQKUwMkYsMSTonMAB/LOkVSa1L6jIrstnCf+u2IFFZfGO2pdykQ62Z3bxUuoEJVwr7mwm7zyaXLZbl/468Tr68DqiIluWZg9TmMBkFEepjyGuKp+2G8Q5fi8LihONRfa+PK 6OOU7DPg LWMgeASAxa83FXbvXJyHTfHEGB6VAXjaM05ACLdj/CWMr9OuRa3afNkGikuVGK1R8T2D6h6+4GdQDGgrhEp0xMpOqoRiIv9Sdymp2qbJP8KTUP6vOX1RTfGaSetqaHF1hz7/yz4bNxgjyOsz2DvAnrh8wls5p9PLZxQMHqN25+UsOZ4dxw8sZNtkOUkSOK+xJgmtSd/REKFiA16YmEPjmW8/GGt8oIArgKwHN5ta3dtlJjIh5C4A3BLhZqKriMe8pdH96UT3I+ODRnzJtHzxfh0UfM+7P3x6A7N4DJC7qqr/ZhY2UvRWIe4/X21YEasQSechBsM5B6Kn/+hHa1WWQxlDmOoYCNCzpluI6wm7QzuFuGkcftTn1CIpxCtudiHadxOiXohtnpf0BE8B4OPJ+YACneP10/17cwBKII5zFu/kO6fRIv+Tsp5b91ZyiUEH6nYiKK9yh69YyxeyjVjySZi6RVy6S6Cen52yLGdZbvygiW5r7riQgHSjTvs4q4j7UnQ9t 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, Feb 21, 2024 at 7:41=E2=80=AFPM Matthew Wilcox wrote: > > On Wed, Feb 21, 2024 at 03:47:30PM -0800, Vishal Moola (Oracle) wrote: > > Now that hugetlb_fault() has a struct vm_fault, have > > hugetlb_handle_userfault() use it instead of creating one of its own. > > > > This lets us reduce the number of arguments passed to > > hugetlb_handle_userfault() from 7 to 3, cleaning up the code and stack. > > > > Signed-off-by: Vishal Moola (Oracle) > > --- > > mm/hugetlb.c | 38 +++++++++----------------------------- > > 1 file changed, 9 insertions(+), 29 deletions(-) > > I love the look of this ... > > > @@ -6116,7 +6098,8 @@ static vm_fault_t hugetlb_no_page(struct mm_struc= t *mm, > > struct vm_area_struct *vma, > > struct address_space *mapping, pgoff_t idx, > > unsigned long address, pte_t *ptep, > > - pte_t old_pte, unsigned int flags) > > + pte_t old_pte, unsigned int flags, > > + struct vm_fault *vmf) > > Should we remove vma, address, idx and flags? Yes, I'm going to do that in another patchset, this one is mainly about enabling hugetlb_fault() to work safely under the VMA lock. It will make it easier to debug if any substitution goes wrong somewhere as well. We may also be able to remove one (or more) of the pte_t arguments, but I have to look into that more.