Messages in this thread | | | Date | Mon, 26 Sep 2022 16:53:37 +0200 | Subject | Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd | From | David Hildenbrand <> |
| |
On 26.09.22 16:48, Kirill A. Shutemov wrote: > On Mon, Sep 26, 2022 at 12:35:34PM +0200, David Hildenbrand wrote: >> On 23.09.22 02:58, Kirill A . Shutemov wrote: >>> On Mon, Sep 19, 2022 at 11:12:46AM +0200, David Hildenbrand wrote: >>>>> diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h >>>>> index 6325d1d0e90f..9d066be3d7e8 100644 >>>>> --- a/include/uapi/linux/magic.h >>>>> +++ b/include/uapi/linux/magic.h >>>>> @@ -101,5 +101,6 @@ >>>>> #define DMA_BUF_MAGIC 0x444d4142 /* "DMAB" */ >>>>> #define DEVMEM_MAGIC 0x454d444d /* "DMEM" */ >>>>> #define SECRETMEM_MAGIC 0x5345434d /* "SECM" */ >>>>> +#define INACCESSIBLE_MAGIC 0x494e4143 /* "INAC" */ >>>> >>>> >>>> [...] >>>> >>>>> + >>>>> +int inaccessible_get_pfn(struct file *file, pgoff_t offset, pfn_t *pfn, >>>>> + int *order) >>>>> +{ >>>>> + struct inaccessible_data *data = file->f_mapping->private_data; >>>>> + struct file *memfd = data->memfd; >>>>> + struct page *page; >>>>> + int ret; >>>>> + >>>>> + ret = shmem_getpage(file_inode(memfd), offset, &page, SGP_WRITE); >>>>> + if (ret) >>>>> + return ret; >>>>> + >>>>> + *pfn = page_to_pfn_t(page); >>>>> + *order = thp_order(compound_head(page)); >>>>> + SetPageUptodate(page); >>>>> + unlock_page(page); >>>>> + >>>>> + return 0; >>>>> +} >>>>> +EXPORT_SYMBOL_GPL(inaccessible_get_pfn); >>>>> + >>>>> +void inaccessible_put_pfn(struct file *file, pfn_t pfn) >>>>> +{ >>>>> + struct page *page = pfn_t_to_page(pfn); >>>>> + >>>>> + if (WARN_ON_ONCE(!page)) >>>>> + return; >>>>> + >>>>> + put_page(page); >>>>> +} >>>>> +EXPORT_SYMBOL_GPL(inaccessible_put_pfn); >>>> >>>> Sorry, I missed your reply regarding get/put interface. >>>> >>>> https://lore.kernel.org/linux-mm/20220810092532.GD862421@chaop.bj.intel.com/ >>>> >>>> "We have a design assumption that somedays this can even support non-page >>>> based backing stores." >>>> >>>> As long as there is no such user in sight (especially how to get the memfd >>>> from even allocating such memory which will require bigger changes), I >>>> prefer to keep it simple here and work on pages/folios. No need to >>>> over-complicate it for now. >>> >>> Sean, Paolo , what is your take on this? Do you have conrete use case of >>> pageless backend for the mechanism in sight? Maybe DAX? >> >> The problem I'm having with this is how to actually get such memory into the >> memory backend (that triggers notifiers) and what the semantics are at all >> with memory that is not managed by the buddy. >> >> memfd with fixed PFNs doesn't make too much sense. > > What do you mean by "fixed PFN". It is as fixed as struct page/folio, no? > PFN covers more possible backends.
For DAX, you usually bypass the buddy and map /dev/mem or a devdax. In contrast to ordinary memfd that allocates memory via the buddy. That's the difference I see -- and I wonder how it could work.
> >> When using DAX, what happens with the shared <->private conversion? Which >> "type" is supposed to use dax, which not? >> >> In other word, I'm missing too many details on the bigger picture of how >> this would work at all to see why it makes sense right now to prepare for >> that. > > IIUC, KVM doesn't really care about pages or folios. They need PFN to > populate SEPT. Returning page/folio would make KVM do additional steps to > extract PFN and one more place to have a bug.
Fair enough. Smells KVM specific, though.
-- Thanks,
David / dhildenb
| |