linux-kernel - Re: [PATCH v4 RESEND 0/2] Align mmap address for DAX pmd mappings

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: <1473376846.2092.69.camel@hpe.com>
Date:   Thu, 8 Sep 2016 23:21:46 +0000
From:   "Kani, Toshimitsu" <toshi.kani@....com>
To:     "kirill@...temov.name" <kirill@...temov.name>
CC:     "hughd@...gle.com" <hughd@...gle.com>,
        "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "adilger.kernel@...ger.ca" <adilger.kernel@...ger.ca>,
        "mike.kravetz@...cle.com" <mike.kravetz@...cle.com>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "mawilcox@...rosoft.com" <mawilcox@...rosoft.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "ross.zwisler@...ux.intel.com" <ross.zwisler@...ux.intel.com>,
        "tytso@....edu" <tytso@....edu>,
        "david@...morbit.com" <david@...morbit.com>,
        "jack@...e.cz" <jack@...e.cz>
Subject: Re: [PATCH v4 RESEND 0/2] Align mmap address for DAX pmd mappings

On Thu, 2016-09-08 at 07:48 -0600, Kani, Toshimitsu wrote:
> On Thu, 2016-09-08 at 13:57 +0300, Kirill A. Shutemov wrote:
> > 
> > On Mon, Aug 29, 2016 at 10:00:43PM +0000, Kani, Toshimitsu wrote:
 :
> > > 
> > > Looking further, these shmem_huge handlings only check pre-
> > > conditions.  So, we should be able to make shmem_get_unmapped_are
> > > a() as a wrapper, which checks such shmem-specific conitions, and
> > > then call __thp_get_unmapped_area() for the actual work.  All
> > > DAX-specific checks are performed in thp_get_unmapped_area() as
> > > well.  We can make  __thp_get_unmapped_area() as a common
> > > function.
> > > 
> > > I'd prefer to make such change as a separate item,
> > 
> > Do you have plan to submit such change?
> 
> Yes, I will submit the change once I finish testing.

I found a bug in the current code, and need some clarification.  The
if-statement below is reverted.

===
diff --git a/mm/shmem.c b/mm/shmem.c
index fd8b2b5..aec5b49 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1980,7 +1980,7 @@ unsigned long shmem_get_unmapped_area(struct file
*file,
                                return addr;
                        sb = shm_mnt->mnt_sb;
                }
-               if (SHMEM_SB(sb)->huge != SHMEM_HUGE_NEVER)
+               if (SHMEM_SB(sb)->huge == SHMEM_HUGE_NEVER)
                        return addr;
        }
===

Because of this bug, mounting tmpfs with "huge=never" enables huge page
mappings, and "huge=always" or others disables it...

The above simple change will change the default behavior, though.  When
"huge=" option is not specified, SHMEM_SB(sb)->huge is set to zero,
which is SHMEM_HUGE_NEVER.  Therefore, huge page mappings are enabled
by default because of this bug.

What's the intended default behavior of this feature?

Thanks,
-Toshi