linux-kernel - Re: [PATCHv7 5/7] kho: don't unpreserve memory during abort

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: <CA+CK2bARUpZaymPTusZWM-kzXcUp_d1UK9nUudu3tHitpeAH5Q@mail.gmail.com>
Date: Fri, 24 Oct 2025 11:33:26 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Pratyush Yadav <pratyush@...nel.org>
Cc: Mike Rapoport <rppt@...nel.org>, 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

> If any of the kho_preserve_pages() fails, the notifier block will fail,
> cause an abort, and eventually all memory will be unpreserved.

This is a wrong behavior. Why should the memory that I preserved be
unpreserved if there is finailziation failure or abort? reserve_mem
should still keep memory as preserved in case KHO later will be
finalized right? I have tested that this patch works with kho
self-test: preserve, finalize, abort, finalize again, and the pages
are properly preserved.

KHO Test and memblock do not need to ever unpreserve pages, as they
preserve them once during boot.

> Now that there is no notifier, and thus no abort, the pages must be
> unpreserved explicitly before returning.
>
> Similarly, for test_kho, kho_test_notifier() calls kho_preserve_folio()
> and expects the abort to clean things up.
>
> Side note: test_kho also preserves folios from kho_test_save_data() and
> doesn't clean them up on error, but that is a separate problem that this
> series doesn't have to solve.
>
> I think patch 3/7 is the one that actually causes this problem since it

I updated that patch with your suggested fix.

Pasha