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

["'David Gibson'" <david@gibson.dropbear.id.au>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/