Re: hugepage: Fix hugepage logic in free_pgtables()

From: 'David Gibson' <>
Date: 2006-03-03 10:00:54
On Thu, Mar 02, 2006 at 01:29:50PM -0800, Chen, Kenneth W wrote:
> Hugh Dickins wrote on Thursday, March 02, 2006 12:27 PM
> > But the first part, || instead of && in is_hugepage_only_range, looks
> > insufficient: the start and end of the range might each fall in a
> > non-huge region, but the range still cross a huge region.
> > 
> > Ah, does RGN_HPAGE nestle up against the TASK_SIZE roof, so any range
> > already tested against TASK_SIZE (as get_unmapped_area has) cannot
> > cross RGN_HPAGE?  If so, perhaps it deserves a comment there.  And
> > if that is so, and can be relied upon, is_hugepage_only_range need
> > only be testing REGION_NUMBER(addr+len-1) - but it does seem fragile.
> There are many address range check before we hit get_unmapped area.
> ia64 can never have a vma range that crosses region boundary.  David
> pointed out earlier that shmat and mremap can still slip through the
> crack and he has a patch that fixed it. But yes, this patch is making
> that assumption (or relying on checks being done properly beforehand).

In fact with that other patch, which ensures that no region-crossing
ranges get through, simply (REGION_NUMBER(addr) == RGN_HPAGE) would be
sufficient; either both start and end are in the hugepage region, or
they're both in the same different region.

David Gibson			| I'll have my music baroque, and my code
david AT	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to
More majordomo info at
Received on Fri Mar 03 10:15:46 2006

This archive was generated by hypermail 2.1.8 : 2006-03-03 10:15:55 EST