On Sat, Mar 26, 2005 at 11:35:30AM +0000, Russell King wrote: > In this case, we have a page which must be kept mapped at virtual address > 0, which means the first entry in the L1 page table must always exist. > However, user threads start from 0x8000, which is also mapped via the > first entry in the L1 page table. > > At a guess, I'd imagine that we're freeing the first L1 page table entry, > thereby causing mm->nr_ptes to become -1. > > I'll do some debugging and try to work out if that (or exactly what's) > going on.
Ok. What's happening is that the ARM pgd_alloc uses pte_alloc_map() to allocate the first L1 page table. This sets mm->nr_ptes to be one. The ARM free_pgd knows about this, and will free this PTE at the appropriate time. However, exit_mmap() doesn't know about this itself, so in the ARM case, it should BUG_ON(mm->nr_ptes != 1) if we're using low vectors. I guess we could hack it such that the ARM pgd_alloc decrements mm->nr_ptes itself to keep things balanced, since free_pte_range() won't be called for this pte. However, I don't like that because its likely to break at some point in the future. Any ideas how to cleanly support this with the new infrastructure? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 Serial core - 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/
