From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932461AbeAROpD (ORCPT ); Thu, 18 Jan 2018 09:45:03 -0500 Received: from mga09.intel.com ([134.134.136.24]:18027 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756459AbeAROpC (ORCPT ); Thu, 18 Jan 2018 09:45:02 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,378,1511856000"; d="scan'208";a="20779154" Subject: Re: [mm 4.15-rc8] Random oopses under memory pressure. To: "Kirill A. Shutemov" , Tetsuo Handa References: <201801160115.w0G1FOIG057203@www262.sakura.ne.jp> <201801170233.JDG21842.OFOJMQSHtOFFLV@I-love.SAKURA.ne.jp> <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 Message-ID: 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.