On Mon, 21 Mar 2005, David S. Miller wrote: > On Tue, 22 Mar 2005 15:14:54 +1100 > Nick Piggin <[EMAIL PROTECTED]> wrote: > > > Question, Dave: flush_tlb_pgtables after Hugh's patch is also > > possibly not being called with enough range to cover all page > > tables that have been freed.
Good question from Nick. > > For example, you may have a single page (start,end) address range > > to free, but if this is enclosed by a large enough (floor,ceiling) > > then it may free an entire pgd entry. > > > > I assume the intention of the API would be to provide the full > > pgd width in that case? > > It just wants the range of page tables liberated. I guess > essentially PMD_SIZE is the granularity. I _think_ that answer means that my current code is fine in this respect. But I'm not entirely convinced. Since sparc64 is the only architecture which implements a flush_tlb_pgtables which actually uses start,end, we do need to suit your needs there - informed reassurance welcome! > Anyways, for the record I made it only call flush_tlb_pgtables() > when end > start, Fine. The patch I just sent, moving the tests, is how I'd like it to be fixed finally, but what you've done in the interim should do fine. > but instead of that BUG() I now get the BUG() > on mm->nr_ptes being non-zero at the end of exit_mmap(). And no way would your change be causing this. Oh dear. > Something is up with the floor/ceiling stuff methinks. Seems so. I did have an off-by-one originally, but that version never leaked out. > It's funny since this code aparently works fine on ia64 which > is fully 3-level too. Hmm... Yes, odd. I'll have to have another think later on. Hugh - 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/
