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

[David S. Miller]

On Sat, 26 Feb 2005 11:56:09 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> 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.