linux-kernel - Re: [RFC PATCH 1/7] x86, mm: ZONE

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:	Fri, 21 Aug 2015 11:15:12 -0400
From:	Jerome Glisse <j.glisse@...il.com>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	Christoph Hellwig <hch@....de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Boaz Harrosh <boaz@...xistor.com>,
	Rik van Riel <riel@...hat.com>,
	"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	david <david@...morbit.com>, Ingo Molnar <mingo@...nel.org>,
	Linux MM <linux-mm@...ck.org>, Ingo Molnar <mingo@...hat.com>,
	Mel Gorman <mgorman@...e.de>, "H. Peter Anvin" <hpa@...or.com>,
	Ross Zwisler <ross.zwisler@...ux.intel.com>,
	"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
	David Woodhouse <dwmw2@...radead.org>
Subject: Re: [RFC PATCH 1/7] x86, mm: ZONE_DEVICE for "device memory"

On Fri, Aug 21, 2015 at 08:02:51AM -0700, Dan Williams wrote:
> [ Adding David Woodhouse ]
> 
> On Sat, Aug 15, 2015 at 1:59 AM, Christoph Hellwig <hch@....de> wrote:
> > On Fri, Aug 14, 2015 at 02:52:15PM -0700, Dan Williams wrote:
> >> The idea is that this memory is not meant to be available to the page
> >> allocator and should not count as new memory capacity.  We're only
> >> hotplugging it to get struct page coverage.
> >
> > This might need a bigger audit of the max_pfn usages.  I remember
> > architectures using it as a decisions for using IOMMUs or similar.
> 
> We chatted about this at LPC yesterday.  The takeaway was that the
> max_pfn checks that the IOMMU code does is for checking whether a
> device needs an io-virtual mapping to reach addresses above its DMA
> limit (if it can't do 64-bit DMA).  Given the capacities of persistent
> memory it's likely that a device with this limitation already can't
> address all of RAM let alone PMEM.   So it seems to me that updating
> max_pfn for PMEM hotplug does not buy us anything except a few more
> opportunities to confuse PMEM as typical RAM.

I think it is wrong do not update max_pfn for 3 reasons :
  - In some case your PMEM memory will end up below current max_pfn
    value so device doing DMA can confuse your PMEM for regular RAM.
  - Given the above, not updating PMEM means you are not consistant,
    ie on some computer PMEM will be DMA addressable by device and
    on other computer it would not. Because different RAM and PMEM
    configuration, different bios, ... that cause max_pfn to be below
    range where PMEM get hotpluged.
  - Last why would we want to block device to access PMEM directly ?
    Wouldn't it make sense for some device like say network to read
    PMEM directly and stream it over the network ? All this happening
    through IOMMU (i am assuming PCIE network card using IOMMU). Which
    imply having the IOMMU consider this like regular mapping (ignoring
    Will Davis recent patchset here that might affect the IOMMU max_pfn
    test).

Cheers,
Jérôme
--
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/