| 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
| ||
|
Date: Mon, 16 Jan 2017 11:31:39 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: Jerome Glisse <jglisse@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Linux MM <linux-mm@...ck.org>,
John Hubbard <jhubbard@...dia.com>,
Ross Zwisler <ross.zwisler@...ux.intel.com>
Subject: Re: [HMM v16 04/15] mm/ZONE_DEVICE/unaddressable: add support for
un-addressable device memory v2
On Mon, Jan 16, 2017 at 7:17 AM, Jerome Glisse <jglisse@...hat.com> wrote:
> On Sun, Jan 15, 2017 at 11:05:43PM -0800, Dan Williams wrote:
>> On Thu, Jan 12, 2017 at 8:30 AM, Jérôme Glisse <jglisse@...hat.com> wrote:
>> > This add support for un-addressable device memory. Such memory is hotpluged
>> > only so we can have struct page but we should never map them as such memory
>> > can not be accessed by CPU. For that reason it uses a special swap entry for
>> > CPU page table entry.
>> >
>> > This patch implement all the logic from special swap type to handling CPU
>> > page fault through a callback specified in the ZONE_DEVICE pgmap struct.
>> >
>> > Architecture that wish to support un-addressable device memory should make
>> > sure to never populate the kernel linar mapping for the physical range.
>> >
>> > This feature potentially breaks memory hotplug unless every driver using it
>> > magically predicts the future addresses of where memory will be hotplugged.
>> >
>> > Changed since v1:
>> > - Add unaddressable memory resource descriptor enum
>> > - Explain why memory hotplug can fail because of un-addressable memory
>>
>> How can we merge this with a known potential regression?
>
> This only affect people using HMM it does not affect people that do not
> use it. Like i said for time being people that want HMM are ok with that.
> I haven't look yet on how to allow struct page about MAX_PHYSMEM_BITS
>
>>
>> >
>> > Signed-off-by: Jérôme Glisse <jglisse@...hat.com>
>> > Cc: Dan Williams <dan.j.williams@...el.com>
>> > Cc: Ross Zwisler <ross.zwisler@...ux.intel.com>
>> > ---
>> > drivers/dax/pmem.c | 4 +--
>> > drivers/nvdimm/pmem.c | 6 ++--
>> > fs/proc/task_mmu.c | 10 +++++-
>> > include/linux/ioport.h | 1 +
>> > include/linux/memory_hotplug.h | 7 ++++
>> > include/linux/memremap.h | 29 +++++++++++++++--
>> > include/linux/swap.h | 18 +++++++++--
>> > include/linux/swapops.h | 67 +++++++++++++++++++++++++++++++++++++++
>> > kernel/memremap.c | 43 +++++++++++++++++++++++--
>> > mm/Kconfig | 12 +++++++
>> > mm/memory.c | 64 ++++++++++++++++++++++++++++++++++++-
>> > mm/memory_hotplug.c | 10 ++++--
>> > mm/mprotect.c | 12 +++++++
>> > tools/testing/nvdimm/test/iomap.c | 3 +-
>> > 14 files changed, 269 insertions(+), 17 deletions(-)
>> >
>> > diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
>> > index 66af7b1..c50b58d 100644
>> > --- a/drivers/dax/pmem.c
>> > +++ b/drivers/dax/pmem.c
>> > @@ -111,8 +111,8 @@ static int dax_pmem_probe(struct device *dev)
>> > if (rc)
>> > return rc;
>> >
>> > - addr = devm_memremap_pages(dev, &res, &dax_pmem->ref,
>> > - altmap, NULL, NULL);
>> > + addr = devm_memremap_pages(dev, &res, &dax_pmem->ref, altmap,
>> > + NULL, NULL, NULL, NULL, MEMORY_DEVICE);
>> > if (IS_ERR(addr))
>> > return PTR_ERR(addr);
>> >
>> > diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
>> > index f2f1904..8166a56 100644
>> > --- a/drivers/nvdimm/pmem.c
>> > +++ b/drivers/nvdimm/pmem.c
>> > @@ -282,7 +282,8 @@ static int pmem_attach_disk(struct device *dev,
>> > pmem->pfn_flags = PFN_DEV;
>> > if (is_nd_pfn(dev)) {
>> > addr = devm_memremap_pages(dev, &pfn_res, &q->q_usage_counter,
>> > - altmap, NULL, NULL);
>> > + altmap, NULL, NULL, NULL,
>> > + NULL, MEMORY_DEVICE);
>> > pfn_sb = nd_pfn->pfn_sb;
>> > pmem->data_offset = le64_to_cpu(pfn_sb->dataoff);
>> > pmem->pfn_pad = resource_size(res) - resource_size(&pfn_res);
>> > @@ -292,7 +293,8 @@ static int pmem_attach_disk(struct device *dev,
>> > } else if (pmem_should_map_pages(dev)) {
>> > addr = devm_memremap_pages(dev, &nsio->res,
>> > &q->q_usage_counter,
>> > - NULL, NULL, NULL);
>> > + NULL, NULL, NULL, NULL,
>> > + NULL, MEMORY_DEVICE);
>> > pmem->pfn_flags |= PFN_MAP;
>> > } else
>> > addr = devm_memremap(dev, pmem->phys_addr,
>> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
>> > index 958f325..9a6ab71 100644
>> > --- a/fs/proc/task_mmu.c
>> > +++ b/fs/proc/task_mmu.c
>> > @@ -535,8 +535,11 @@ static void smaps_pte_entry(pte_t *pte, unsigned long addr,
>> > } else {
>> > mss->swap_pss += (u64)PAGE_SIZE << PSS_SHIFT;
>> > }
>> > - } else if (is_migration_entry(swpent))
>> > + } else if (is_migration_entry(swpent)) {
>> > page = migration_entry_to_page(swpent);
>> > + } else if (is_device_entry(swpent)) {
>> > + page = device_entry_to_page(swpent);
>> > + }
>> > } else if (unlikely(IS_ENABLED(CONFIG_SHMEM) && mss->check_shmem_swap
>> > && pte_none(*pte))) {
>> > page = find_get_entry(vma->vm_file->f_mapping,
>> > @@ -699,6 +702,8 @@ static int smaps_hugetlb_range(pte_t *pte, unsigned long hmask,
>> >
>> > if (is_migration_entry(swpent))
>> > page = migration_entry_to_page(swpent);
>> > + if (is_device_entry(swpent))
>> > + page = device_entry_to_page(swpent);
>> > }
>> > if (page) {
>> > int mapcount = page_mapcount(page);
>> > @@ -1182,6 +1187,9 @@ static pagemap_entry_t pte_to_pagemap_entry(struct pagemapread *pm,
>> > flags |= PM_SWAP;
>> > if (is_migration_entry(entry))
>> > page = migration_entry_to_page(entry);
>> > +
>> > + if (is_device_entry(entry))
>> > + page = device_entry_to_page(entry);
>> > }
>> >
>> > if (page && !PageAnon(page))
>> > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
>> > index 6230064..d154a18 100644
>> > --- a/include/linux/ioport.h
>> > +++ b/include/linux/ioport.h
>> > @@ -130,6 +130,7 @@ enum {
>> > IORES_DESC_ACPI_NV_STORAGE = 3,
>> > IORES_DESC_PERSISTENT_MEMORY = 4,
>> > IORES_DESC_PERSISTENT_MEMORY_LEGACY = 5,
>> > + IORES_DESC_UNADDRESSABLE_MEMORY = 6,
>> > };
>> >
>> > /* helpers to define resources */
>> > diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
>> > index 3f50eb8..e7c5dc6 100644
>> > --- a/include/linux/memory_hotplug.h
>> > +++ b/include/linux/memory_hotplug.h
>> > @@ -285,15 +285,22 @@ extern int zone_for_memory(int nid, u64 start, u64 size, int zone_default,
>> > * never relied on struct page migration so far and new user of might also
>> > * prefer avoiding struct page migration.
>> > *
>> > + * For device memory (which use ZONE_DEVICE) we want differentiate between CPU
>> > + * accessible memory (persitent memory, device memory on an architecture with a
>> > + * system bus that allow transparent access to device memory) and unaddressable
>> > + * memory (device memory that can not be accessed by CPU directly).
>> > + *
>> > * New non device memory specific flags can be added if ever needed.
>> > *
>> > * MEMORY_REGULAR: regular system memory
>> > * DEVICE_MEMORY: device memory create a ZONE_DEVICE zone for it
>> > * DEVICE_MEMORY_ALLOW_MIGRATE: page in that device memory ca be migrated
>> > + * MEMORY_DEVICE_UNADDRESSABLE: un-addressable memory (CPU can not access it)
>> > */
>> > #define MEMORY_NORMAL 0
>> > #define MEMORY_DEVICE (1 << 0)
>> > #define MEMORY_DEVICE_ALLOW_MIGRATE (1 << 1)
>> > +#define MEMORY_DEVICE_UNADDRESSABLE (1 << 2)
>> >
>> > extern int arch_add_memory(int nid, u64 start, u64 size, int flags);
>> > extern int offline_pages(unsigned long start_pfn, unsigned long nr_pages);
>> > diff --git a/include/linux/memremap.h b/include/linux/memremap.h
>> > index 582561f..4b9f02c 100644
>> > --- a/include/linux/memremap.h
>> > +++ b/include/linux/memremap.h
>> > @@ -35,31 +35,42 @@ static inline struct vmem_altmap *to_vmem_altmap(unsigned long memmap_start)
>> > }
>> > #endif
>> >
>> > +typedef int (*dev_page_fault_t)(struct vm_area_struct *vma,
>> > + unsigned long addr,
>> > + struct page *page,
>> > + unsigned flags,
>> > + pmd_t *pmdp);
>> > typedef void (*dev_page_free_t)(struct page *page, void *data);
>> >
>> > /**
>> > * struct dev_pagemap - metadata for ZONE_DEVICE mappings
>> > + * @page_fault: callback when CPU fault on an un-addressable device page
>> > * @page_free: free page callback when page refcount reach 1
>> > * @altmap: pre-allocated/reserved memory for vmemmap allocations
>> > * @res: physical address range covered by @ref
>> > * @ref: reference count that pins the devm_memremap_pages() mapping
>> > * @dev: host device of the mapping for debug
>> > * @data: privata data pointer for page_free
>> > + * @flags: device memory flags (look for MEMORY_DEVICE_* memory_hotplug.h)
>> > */
>> > struct dev_pagemap {
>> > + dev_page_fault_t page_fault;
>> > dev_page_free_t page_free;
>> > struct vmem_altmap *altmap;
>> > const struct resource *res;
>> > struct percpu_ref *ref;
>> > struct device *dev;
>> > void *data;
>> > + int flags;
>> > };
>>
>> dev_pagemap is only meant for get_user_pages() to do lookups of ptes
>> with _PAGE_DEVMAP and take a reference against the hosting device..
>
> And i want to build on top of that to extend _PAGE_DEVMAP to support
> a new usecase for unaddressable device memory.
>
>>
>> Why can't HMM use the typical vm_operations_struct fault path and push
>> more of these details to a driver rather than the core?
>
> Because the vm_operations_struct has nothing to do with the device.
> We are talking about regular vma here. Think malloc, mmap, share
> memory, ... not about mmap(/dev/thedevice,...)
>
> So the vm_operations_struct is never under device control and we can
> not, nor want to, rely on that.
Can you explain more what's behind that "can not, nor want to"
statement? It seems to me that any awkwardness of moving to a
standalone device file interface is less than a maintaining a new /
parallel mm fault path through dev_pagemap.
>
> So what we looking for here is struct page that can behave mostly
> like anyother except that we do not want to allow GUP to take a
> reference almost exactly what ZONE_DEVICE already provide.
>
> So do you have any fundamental objections to this patchset ? And if
> so, how do you propose i solve the problem i am trying to address ?
> Because hardware exist today and without something like HMM we will
> not be able to support such hardware.
My pushback stems from it being a completely different use case for
devm_memremap_pages(), as evidenced by it growing from 4 arguments to
9, and the ongoing maintenance overhead of understanding HMM
requirements when updating the pmem usage of ZONE_DEVICE.
Powered by blists - more mailing lists