linux-kernel - Re: [mm 4.15-rc8] Random oopses under memory pressure.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b02e08bb-b551-e239-6f30-1db4587850c8@linux.intel.com>
Date:   Thu, 18 Jan 2018 06:51:37 -0800
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        torvalds@...ux-foundation.org, kirill.shutemov@...ux.intel.com,
        akpm@...ux-foundation.org, hannes@...xchg.org,
        iamjoonsoo.kim@....com, mgorman@...hsingularity.net,
        tony.luck@...el.com, vbabka@...e.cz, mhocko@...nel.org,
        aarcange@...hat.com, hillf.zj@...baba-inc.com, hughd@...gle.com,
        oleg@...hat.com, peterz@...radead.org, riel@...hat.com,
        srikar@...ux.vnet.ibm.com, vdavydov.dev@...il.com,
        mingo@...nel.org, linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        x86@...nel.org
Subject: Re: [mm 4.15-rc8] Random oopses under memory pressure.

On 01/18/2018 06:45 AM, Kirill A. Shutemov wrote:
> On Thu, Jan 18, 2018 at 06:38:10AM -0800, Dave Hansen wrote:
>> On 01/18/2018 05:12 AM, Kirill A. Shutemov wrote:
>>> -		if (pte_page(*pvmw->pte) - pvmw->page >=
>>> -				hpage_nr_pages(pvmw->page)) {
>> Is ->pte guaranteed to map a page which is within the same section as
>> pvmw->page?  Otherwise, with sparsemem (non-vmemmap), the pointer
>> arithmetic won't work.
> No, it's not guaranteed. It can be arbitrary page.
> 
> The arithmetic won't work because they are different "memory objects"?

No, because sections' mem_map[]s can be allocated non-contiguously.
Section 1's might be a lower virtual address than Section 0's.

They're allocated not unlike this:

	mem_section[0]->section_mem_map = kmalloc(SECTION_SIZE);
	mem_section[1]->section_mem_map = kmalloc(SECTION_SIZE);
	...

The first pfn in section 1 and the last pfn in section 0 are adjacent
PFNs, but their 'struct page' might have virtual addresses that are TB
apart.