From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 C0BD43F44E8 for ; Fri, 26 Jun 2026 11:57:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782475037; cv=none; b=fMNH7wjBZj2Q6n4GubhmIVCdJkUkszffnsMhgMpiC6XxG0b3VM7E3USNj1bqRDC5Fqe3teEKDInv8NR1C3H1bVzYYponoZzP/A2fWfSjaeXpE5pmldcdyihvPtlasC1hPat2ZCvReSO37djnAc6Jff1nqtN99kCIG/YLF6FLba4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782475037; c=relaxed/simple; bh=pc2EgAPC+bYO2dvo2IhEEXj1+D4A3iJpqmNDUDqXhmE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=DnlvwAXWYE9/jDnPNOP6rLsLIW6rerDqbEkexGgv7WjBrJjOb+ovfULlcda4DJSWdo5t7Nl74KBmZA2uU2zXGUVmKyoWzuy2A+QWbWlO7rzdtHhVG8V4Ntcm8XUE37pDE4m7eD8zoR2w7FqI6fs+GxQH7cvygPHwYoFXjMk1Lw0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Bx1YAzWS; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Bx1YAzWS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F51F1F000E9; Fri, 26 Jun 2026 11:57:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782475034; bh=9YpMyR+qlvlqRuVjps8vxBolsZnShA75KeyYR5QZWZI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Bx1YAzWSid7owFWxMCfA0186eDDpPS6Bk1iUsg+5y5Ugl2P9liT+7/arQf95DTE4S HW+dq6UYThVhQ9NIFmWe8tFD2BlNMJWJaVVk+JZX4xuPvF8cmg5B3rOmTwW7ZTRg58 T7RbELABusb6j+rLGCeH8mpsvLl5yXS00wxwbkJHNLbmweXgbRfVy8v7Owq6GAzcY7 3kHxztfz8U+TqCWxUt9uQydBK4QYk3UwDBX+mf4JwlBYIElybqH1uEgseynnD70u92 +7njhKUWT8E49vgLRmSWdFkjWBnLtyosTqxRf/6QkwYBJJTCqHZR9Pw/4v0hWtMQep lpa9skKfM/ccA== From: Pratyush Yadav To: Samiullah Khawaja Cc: Pasha Tatashin , Mike Rapoport , Pratyush Yadav , Alexander Graf , David Matlack , tarunsahu@google.com, open list , "open list:KEXEC HANDOVER (KHO)" , "open list:KEXEC HANDOVER (KHO)" Subject: Re: [PATCH 1/1] liveupdate: luo_file: Add internal APIs for file preservation In-Reply-To: <20260613012521.835490-2-skhawaja@google.com> (Samiullah Khawaja's message of "Sat, 13 Jun 2026 01:25:20 +0000") References: <20260613012521.835490-1-skhawaja@google.com> <20260613012521.835490-2-skhawaja@google.com> Date: Fri, 26 Jun 2026 13:57:11 +0200 Message-ID: <2vxzwlvljyzs.fsf@kernel.org> 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 Hi Sami, On Sat, Jun 13 2026, Samiullah Khawaja wrote: > From: Pasha Tatashin > > Live update orchestrator file handlers depend on the preservation of > other files. To make sure that the dependency is preserved, the file > handlers needs to fetch the preservation token of the preserved > dependency. Similarly during restore, a file handler wants to fetch the > restored file of the dependency. > > Add APIs that allows fetching token of dependency during preservation, > and fetching the restored file dependency during restore. > > Signed-off-by: Pasha Tatashin > Signed-off-by: Samiullah Khawaja We discussed this once already on a call, but I'll write my argument out here for everyone else to get a say as well. While it isn't obvious, this patch implicitly defines a part of the uAPI for live update. This patch says to VMMs (or other live update users) that "you can restore dependent files in any order". That is, VMMs don't have to restore the files in a topological sort order or dependencies, they can do so in any order and the kernel will manage the dependencies on its own. But on the preservation side, VMMs still do need to follow the topological order of dependencies. Because if they don't, the liveupdate_get_token_outgoing() call will fail and preservation can't proceed. In simple words, if file type A depends on file type B, VMMs always need to preserve B before A, because A's preservation will try to find B's token, and if B is not preserved that will fail. On the _restore_ side though, liveupdate_get_file_incoming() implicitly retrieves the file so the VMM can restore then in any order. I don't like this for a couple reasons. First, this makes the API asymmetric. If the VMM needs to manage dependency order during preservation anyway, why not do it on retrieve as well? Second, the API is easier to misuse. The VMM can restore A but not B, and then close the session. It will go on its merry way never knowing it did something wrong. For example, guest_memfd depends on its VM FD. With this patch, LUO will allow restoring guest_memfd without restoring the VM FD. This makes the guest_memfd practically useless. Yes, it is a bug in the VMM anyway, but if guest_memfd restore was denied, then it would be easier to catch. The kernel will keep itself safe in either case, but it will make the API harder to misuse. And you can always _relax_ the ordering requirement if there is a need in the future, but you can't go the other way round. So that's my question: do we enforce restore ordering? The code change should be relatively simple. You just need to fail if the file is not already restored in liveupdate_get_file_incoming(). In either case, please at least add a piece in the documentation about this ordering. We should not leave it implicit. [...] -- Regards, Pratyush Yadav