From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 65DD025CC79 for ; Fri, 14 Nov 2025 19:35:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763148932; cv=none; b=d0aq42/6b1Zrx1shvcJiSpFQh77CVpc1KTiyS64q82inf5bgukytJO52TPEyvBe7fD/IflbbVyazmXoCerXshA4pRW2hVQttlwtYW19B7HFiHml9eVMa2ceNFWvwoZGbCQz80seNHnh5rGmBU31YaFx12ot9YETd2NEIWfUniZQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763148932; c=relaxed/simple; bh=Zc97r0exmktwpRs9kQQA4bpGO3Sc8oaRn9s7KddLdwQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=YCpy7W+IroteXgzfaF7OvP6g8fj6eBlN2pQTvPa3s0CIM1LuwYCqjEbd5k1TmO44AyYYxp8+IzumFOh5u2SsW7D6T42Pf7KGVF9nNI+T4uAWalJYFuuiKhXCPaFe3umoYk8yzyS23YJYrkFVpjC5anve5Ufean+pyk3W/qmKiKc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kz1ExJB9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kz1ExJB9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0E8BFC4CEF5; Fri, 14 Nov 2025 19:35:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763148932; bh=Zc97r0exmktwpRs9kQQA4bpGO3Sc8oaRn9s7KddLdwQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kz1ExJB9ShhwyZCJrTmzMuqpRjtWv4hW2F7jZNB3rfQUowOAAacUIA9PnkDXUXXGy xLhcc2rw7hSxiEIqfhbBUcVT9CvKryIbYxKgx8gSDhH6DPxm8qm1u6p2h4NU4y+eCh jElngR6kvZ1B+ABXKxNxhL3hIGll1aJDF2ueT+YF5Q4Bkr8Q9r9knlbR1fBdFyTVCq R2ND68jqTTUj1ZeLbaAN4/1I/L/AHp8N6psr/aDGPJdB4iWsFfp4u6FjJE+EFxuFiy r945l83UMnqUx71Xg0fjH+ULU/gdV0SC6l9m//rhtkFv5zEouCT8tb8KzHp71NJNGW JstnL8QGZWi/g== From: Pratyush Yadav To: Pasha Tatashin Cc: akpm@linux-foundation.org, bhe@redhat.com, rppt@kernel.org, jasonmiu@google.com, arnd@arndb.de, coxu@redhat.com, dave@vasilevsky.ca, ebiggers@google.com, graf@amazon.com, kees@kernel.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, linux-mm@kvack.org Subject: Re: [PATCH v2 12/13] kho: Allow memory preservation state updates after finalization In-Reply-To: <20251114190002.3311679-13-pasha.tatashin@soleen.com> (Pasha Tatashin's message of "Fri, 14 Nov 2025 14:00:01 -0500") References: <20251114190002.3311679-1-pasha.tatashin@soleen.com> <20251114190002.3311679-13-pasha.tatashin@soleen.com> Date: Fri, 14 Nov 2025 20:35:28 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Fri, Nov 14 2025, Pasha Tatashin wrote: > Currently, kho_preserve_* and kho_unpreserve_* return -EBUSY if > KHO is finalized. This enforces a rigid "freeze" on the KHO memory > state. > > With the introduction of re-entrant finalization, this restriction is > no longer necessary. Users should be allowed to modify the preservation > set (e.g., adding new pages or freeing old ones) even after an initial > finalization. > > The intended workflow for updates is now: > 1. Modify state (preserve/unpreserve). > 2. Call kho_finalize() again to refresh the serialized metadata. > > Remove the kho_out.finalized checks to enable this dynamic behavior. > > This also allows to convert kho_unpreserve_* functions to void, as they > do not return any error anymore. > > Signed-off-by: Pasha Tatashin > Reviewed-by: Mike Rapoport (Microsoft) Reviewed-by: Pratyush Yadav [...] -- Regards, Pratyush Yadav