linux-kernel - Re: [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD mmap

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]

Date:	Thu, 07 Apr 2016 15:20:33 -0600
From:	Toshi Kani <toshi.kani@....com>
To:	Matthew Wilcox <willy@...ux.intel.com>
Cc:	mingo@...nel.org, bp@...e.de, hpa@...or.com, tglx@...utronix.de,
	dan.j.williams@...el.com, kirill.shutemov@...ux.intel.com,
	linux-mm@...ck.org, x86@...nel.org, linux-nvdimm@...ts.01.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86 get_unmapped_area: Add PMD alignment for DAX PMD
 mmap

On Thu, 2016-04-07 at 13:41 -0400, Matthew Wilcox wrote:
> On Wed, Apr 06, 2016 at 11:44:32AM -0600, Toshi Kani wrote:
> > > 
> > > The NVML chooses appropriate addresses and gets a properly aligned
> > > address without any kernel code.
> >
> > An application like NVML can continue to specify a specific address to
> > mmap().  Most existing applications, however, do not specify an address
> > to mmap().  With this patch, specifying an address will remain
> > optional.
>
> The point is that this *can* be done in userspace.  You need to sell us
> on the advantages of doing it in the kernel.

Sure.  As I said, the point is that we do not need to modify existing
applications for using DAX PMD mappings.

For instance, fio with "ioengine=mmap" performs I/Os with mmap().
https://github.com/caius/fio/blob/master/engines/mmap.c

With this change, unmodified fio can be used for testing with DAX PMD
mappings.  There are many examples like this, and I do not think we want to
modify all applications that we want to evaluate/test with.

> > > I think this is the wrong place for it, if we decide that this is the
> > > right thing to do.  The filesystem has a get_unmapped_area() which
> > > should be used instead.
> >
> > Yes, I considered adding a filesystem entry point, but decided going
> > this way because:
> >  - arch_get_unmapped_area() and arch_get_unmapped_area_topdown() are
> > arch-specific code.  Therefore, this filesystem entry point will need
> > arch-specific implementation. 
> >  - There is nothing filesystem specific about requesting PMD alignment.
>
> See http://article.gmane.org/gmane.linux.kernel.mm/149227 for Hugh's
> approach for shmem.  I strongly believe that if we're going to do this
> i the kernel, we should build on this approach, and not hack something
> into each architecture's generic get_unmapped_area.

Thanks for the pointer.  Yes, we can call current->mm->get_unmapped_area()
with size + PMD_SIZE, and adjust with the alignment in a filesystem entry
point.  I will update the patch with this approach.

-Toshi