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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHN2nPL6SV_Y6Sxqy4o-mOPZoGYMoWow=KevUTX6=c8JkO_g8g@mail.gmail.com>
Date: Thu, 18 Sep 2025 23:58:47 -0700
From: Jason Miu <jasonmiu@...gle.com>
To: Mike Rapoport <rppt@...nel.org>
Cc: Alexander Graf <graf@...zon.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Baoquan He <bhe@...hat.com>, Changyuan Lyu <changyuanl@...gle.com>, 
	David Matlack <dmatlack@...gle.com>, David Rientjes <rientjes@...gle.com>, 
	Jason Gunthorpe <jgg@...dia.com>, Joel Granados <joel.granados@...nel.org>, 
	Marcos Paulo de Souza <mpdesouza@...e.com>, Mario Limonciello <mario.limonciello@....com>, 
	Pasha Tatashin <pasha.tatashin@...een.com>, Petr Mladek <pmladek@...e.com>, 
	"Rafael J . Wysocki" <rafael.j.wysocki@...el.com>, Steven Chen <chenste@...ux.microsoft.com>, 
	Yan Zhao <yan.y.zhao@...el.com>, kexec@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC v1 2/4] kho: Adopt KHO page tables and remove serialization

Hi Mike,

Thank you very much for your comments!

On Wed, Sep 17, 2025 at 10:52 AM Mike Rapoport <rppt@...nel.org> wrote:
> > -/*
> > - * TODO: __maybe_unused is added to the functions:
> > - * kho_preserve_page_table()
> > - * kho_walk_tables()
> > - * kho_memblock_reserve()
> > - * since they are not actually being called in this change.
> > - * __maybe_unused will be removed in the next patch.
> > - */
> > -static __maybe_unused int kho_preserve_page_table(unsigned long pfn, int order)
> > +static int kho_preserve_page_table(unsigned long pfn, int order)
>
> Just merge this and the previous patch so that the patch will replace the
> current preservation mechanism with a new one.

Sure I can do this.

> > @@ -1023,12 +752,8 @@ int kho_preserve_folio(struct folio *folio)
> >  {
> >       const unsigned long pfn = folio_pfn(folio);
> >       const unsigned int order = folio_order(folio);
> > -     struct kho_mem_track *track = &kho_out.ser.track;
> > -
> > -     if (kho_out.finalized)
> > -             return -EBUSY;
> >
> > -     return __kho_preserve_order(track, pfn, order);
> > +     return kho_preserve_page_table(pfn, order);
>
> I don't think we should "rename" __kho_preserve_order() to
> kho_preserve_page_table(). __kho_preserve_order() could use the new data
> structure, or call the new implementation, but I don't see a reason to
> replace it.
>

Ok, I prefer calling the new implementation, so it will look like:

kho_preserve_folio() -> __kho_preserve_order() -> __kho_preserve_page_table()

 __kho_preserve_page_table() is the internal implementation of
kho_preserve_page_table() and we can remove the
kho_preserve_page_table().

--
Jason Miu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ