Re: [PATCH] set_pte() part 2 arch usage

["David S. Miller" <davem@davemloft.net>]

On Sat, 26 Feb 2005 11:56:09 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Fri, 2005-02-25 at 10:37 -0800, David S. Miller wrote:
> > I bet the address arg is incorrect in some case.
> 
> Yes, probably. That's the same symptoms we had when zeromap_pud_range
> had the bug getting the address wrong, which means we fail to properly
> flush the hash & TLB for this PTE. I'm not at work (it's sat. already
> here :) but I'll have a look asap.

I added the debugging I suggested and did some runs on sparc64.

There are many pte level looping constructs of the form:

	pte = ...(pmd, address);
	address &= ~PMD_MASK;
	end = address + size;
	if (end > PMD_SIZE)
		end = PMD_SIZE;

	some_loop() {
		...
		set_pte_at(mm, address, pte);
		address += PAGE_SIZE;
		pte++;
		...
	}

This "address" mask screws everything up.

I know of at least three such cases so far, vmalloc.c:unmap_area_pte(),
vmalloc.c:map_area_pte(), and mprotect.c:change_pte_range()

The latter could definitely explain the behavior you are seeing on
ppc64.