Re: RFC: Cleanup / small fixes to hugetlb fault handling

From: 'David Gibson'
Date: Wed Oct 26 2005 - 19:23:18 EST


On Wed, Oct 26, 2005 at 05:16:39PM -0700, Chen, Kenneth W wrote:
> David Gibson wrote on Wednesday, October 26, 2005 5:05 PM
> > On Wed, Oct 26, 2005 at 11:44:52AM -0700, Chen, Kenneth W wrote:
> > > David Gibson wrote on Tuesday, October 25, 2005 7:49 PM
> > > > +int hugetlb_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> > > > + unsigned long address, int write_access)
> > > > +{
> > > > + pte_t *ptep;
> > > > + pte_t entry;
> > > > +
> > > > + ptep = huge_pte_alloc(mm, address);
> > > > + if (! ptep)
> > > > + /* OOM */
> > > > + return VM_FAULT_SIGBUS;
> > > > +
> > > > + entry = *ptep;
> > > > +
> > > > + if (pte_none(entry))
> > > > + return hugetlb_no_page(mm, vma, address, ptep);
> > > > +
> > > > + /* we could get here if another thread instantiated the pte
> > > > + * before the test above */
> > > > +
> > > > + return VM_FAULT_SIGBUS;
> > > > }
> > >
> > > Are you sure about the last return? Looks like a typo to me, if *ptep
> > > is present, it should return VM_FAULT_MINOR.
> >
> > Oops, yes, thinko. Corrected patch shortly.
>
> While you at it, I think it would be preferable that the first return be
> VM_FAULT_OOM, your thoughts?

I wondered about that. Logically it is an OOM, but I was just a bit
worried about a hugepage event triggering off an OOM and killing
unrelated processes. I guess it is actually a shortage of normal
pages, not hugepages here, so it should be ok, or at least as ok as an
OOM can ever be.

--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/people/dgibson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/