linux-kernel - Re: [HMM v13 06/18] mm/ZONE_DEVICE/unaddressable: add special swap for unaddressable

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]

Date:   Thu, 24 Nov 2016 08:56:23 -0500
From:   Jerome Glisse <jglisse@...hat.com>
To:     Anshuman Khandual <khandual@...ux.vnet.ibm.com>
Cc:     akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, John Hubbard <jhubbard@...dia.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Ross Zwisler <ross.zwisler@...ux.intel.com>
Subject: Re: [HMM v13 06/18] mm/ZONE_DEVICE/unaddressable: add special swap
 for unaddressable

On Tue, Nov 22, 2016 at 10:18:27AM +0530, Anshuman Khandual wrote:
> On 11/21/2016 06:12 PM, Jerome Glisse wrote:
> > On Mon, Nov 21, 2016 at 04:28:04PM +0530, Anshuman Khandual wrote:
> >> On 11/18/2016 11:48 PM, Jérôme Glisse wrote:
> >>> To allow use of device un-addressable memory inside a process add a
> >>> special swap type. Also add a new callback to handle page fault on
> >>> such entry.
> >>
> >> IIUC this swap type is required only for the mirror cases and its
> >> not a requirement for migration. If it's required for mirroring
> >> purpose where we intercept each page fault, the commit message
> >> here should clearly elaborate on that more.
> > 
> > It is only require for un-addressable memory. The mirroring has nothing to do
> > with it. I will clarify commit message.
> 
> One thing though. I dont recall how persistent memory ZONE_DEVICE
> pages are handled inside the page tables, point here is it should
> be part of the same code block. We should catch that its a device
> memory page and then figure out addressable or not and act
> accordingly. Because persistent memory are CPU addressable, there
> might not been special code block but dealing with device pages 
> should be handled in a more holistic manner.

Before i repost updated patchset i should stress that dealing with un-addressable
device page and addressable one in same block is not do-able without re-doing once
again the whole mm page fault code path. Because i use special swap entry the 
logical place for me to handle it is with where swap entry are handled.

Regular device page are handle bit simpler that other page because they can't be
evicted/swaped so they are always present once faulted. I think right now they
are always populated through fs page fault callback (well dax one).

So not much reasons to consolidate all device page handling in one place. We are
looking at different use case in the end.

Cheers,
Jérôme