Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [mm 4.15-rc8] Random oopses under memory pressure.
To:     "Kirill A. Shutemov" <kirill@shutemov.name>,
        Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
References: <201801160115.w0G1FOIG057203@www262.sakura.ne.jp>
 <CA+55aFxOn5n4O2JNaivi8rhDmeFhTQxEHD4xE33J9xOrFu=7kQ@mail.gmail.com>
 <201801170233.JDG21842.OFOJMQSHtOFFLV@I-love.SAKURA.ne.jp>
 <CA+55aFyxyjN0Mqnz66B4a0R+uR8DdfxdMhcg5rJVi8LwnpSRfA@mail.gmail.com>
 <201801172008.CHH39543.FFtMHOOVSQJLFO@I-love.SAKURA.ne.jp>
 <201801181712.BFD13039.LtHOSVMFJQFOFO@I-love.SAKURA.ne.jp>
 <20180118122550.2lhsjx7hg5drcjo4@node.shutemov.name>
Cc:     torvalds@linux-foundation.org, kirill.shutemov@linux.intel.com,
        akpm@linux-foundation.org, hannes@cmpxchg.org,
        iamjoonsoo.kim@lge.com, mgorman@techsingularity.net,
        tony.luck@intel.com, vbabka@suse.cz, mhocko@kernel.org,
        aarcange@redhat.com, hillf.zj@alibaba-inc.com, hughd@google.com,
        oleg@redhat.com, peterz@infradead.org, riel@redhat.com,
        srikar@linux.vnet.ibm.com, vdavydov.dev@gmail.com,
        mingo@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        x86@kernel.org
From:   Dave Hansen <dave.hansen@linux.intel.com>
Message-ID: <d8347087-18a6-1709-8aa8-3c6f2d16aa94@linux.intel.com>
Date:   Thu, 18 Jan 2018 06:45:00 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <20180118122550.2lhsjx7hg5drcjo4@node.shutemov.name>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 01/18/2018 04:25 AM, Kirill A. Shutemov wrote:
> [   10.084024] diff: -858690919
> [   10.084258] hpage_nr_pages: 1
> [   10.084386] check1: 0
> [   10.084478] check2: 0
...
> diff --git a/mm/page_vma_mapped.c b/mm/page_vma_mapped.c
> index d22b84310f6d..57b4397f1ea5 100644
> --- a/mm/page_vma_mapped.c
> +++ b/mm/page_vma_mapped.c
> @@ -70,6 +70,14 @@ static bool check_pte(struct page_vma_mapped_walk *pvmw)
>  		}
>  		if (pte_page(*pvmw->pte) < pvmw->page)
>  			return false;
> +
> +		if (pte_page(*pvmw->pte) - pvmw->page) {
> +			printk("diff: %d\n", pte_page(*pvmw->pte) - pvmw->page);
> +			printk("hpage_nr_pages: %d\n", hpage_nr_pages(pvmw->page));
> +			printk("check1: %d\n", pte_page(*pvmw->pte) - pvmw->page < 0);
> +			printk("check2: %d\n", pte_page(*pvmw->pte) - pvmw->page >= hpage_nr_pages(pvmw->page));
> +			BUG();
> +		}

This says that pte_page(*pvmw->pte) and pvmw->page are roughly 4GB away
from each other (858690919*4=0xccba559c0).  That's not the compiler
being wonky, it just means that the virtual addresses of the memory
sections are that far apart.

This won't happen when you have vmemmap or flatmem because the mem_map[]
is virtually contiguous and pointer arithmetic just works against all
'struct page' pointers.  But with classic sparsemem, it doesn't.

You need to make sure that the PFNs are in the same section before you
can do the math that you want to do here.