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

'David Gibson'
2005-10-27T00:23:04Z

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.