On Tue, Feb 20, 2024 at 7:46 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> 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.
