From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D25C7606D822 for ; Tue, 3 Nov 2026 18:19:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=IIJ7coeX; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=Bt1+zkKF DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Unsubscribe-Post: List-Owner; bh=FYHOxuzquXBIUkTOvswFznqwg+VfrAF2mXc+DGRaufk=; b=IIJ7coeXOtjSIc CbhO5iDnWAWyEMwHwp5Ly8aZZjwHF3b6BN3z6IHaK+hTtmjFM8F2agLmLv36GJqQ53GloXAV46Afq Qm1gQXjVUZ1xBMlcB2AmWHoH6Nq+FyQLnDhJWOVxz3OnPbq7iTP6yzVo5SEtVWA0y8ioAep2DpTM4 zrAdHm3xiyF1RkrAYrWems7kWGDwrUBM/kqonsj0M7zqFaXI4BACVSz28rpDuTDCiGED3fK5YOzYV CDxoNymG80kx+z0ObjX42EjA6DGhm1WixN40z/UYvKGzKy8fbDMzB8OtVe9xB5g3Urxq8T/YKmtWV 8UtHvB0BdTE9ca4xmz5Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xOJ6Z-00000003Ota-25Ls; Tue, 03 Nov 2026 18:19:31 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xOJ6X-00000003Osy-3YpX for kexec@lists.infradead.org; Tue, 03 Nov 2026 18:19:29 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 9AAC243D27; Tue, 3 Nov 2026 18:19:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 245421F00A1C; Tue, 3 Nov 2026 18:19:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793729969; bh=FYHOxuzquXBIUkTOvswFznqwg+VfrAF2mXc+DGRaufk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Bt1+zkKFo0p/VYFtoaUpCeVO3q5Cot/MAaSoDdO3JiIxqdBgddjfqGHVdU99f1yWj RsT6XXcuLwdpqT7Qab6KbC+RyTnGd06cSobRJaWbAoKxvdNKnkWvxmFMjQCOqumBl8 takgjwM5VsjAfThX6toPDwysqGPdMju8o34WUTRroShJvepb9fCACdAZdXesrVMKJE 0zFf5NU8SdZRixP7e04hwd7Ic/5kKoelEmkDaAuxulY3md1Z3X9wnC/JaDAjGz1Mhx 5bVn2I1v8p5m/7t2COrI4myiOIdk36kvbkiHLIcGlK31qI5uR8RK+4eW7NOuA83TUs uroXbiBov88PQ== From: Pratyush Yadav To: Pasha Tatashin , Mike Rapoport , Pratyush Yadav , Andrew Morton , Samiullah Khawaja Cc: kexec@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 1/2] liveupdate: luo_file: allow keeping private_data from retrieve until finish Date: Tue, 3 Nov 2026 19:19:13 +0100 Message-ID: <20261103181916.2462825-2-pratyush@kernel.org> X-Mailer: git-send-email 2.56.0.385.gac671c819a-goog In-Reply-To: <20261103181916.2462825-1-pratyush@kernel.org> References: <20261103181916.2462825-1-pratyush@kernel.org> X-Archived-By: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: kexec@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "kexec" X-Spam-Status: No, score=-18.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 From: "Pratyush Yadav (Google)" The private_data field of struct liveupdate_file_op_args lets file handlers keep runtime state that is not preserved. It is set by .preserve() and passed to the later outgoing callbacks, up to .unpreserve(). But in the new kernel, nothing set by .retrieve() is kept, and .can_finish() and .finish() always get a NULL private_data. Handlers might need to keep runtime state from retrieve until finish. For example, memfd will need to remember the folios it holds on to until finish so it can release them there. Save the private_data set by a successful .retrieve() in the luo_file, and pass it to .can_finish() and .finish(). The handler must free it in .finish(). Signed-off-by: Pratyush Yadav (Google) --- include/linux/liveupdate.h | 8 +++++--- kernel/liveupdate/luo_file.c | 11 ++++++++--- 2 files changed, 13 insertions(+), 6 deletions(-) diff --git a/include/linux/liveupdate.h b/include/linux/liveupdate.h index 63ea5417de849..21caff8a98a7e 100644 --- a/include/linux/liveupdate.h +++ b/include/linux/liveupdate.h @@ -36,9 +36,11 @@ struct file; * @serialized_data: The opaque u64 handle, preserve/prepare/freeze may update * this field. * @private_data: Private data for the file used to hold runtime state that - * is not preserved. Set by the handler's .preserve() - * callback, and must be freed in the handler's - * .unpreserve() callback. + * is not preserved. For outgoing, set by the handler's + * .preserve() callback, and must be freed in the handler's + * .unpreserve() callback. For incoming, set by the handler's + * .retrieve() callback on success, and must be freed in the + * handler's .finish() callback. * * This structure bundles all parameters for the file operation callbacks. * The 'data' and 'file' fields are used for both input and output. diff --git a/kernel/liveupdate/luo_file.c b/kernel/liveupdate/luo_file.c index c39f96961a85b..ca4b685d6e1ce 100644 --- a/kernel/liveupdate/luo_file.c +++ b/kernel/liveupdate/luo_file.c @@ -130,9 +130,11 @@ static DEFINE_XARRAY(luo_preserved_files); * .retrieve(), and .finish() callbacks, allowing it to track * and update its serialized state across phases. * @private_data: Pointer to the private data for the file used to hold runtime - * state that is not preserved. Set by the handler's .preserve() - * callback, and must be freed in the handler's .unpreserve() - * callback. + * state that is not preserved. For outgoing, set by the + * handler's .preserve() callback, and must be freed in the + * handler's .unpreserve() callback. For incoming, set by the + * handler's .retrieve() callback, and must be freed in the + * handler's .finish() callback. * @retrieve_status: Status code indicating whether a user/kernel in the new kernel has * successfully called retrieve() on this file. This prevents * multiple retrieval attempts. A value of 0 means a retrieve() @@ -596,6 +598,7 @@ int luo_retrieve_file(struct luo_file_set *file_set, u64 token, } luo_file->file = args.file; + luo_file->private_data = args.private_data; /* Get reference so we can keep this file in LUO until finish */ get_file(luo_file->file); @@ -622,6 +625,7 @@ static int luo_file_can_finish_one(struct luo_file_set *file_set, args.handler = luo_file->fh; args.file = luo_file->file; args.serialized_data = luo_file->serialized_data; + args.private_data = luo_file->private_data; args.retrieve_status = luo_file->retrieve_status; can_finish = luo_file->fh->ops->can_finish(&args); } @@ -639,6 +643,7 @@ static void luo_file_finish_one(struct luo_file_set *file_set, args.handler = luo_file->fh; args.file = luo_file->file; args.serialized_data = luo_file->serialized_data; + args.private_data = luo_file->private_data; args.retrieve_status = luo_file->retrieve_status; luo_file->fh->ops->finish(&args); -- 2.56.0.385.gac671c819a-goog