linux-kernel - Re: could you clarify mm/mempolicy: fix !vma in new_vma

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: <CAA_GA1csMEhSYmeS7qgDj7h=Xh2WrsYvirkS55W4Jj3LTHy87A@mail.gmail.com>
Date:	Tue, 7 Jan 2014 13:29:31 +0800
From:	Bob Liu <lliubbo@...il.com>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	Wanpeng Li <liwanp@...ux.vnet.ibm.com>,
	Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
	Bob Liu <bob.liu@...cle.com>, Linux-MM <linux-mm@...ck.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: could you clarify mm/mempolicy: fix !vma in new_vma_page()

On Mon, Jan 6, 2014 at 10:18 PM, Michal Hocko <mhocko@...e.cz> wrote:
> On Mon 06-01-14 20:45:54, Bob Liu wrote:
> [...]
>>  544         if (PageAnon(page)) {
>>  545                 struct anon_vma *page__anon_vma = page_anon_vma(page);
>>  546                 /*
>>  547                  * Note: swapoff's unuse_vma() is more efficient with this
>>  548                  * check, and needs it to match anon_vma when KSM is active.
>>  549                  */
>>  550                 if (!vma->anon_vma || !page__anon_vma ||
>>  551                     vma->anon_vma->root != page__anon_vma->root)
>>  552                         return -EFAULT;
>>  553         } else if (page->mapping && !(vma->vm_flags & VM_NONLINEAR)) {
>>  554                 if (!vma->vm_file ||
>>  555                     vma->vm_file->f_mapping != page->mapping)
>>  556                         return -EFAULT;
>>  557         } else
>>  558                 return -EFAULT;
>>
>> That's the "other conditions" and the reason why we can't use
>> BUG_ON(!vma) in new_vma_page().
>
> Sorry, I wasn't clear with my question. I was interested in which of
> these triggered and why only for hugetlb pages?
>

Sorry I didn't analyse the root cause. They are several checks in
page_address_in_vma() so I think it might be not difficult to hit one
of them. For example, if the page was mapped to vma by nonlinear
mapping?
Anyway, some debug code is needed to verify what really happened here.

alloc_page_vma() can handle the vma=NULL case while
alloc_huge_page_noerr() can't, so we return NULL instead of call down
to alloc_huge_page().

-- 
Regards,
--Bob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/