Re: [PATCH 1/5] freepgt: free_pgtables use vma list

["David S. Miller" <davem@davemloft.net>]

On Mon, 21 Mar 2005 20:52:44 +0000 (GMT)
Hugh Dickins <hugh@veritas.com> wrote:

Hugh, I'm getting some problems on sparc64 here:

> +static inline void free_pgd_range(struct mmu_gather *tlb,
> +			unsigned long addr, unsigned long end,
> +			unsigned long floor, unsigned long ceiling)
>  {
>  	pgd_t *pgd;
>  	unsigned long next;
> +	unsigned long start;
>  
> +	addr &= PMD_MASK;
> +	if (addr < floor) {
> +		addr += PMD_SIZE;
> +		if (!addr)
> +			return;
> +	}
> +	ceiling &= PMD_MASK;
> +	if (addr > ceiling - 1)
> +		return;
> +
> +	start = addr;
>  	pgd = pgd_offset(tlb->mm, addr);
>  	do {
>  		next = pgd_addr_end(addr, end);
>  		if (pgd_none_or_clear_bad(pgd))
>  			continue;
> -		clear_pud_range(tlb, pgd, addr, next);
> +		free_pud_range(tlb, pgd, addr, next, floor, ceiling);
>  	} while (pgd++, addr = next, addr != end);
> +
> +	if (!tlb_is_full_mm(tlb))
> +		flush_tlb_pgtables(tlb->mm, start, end);
> +}

flush_tlb_pgtables() on sparc64 has a BUG() check which
is basically:

	BUG((long)start > (long)end);

This catches two cases of bogus arguments:

1) start --> end straddles sparc64 address space hole
2) start > end

With your changes, this triggers on even the first user
process execution.  Specifically I get the first
trap with start=0x70800000 and end=0x70188000.  (these
addresses are in the region where generally 32-bit tasks
get their non-fixed mmap() requests satisfied, so these
are probably shared library chunks).

I think the VMA gathering optimization one level up in
free_pgtables() has some logic error in it.   Maybe...

I'll try to figure out what exactly is going on, but
perhaps you can spot it before me. :-)