Received-SPF: pass (google.com: domain of linux-kernel+bounces-76863-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240221234732.187629-1-vishal.moola@gmail.com>
 <20240221234732.187629-4-vishal.moola@gmail.com> <ZdbCfLo85Gi_a7OI@casper.infradead.org>
In-Reply-To: <ZdbCfLo85Gi_a7OI@casper.infradead.org>
From: Vishal Moola <vishal.moola@gmail.com>
Date: Thu, 22 Feb 2024 08:13:20 -0800
Message-ID: <CAOzc2py0YtAbE0GmvYROvD=DzYACHAGs0uZzFdRkPO10CATCJQ@mail.gmail.com>
Subject: Re: [PATCH v2 3/5] hugetlb: Pass struct vm_fault through to hugetlb_handle_userfault()
To: Matthew Wilcox <willy@infradead.org>
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

On Wed, Feb 21, 2024 at 7:41=E2=80=AFPM Matthew Wilcox <willy@infradead.org=
> 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) <vishal.moola@gmail.com>
> > ---
> >  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.