On Mon, 2005-11-21 at 10:12 -0500, Nick Piggin wrote:
> )
> X-Fetchmail-Warning: recipient address [email protected] didn't match any local name
>
> bad_range is supposed to be a temporary check. It would be a pity to throw
> it out. Make it depend on CONFIG_DEBUG_VM instead.
>
> CONFIG_HOLES_IN_ZONE systems were relying on this to check pfn_valid in
> the page allocator. Add that to page_is_buddy instead.
>
> Signed-off-by: Nick Piggin <[email protected]>
>
> Index: linux-2.6/mm/page_alloc.c
> ===================================================================
> --- linux-2.6.orig/mm/page_alloc.c
> +++ linux-2.6/mm/page_alloc.c
> @@ -81,6 +81,7 @@ int min_free_kbytes = 1024;
> unsigned long __initdata nr_kernel_pages;
> unsigned long __initdata nr_all_pages;
>
> +#ifdef CONFIG_DEBUG_VM
> static int page_outside_zone_boundaries(struct zone *zone, struct page *page)
> {
> int ret = 0;
> @@ -122,6 +123,13 @@ static int bad_range(struct zone *zone,
> return 0;
> }
>
> +#else
> +static inline int bad_range(struct zone *zone, struct page *page)
> +{
> + return 0;
> +}
> +#endif
> +
> static void bad_page(const char *function, struct page *page)
...
> static inline int page_is_buddy(struct page *page, int order)
> {
> +#ifdef CONFIG_HOLES_IN_ZONE
> + if (!pfn_valid(page_to_pfn(page)))
> + return 0;
> +#endif
> +
> if (PagePrivate(page) &&
> (page_order(page) == order) &&
> page_count(page) == 0)
> @@ -320,17 +334,15 @@ static inline void __free_pages_bulk (st
> struct free_area *area;
> struct page *buddy;
>
> - combined_idx = __find_combined_index(page_idx, order);
> buddy = __page_find_buddy(page, page_idx, order);
> -
> - if (bad_range(zone, buddy))
> - break;
> if (!page_is_buddy(buddy, order))
> break; /* Move the buddy up one level. */
I seem to also remember a case with this bad_range() check was useful
for zones that don't have their boundaries aligned on a MAX_ORDER
boundary. Would this change break such a zone? Do we care?
-- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
