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

[Hugh Dickins <hugh@veritas.com>]

On Mon, 21 Mar 2005, David S. Miller wrote:
> On Tue, 22 Mar 2005 15:14:54 +1100
> Nick Piggin <nickpiggin@yahoo.com.au> 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