On Mon, 21 Mar 2005 20:52:44 +0000 (GMT)
Hugh Dickins <[EMAIL PROTECTED]> 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. :-)
-
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/
