[PATCH v2 08/16] mm: add ability to take further action in vm_area_desc
Jason Gunthorpe
jgg at nvidia.com
Mon Sep 15 05:11:12 PDT 2025
On Wed, Sep 10, 2025 at 09:22:03PM +0100, Lorenzo Stoakes wrote:
> +static inline void mmap_action_remap(struct mmap_action *action,
> + unsigned long addr, unsigned long pfn, unsigned long size,
> + pgprot_t pgprot)
> +{
> + action->type = MMAP_REMAP_PFN;
> +
> + action->remap.addr = addr;
> + action->remap.pfn = pfn;
> + action->remap.size = size;
> + action->remap.pgprot = pgprot;
> +}
These helpers drivers are supposed to call really should have kdocs.
Especially since 'addr' is sort of ambigous.
And I'm wondering why they don't take in the vm_area_desc? Eg shouldn't
we be strongly discouraging using anything other than
vma->vm_page_prot as the last argument?
I'd probably also have a small helper wrapper for the very common case
of whole vma:
/* Fill the entire VMA with pfns starting at pfn. Caller must have
* already checked desc has an appropriate size */
mmap_action_remap_full(struct vm_area_desc *desc, unsigned long pfn)
It is not normal for a driver to partially populate a VMA, lets call
those out as something weird.
> +struct page **mmap_action_mixedmap_pages(struct mmap_action *action,
> + unsigned long addr, unsigned long num_pages)
> +{
> + struct page **pages;
> +
> + pages = kmalloc_array(num_pages, sizeof(struct page *), GFP_KERNEL);
> + if (!pages)
> + return NULL;
This allocation seems like a shame, I doubt many places actually need
it .. A callback to get each pfn would be better?
Jason
More information about the kexec
mailing list