Messages in this thread | | | Date | Mon, 21 Mar 2005 14:26:50 -0800 | From | "David S. Miller" <> | Subject | Re: [PATCH 1/5] freepgt: free_pgtables use vma list |
| |
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. :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |