linux-kernel - Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb

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] [day] [month] [year] [list]

Message-Id: <871szcsz2g.fsf@linux.vnet.ibm.com>
Date:   Wed, 19 Oct 2016 10:41:19 +0530
From:   "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Jan Stancek <jstancek@...hat.com>,
        Mike Kravetz <mike.kravetz@...cle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH] mm/hugetlb: Use the right pte val for compare in hugetlb_cow

Andrew Morton <akpm@...ux-foundation.org> writes:

> On Tue, 18 Oct 2016 21:12:45 +0530 "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com> wrote:
>
>> We cannot use the pte value used in set_pte_at for pte_same comparison,
>> because archs like ppc64, filter/add new pte flag in set_pte_at. Instead
>> fetch the pte value inside hugetlb_cow. We are comparing pte value to
>> make sure the pte didn't change since we dropped the page table lock.
>> hugetlb_cow get called with page table lock held, and we can take a copy
>> of the pte value before we drop the page table lock.
>> 
>> With hugetlbfs, we optimize the MAP_PRIVATE write fault path with no
>> previous mapping (huge_pte_none entries), by forcing a cow in the fault
>> path. This avoid take an addition fault to covert a read-only mapping
>> to read/write. Here we were comparing a recently instantiated pte (via
>> set_pte_at) to the pte values from linux page table. As explained above
>> on ppc64 such pte_same check returned wrong result, resulting in us
>> taking an additional fault on ppc64.
>
> From my reading this is a minor performance improvement and a -stable
> backport isn't needed.  But it is unclear whether the impact warrants a
> 4.9 merge.

This patch workaround the issue reported at https://lkml.kernel.org/r/57FF7BB4.1070202@redhat.com
The reason for that OOM was a reserve count accounting issue which
happens in the error path of hugetlb_cow. Not this patch avoid us taking
the error path and hence we don't have the reported OOM.

An actual fix for that issue is being worked on by Mike Kravetz.

>
> Please be careful about describing end-user visible impacts when fixing
> bugs, thanks.

-aneesh