Re: [PATCH 2/3] hugetlb: Use vmf_anon_prepare() instead of anon_vma_prepare()

[Vishal Moola <vishal.moola@gmail.com>]

On Tue, Feb 20, 2024 at 7:46 PM Matthew Wilcox <willy@infradead.org> wrote:
>
> On Tue, Feb 20, 2024 at 03:14:23PM -0800, Vishal Moola (Oracle) wrote:
> > +++ b/mm/hugetlb.c
> > @@ -5834,9 +5834,15 @@ static vm_fault_t hugetlb_wp(struct mm_struct *mm, struct vm_area_struct *vma,
> >       struct folio *old_folio;
> >       struct folio *new_folio;
> >       int outside_reserve = 0;
> > -     vm_fault_t ret = 0;
> > +     vm_fault_t ret = 0, anon_ret = 0;
>
> Do we need a second variable here?  Seems to me like we could
> unconditionally assign to ret:

Hmm, looks like we can directly assign to ret without any problems
in both functions, I'll change that for v2.

> > -     if (unlikely(anon_vma_prepare(vma))) {
> > -             ret = VM_FAULT_OOM;
> > +     anon_ret = vmf_anon_prepare(&vmf);
> > +     if (unlikely(anon_ret)) {
> > +             ret = anon_ret;
>
>
>
> >       unsigned long haddr = address & huge_page_mask(h);
> >       struct mmu_notifier_range range;
> > +     struct vm_fault vmf = {
> > +                             .vma = vma,
> > +                             .address = haddr,
> > +                             .real_address = address,
> > +                             .flags = flags,
> > +     };
>
> We don't usually indent quite so far.  One extra tab would be enough.
>
> Also, I thought we talked about creating the vmf in hugetlb_fault(),
> then passing it to hugetlb_wp() hugetlb_no_page() and handle_userfault()?
> Was there a reason to abandon that idea?

No I haven't abandoned that idea, I intend to have a separate patchset to go
on top of this one - just keeping them separate since they are conceptually
different. I'm converting each function to use struct vm_fault first, then
shifting it to be passed throughout as an arguement while cleaning up the
excess variables laying around. In a sense working bottom-up instead
of top-down.