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 9E151CD1284 for ; Thu, 4 Apr 2024 19:32:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 314586B0098; Thu, 4 Apr 2024 15:32:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C4916B0099; Thu, 4 Apr 2024 15:32:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18BE66B009A; Thu, 4 Apr 2024 15:32:25 -0400 (EDT) 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 EF1116B0098 for ; Thu, 4 Apr 2024 15:32:24 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 7A00112029E for ; Thu, 4 Apr 2024 19:32:24 +0000 (UTC) X-FDA: 81972845808.21.1DB8E07 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf18.hostedemail.com (Postfix) with ESMTP id ACF241C0013 for ; Thu, 4 Apr 2024 19:32:22 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=IhYeRkJe; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712259142; 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=1QF7YfDkyhTCu/FPW6+EBtGcxT+kvR7RnrsjI6gQgsU=; b=Qn5S2pJ9FE5WfoK3kEMfefvCv0xY3byUsOUa3ocgnvA193l11rJrWAALnALC62kZTLrJ6K crGVBTTog0MufYAOYP9dj4h6UAmoq6lCEzx+djZONvqQuEJkJk5dxwtkKL8M8WrjmF+VQ6 v93/44PHQe2gqrDOFiWDbI0ZH5JJwjU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=IhYeRkJe; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712259142; a=rsa-sha256; cv=none; b=UfpGdlErXMJk22TN5ZvgV5t9e/rqdxhcjyuc0Z51a+ERuJpCJmNJcUJKrpcIiT6QwXXlBY FWramDjW+IttgTIs2xZdBJ7Jo4wHZd1tdEx+AWA0oegORvQZUx/lnIuIEm3B8bq5fNVrCV jVXYWxuxD6hNwjAzxwWvG/RRuUB+C2o= Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-d9b9adaf291so1520613276.1 for ; Thu, 04 Apr 2024 12:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712259142; x=1712863942; 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=1QF7YfDkyhTCu/FPW6+EBtGcxT+kvR7RnrsjI6gQgsU=; b=IhYeRkJeVFAgzFHUg7XRVDQM2Rv+kgRVmp147H2Uvc6HNQDKsVLtlIuw8jqh/dtpPI 2oArqWb3KkEVepe5cvgSXgp9R7bQIpNbrK1BuCXqSiAyirPeEi+P5pEIJlyhVTMCCJgH rc2e3bAwgFG7R3QBwSTaEXQvRVkTJESbojw75vETKYTx3ZsY1i8k8cm3WWPzHJBfGc0P e0RcVn0FPMCj4NUTUhADntutUTlSsBkL3k6OESmJb/7UAtAiN0ZOua5p3H29jJ6aCVAl A27vZXEX/DpLsTb6yQ1uvGWsS5F5bu6m8H3B/4ZJAwZsb6a9eab1tVrGaivVKLxcuQu4 0Nqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712259142; x=1712863942; 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=1QF7YfDkyhTCu/FPW6+EBtGcxT+kvR7RnrsjI6gQgsU=; b=Epav4Rg3ch2pvjXOuWEma0T4fmpJXpI3EtZI/Gw4sgspuyt25zjX0924uTLH2PCw/F EntrxrpFsFJqjxpxfWygg/v2+RdUjQpzHMMLHR5IcJ+lse83OznpfRzn6YEg9CU45k2U nc51FJsKz7+vAsK4e77RpaMwQgIZJd5z7izoD0LTrPqDdoU5cchDw2OgMD1Hsqybl+lF sDa09kLtCCxhyS9Uk32c9M7nzSLd7kIzC1xOYbyO9/h2pfZm3rkQGKZHGZt3VBuziS1p 1AzCbecL+2c0QJnLB7WXoqG5vxgAyNK9Zr9qDXPWnoE4r4cqWv/2MWFYiIVT5XLClCOO V0PQ== X-Gm-Message-State: AOJu0YyCbZ7t8d781QKkx+DuM90ehrvnijqehcKlpfLC+HLIx1h2Wlx1 QynV+Nkk2ceq9s7NC2gJ4/+iwTJeQ4nmJLskxSvjR4KjEbVmC2UNmUrNpsPc3zb3BtwH9ZczIYO LOT8MXFdGrsiL0DQQItbk27fRRFQ= X-Google-Smtp-Source: AGHT+IHu0tf3wBJpfd3UyhX93ctSlHSzZkIbY7hMSDwDS6Q0n1uGqbYHK48drdtAqk3f12AmqnbitdryFo4MfkssZfc= X-Received: by 2002:a25:8b81:0:b0:dcc:7131:ad4a with SMTP id j1-20020a258b81000000b00dcc7131ad4amr2943771ybl.62.1712259141645; Thu, 04 Apr 2024 12:32:21 -0700 (PDT) MIME-Version: 1.0 References: <20240401202651.31440-1-vishal.moola@gmail.com> <20240401202651.31440-2-vishal.moola@gmail.com> In-Reply-To: From: Vishal Moola Date: Thu, 4 Apr 2024 12:32:11 -0700 Message-ID: Subject: Re: [PATCH v2 1/3] hugetlb: Convert hugetlb_fault() to use struct vm_fault To: Oscar Salvador Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, muchun.song@linux.dev, willy@infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: ACF241C0013 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: sawwrwzc5t5gbbhpyohk9a7n9bzgk8yd X-HE-Tag: 1712259142-579781 X-HE-Meta: U2FsdGVkX1+OTy51GEWCUI0WV8lb/Fd62aHIAbb4pkK94Y/MH8tt1IZXPQi0G+XrBdZIsQ1rmT3kuz+KYFAn3W6hoOLVygW+gp7ZWT4dIup0yzbeD4cdXTkdUTyb25MFMACnzLSxe4838ZYeIcGApxnySwMjhpARk1DU0UoCXXM6DeKk+Z04nC59gXSJHx9gJ+/f/+fG7uETAMT0OElnD9Eyu9FJ2d009GVl1exArYGVNW6HSch5zAXXF+nUfrQ32PF2AB1Wg4C5x+GCtewcdaM4IUfGQ5mOKWr8tEN+fnt2O8l7oEZ8CH3E/vp32C7hLwu3mCkOS6XrRTp3rB5i7oc7saS4kgpH3JMqx7AEvVaJHrHV6oTXjncg49SghlE908N6dGTrKrYtUHv7EDbRVvrlcK26xFDUeOtmnIW8abAZYl2H0u2MMH8m4CMLkIUn5/UQ9Ickue4UW4PEXMr7XLU56N5e0hsgtFdFxJWb9UgGgBWY7jjoPAJhq6Sb6KUQmo0Ltd0o0SAttmp8APclcLttOr0a7K112Gc/JY1i6fi9Jc5+BE/8F0bSzvk7ZaB80pAkgUw42YpDQeSCLRwqHd79ebaiVcinVwl4K9yvH0GMMAB1u0ybNPpFentISRFn4m+J9fIjE4J1q5q0rnFqYJgsE7xiYLyrbaldv9RVAY5j0vxC4x2T71um9CE/u283K5F8zseZmQuqq4+gEEiaBvUmQSOBG+j+WB+QqHybXNOyuU/QF+EEB+Iz9V0gahnvxvDZ538u3zvqWKswh//cR4wW2BwkQ5Nff3uCFGTjM1X6I0k02uE/xlSMT8YtXkcJB5FhNh4vdAZBhFnUneG8nQBhqREiDa0BhmGl50GNXEWhzKjAivqb0k7/2lzi4w6FjhVkUOVGv+tJQ1SPNK/OUwanRoQ6ymbduFob+zuFHtC3GqkYidcJNt8s7gvz+h5VPdwSY6E0W6l9U9kBg4U KW6dUdqQ h7orVybu49DSHAeuTiQsTVD6PACo6Ev5LHRjxcq5gFuVI5y8Ms/Ig2Dkdxfa+eoEFDW1NpjnGDj1Xtm9o1JLc/kYxd2myCPcbkdF7k5Rz4YADL2NWBL56xnsHTguF4K+08zPQdgta2Dq4++eZzkUz3pV4yznJ4psFwIPP8Bs4MjVRBM6Glh2TfVtt1Sh0DRrXD6ogwUagtvWrYTCNMMbcGNZju/UhfquOw7DsRsoV1z3XTpTXRBA01whT4283cycDzSv3RuFF7pvW7J/saUQS8NBMp40d+MDu5WUUaj9r6vaann7sa3Rm+ty42Dck0pvzATVnFbNu6c9FSaCoDBADPEVd2GBqVubdyTaxtqLVqqQfq1M= 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 Thu, Apr 4, 2024 at 5:26=E2=80=AFAM Oscar Salvador w= rote: > > On Mon, Apr 01, 2024 at 01:26:49PM -0700, Vishal Moola (Oracle) wrote: > > Now that hugetlb_fault() has a vm_fault available for fault tracking, u= se > > it throughout. This cleans up the code by removing 2 variables, and > > prepares hugetlb_fault() to take in a struct vm_fault argument. > > > > Signed-off-by: Vishal Moola (Oracle) > > Reviewed-by: Oscar Salvador > > A question below: > > > mm/hugetlb.c | 84 +++++++++++++++++++++++++--------------------------- > > 1 file changed, 41 insertions(+), 43 deletions(-) > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > index 8267e221ca5d..360b82374a89 100644 > > --- a/mm/hugetlb.c > > +++ b/mm/hugetlb.c > ... > > /* > > - * entry could be a migration/hwpoison entry at this point, so th= is > > - * check prevents the kernel from going below assuming that we ha= ve > > - * an active hugepage in pagecache. This goto expects the 2nd pag= e > > - * fault, and is_hugetlb_entry_(migration|hwpoisoned) check will > > - * properly handle it. > > + * vmf.orig_pte could be a migration/hwpoison vmf.orig_pte at thi= s > > "vmf.orig_pte could be a migration/hwpoison entry at ..." > > > - entry =3D pte_mkyoung(entry); > > - if (huge_ptep_set_access_flags(vma, haddr, ptep, entry, > > + vmf.orig_pte =3D pte_mkyoung(vmf.orig_pte); > > + if (huge_ptep_set_access_flags(vma, vmf.address, vmf.pte, vmf.ori= g_pte, > > flags & FAULT_FLAG_WRITE)= ) > > Would it make sense to teach huge_ptep_set_access_flags/set_huge_pte_at()= to use > vm_fault struct as well? All info we are passing is stored there. > Maybe it is not worth the trouble though, just asking. Yeah, it makes sense. There are actually many function calls in the hugetlb_fault() and __handle_mm_fault() pathways that could make use of vm_fault to clean up the stack. It's not particularly complicated either, aside from reorganizing some variables for every implementation of each function. I'm not really sure if it's worth dedicated effort and churn though (at least I'm not focused on that for now).