linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Pratyush Yadav <me@yadavpratyush.com>,
	 Pratyush Yadav <pratyush@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, 16 Sep 2025 14:48:55 +0200	[thread overview]
Message-ID: <mafs0bjnaimvc.fsf@kernel.org> (raw)
In-Reply-To: <aMgey9qEC_XUejXm@kernel.org>

On Mon, Sep 15 2025, Mike Rapoport wrote:

> On Tue, Sep 09, 2025 at 04:33:27PM +0200, Pratyush Yadav wrote:
>> Hi Mike,
>> 
>> Couple more thoughts.
>> 
>> On Mon, Sep 08 2025, Pratyush Yadav wrote:
>> > On Mon, Sep 08 2025, Mike Rapoport wrote:
>> >> +
>> >> +	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.
>
> Sure, I can add the checks, but it feels superfluous to me.

See my reasoning in the other reply:
https://lore.kernel.org/linux-mm/mafs0frcmin3t.fsf@kernel.org/

>  
>> 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.
>
> I think vmalloc is as basic as folio. At some point we probably converge to 
> kho_preserve(void *) that will choose the right internal handler. like
> folio, vmalloc, kmalloc etc.

Sure, but do you need to use the internal APIs? Because doing this way
would miss some improvements for the public APIs. See my patch for
adding more sanity checking to kho_restore_folio() for example:
https://lore.kernel.org/linux-mm/20250910153443.95049-1-pratyush@kernel.org/

vmalloc preservation would miss this improvement since it uses the
internal API, even though it will clearly benefit from it.

-- 
Regards,
Pratyush Yadav


  parent reply	other threads:[~2025-09-16 12:49 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
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 [this message]
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=mafs0bjnaimvc.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --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=me@yadavpratyush.com \
    --cc=pasha.tatashin@soleen.com \
    --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