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

David S. Miller
2005-03-21T22:35:39Z

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. :-)