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: <aPnXVmD3cNmYNRF_@kernel.org>
Date: Thu, 23 Oct 2025 10:20:54 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Pratyush Yadav <pratyush@...nel.org>
Cc: Pasha Tatashin <pasha.tatashin@...een.com>, akpm@...ux-foundation.org,
	brauner@...nel.org, corbet@....net, graf@...zon.com, jgg@...pe.ca,
	linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
	linux-mm@...ck.org, masahiroy@...nel.org, ojeda@...nel.org,
	rdunlap@...radead.org, tj@...nel.org
Subject: Re: [PATCHv7 5/7] kho: don't unpreserve memory during abort

On Wed, Oct 22, 2025 at 01:15:30PM +0200, Pratyush Yadav wrote:
> On Tue, Oct 21 2025, Pasha Tatashin wrote:
> 
> > KHO allows clients to preserve memory regions at any point before the
> > KHO state is finalized. The finalization process itself involves KHO
> > performing its own actions, such as serializing the overall
> > preserved memory map.
> >
> > If this finalization process is aborted, the current implementation
> > destroys KHO's internal memory tracking structures
> > (`kho_out.ser.track.orders`). This behavior effectively unpreserves
> > all memory from KHO's perspective, regardless of whether those
> > preservations were made by clients before the finalization attempt
> > or by KHO itself during finalization.
> >
> > This premature unpreservation is incorrect. An abort of the
> > finalization process should only undo actions taken by KHO as part of
> > that specific finalization attempt. Individual memory regions
> > preserved by clients prior to finalization should remain preserved,
> > as their lifecycle is managed by the clients themselves. These
> > clients might still need to call kho_unpreserve_folio() or
> > kho_unpreserve_phys() based on their own logic, even after a KHO
> > finalization attempt is aborted.
> 
> I think you also need to update test_kho and reserve_mem to do this
> since right now they assume all memory gets unpreserved on failure.

I agree. 

> > Signed-off-by: Pasha Tatashin <pasha.tatashin@...een.com>
> > ---
> [...]
> 
> -- 
> Regards,
> Pratyush Yadav

-- 
Sincerely yours,
Mike.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ