From: Pratyush Yadav <me@yadavpratyush.com>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alexander Graf <graf@amazon.com>, Baoquan He <bhe@redhat.com>,
Changyuan Lyu <changyuanl@google.com>,
Chris Li <chrisl@kernel.org>, Jason Gunthorpe <jgg@nvidia.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
kexec@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/2] kho: add support for preserving vmalloc allocations
Date: Tue, 09 Sep 2025 16:33:27 +0200 [thread overview]
Message-ID: <mafs0ldmnlmq0.fsf@yadavpratyush.com> (raw)
In-Reply-To: <mafs0ldmon784.fsf@kernel.org>
Hi Mike,
Couple more thoughts.
On Mon, Sep 08 2025, Pratyush Yadav wrote:
> On Mon, Sep 08 2025, Mike Rapoport wrote:
>
>> From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
>>
>> A vmalloc allocation is preserved using binary structure similar to
>> global KHO memory tracker. It's a linked list of pages where each page
>> is an array of physical address of pages in vmalloc area.
>>
>> kho_preserve_vmalloc() hands out the physical address of the head page
>> to the caller. This address is used as the argument to
>> kho_vmalloc_restore() to restore the mapping in the vmalloc address
>> space and populate it with the preserved pages.
>>
>> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
[...]
>> +/**
>> + * kho_restore_vmalloc - recreates and populates an area in vmalloc address
>> + * space from the preserved memory.
>> + * @preservation: physical address of the preservation metadata.
>> + *
>> + * Recreates an area in vmalloc address space and populates it with memory that
>> + * was preserved using kho_preserve_vmalloc().
>> + *
>> + * Return: pointer to the area in the vmalloc address space, NULL on failure.
>> + */
>> +void *kho_restore_vmalloc(phys_addr_t preservation)
>> +{
>> + struct kho_vmalloc_chunk *chunk = phys_to_virt(preservation);
>> + unsigned int align, order, shift, flags;
>> + unsigned int idx = 0, nr;
>> + unsigned long addr, size;
>> + struct vm_struct *area;
>> + struct page **pages;
>> + int err;
>> +
>> + flags = chunk->hdr.flags;
>> + if (flags & ~KHO_VMALLOC_FLAGS_MASK)
>> + return NULL;
>> +
>> + nr = chunk->hdr.total_pages;
>> + pages = kvmalloc_array(nr, sizeof(*pages), GFP_KERNEL);
>> + if (!pages)
>> + return NULL;
>> + order = chunk->hdr.order;
>> + shift = PAGE_SHIFT + order;
>> + align = 1 << shift;
>> +
>> + while (chunk) {
>> + struct page *page;
>> +
>> + for (int i = 0; i < chunk->hdr.num_elms; i++) {
>> + phys_addr_t phys = chunk->phys[i];
>> +
>> + for (int j = 0; j < (1 << order); j++) {
>> + page = phys_to_page(phys);
>> + kho_restore_page(page, 0);
>> + pages[idx++] = page;
>
> This can buffer-overflow if the previous kernel was buggy and added too
> many pages. Perhaps keep check for this?
Thinking about this a bit more, I think this should check that we found
_exactly_ chunk->hdr.total_pages pages, and should error out otherwise.
If too few are found, pages array will contain bogus data, if too many,
buffer overflow.
Also, I am not a fan of using kho_restore_page() directly. I think the
vmalloc preservation is a layer above core KHO, and it should use the
public KHO APIs. It really doesn't need to poke into internal APIs. If
any of the public APIs are insufficient, we should add new ones.
I don't suppose I'd insist on it, but something to consider since you
are likely going to do another revision anyway.
>
>> + phys += PAGE_SIZE;
>> + }
>> + }
>> +
>> + page = virt_to_page(chunk);
>> + chunk = KHOSER_LOAD_PTR(chunk->hdr.next);
>> + kho_restore_page(page, 0);
>> + __free_page(page);
>> + }
>> +
>> + area = __get_vm_area_node(nr * PAGE_SIZE, align, shift, flags,
>> + VMALLOC_START, VMALLOC_END, NUMA_NO_NODE,
>> + GFP_KERNEL, __builtin_return_address(0));
>> + if (!area)
>> + goto err_free_pages_array;
>> +
>> + addr = (unsigned long)area->addr;
>> + size = get_vm_area_size(area);
>> + err = vmap_pages_range(addr, addr + size, PAGE_KERNEL, pages, shift);
>> + if (err)
>> + goto err_free_vm_area;
>> +
>> + return area->addr;
>
> You should free the pages array before returning here.
>
>> +
>> +err_free_vm_area:
>> + free_vm_area(area);
>> +err_free_pages_array:
>> + kvfree(pages);
>> + return NULL;
>> +}
>> +EXPORT_SYMBOL_GPL(kho_restore_vmalloc);
>> +
>> /* Handling for debug/kho/out */
>>
>> static struct dentry *debugfs_root;
--
Regards,
Pratyush Yadav
next prev parent reply other threads:[~2025-09-09 14:33 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-08 10:35 [PATCH v3 0/2] " Mike Rapoport
2025-09-08 10:35 ` [PATCH v3 1/2] " Mike Rapoport
2025-09-08 14:14 ` Jason Gunthorpe
2025-09-15 14:01 ` Mike Rapoport
2025-09-15 14:37 ` Jason Gunthorpe
2025-09-15 16:11 ` Mike Rapoport
2025-09-08 18:12 ` Pratyush Yadav
2025-09-08 18:18 ` Jason Gunthorpe
2025-09-09 14:33 ` Pratyush Yadav [this message]
2025-09-15 14:12 ` Mike Rapoport
2025-09-15 14:43 ` Jason Gunthorpe
2025-09-15 16:36 ` Mike Rapoport
2025-09-16 13:05 ` Jason Gunthorpe
2025-09-16 13:21 ` Pratyush Yadav
2025-09-16 14:34 ` Mike Rapoport
2025-09-16 12:48 ` Pratyush Yadav
2025-09-16 14:41 ` Mike Rapoport
2025-09-15 14:08 ` Mike Rapoport
2025-09-16 12:43 ` Pratyush Yadav
2025-09-08 10:35 ` [PATCH v3 2/2] lib/test_kho: use kho_preserve_vmalloc instead of storing addresses in fdt Mike Rapoport
-- strict thread matches above, loose matches on Subject: below --
2025-09-07 7:00 [PATCH v2 0/2] kho: add support for preserving vmalloc allocations Mike Rapoport
2025-09-07 7:00 ` [PATCH v3 1/2] " Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mafs0ldmnlmq0.fsf@yadavpratyush.com \
--to=me@yadavpratyush.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=changyuanl@google.com \
--cc=chrisl@kernel.org \
--cc=graf@amazon.com \
--cc=jgg@nvidia.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox