From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 63B98C71136 for ; Mon, 16 Jun 2025 10:43:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 998DF6B008A; Mon, 16 Jun 2025 06:43:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 970306B008C; Mon, 16 Jun 2025 06:43:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8AD556B0092; Mon, 16 Jun 2025 06:43:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7CF906B008A for ; Mon, 16 Jun 2025 06:43:23 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id F3CC11A0FD0 for ; Mon, 16 Jun 2025 10:43:22 +0000 (UTC) X-FDA: 83560927044.09.CA1BBF1 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf15.hostedemail.com (Postfix) with ESMTP id 4539FA000D for ; Mon, 16 Jun 2025 10:43:21 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fEeoQYUk; spf=pass (imf15.hostedemail.com: domain of pratyush@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=pratyush@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750070601; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=R2ws1OtmFdjBniJfUfv2dgSiEI94iyjXjUAT4I5e+NY=; b=J/xdrxOBciR2ByVTq6gYgnl+IMSCC05zxQk6PGpY25P3Dr9L9bQrPJSJGuod6C4euw3tJj Zqtb5NsGIhfk89ANi73ts0glRMZrbcLAwzaCSi0qmMitSEUNCN+6Zssn/7AwLOnVSj1yiS OLAZ9hWH6RwIkFCvWtnARrYE4E3Z6r4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=fEeoQYUk; spf=pass (imf15.hostedemail.com: domain of pratyush@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=pratyush@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750070601; a=rsa-sha256; cv=none; b=YOKqGFeHKDbdPl7onuDpcjTxcVjMr3A1LEC+QolxfE4YcoOjNqMMlQYkVMtyJG+nk7ghya ob/3vxTesC/4z/ASLbRY6cc7v5872UHjMTLRNqr0fMuUKdgCf8vjBa4kNc7FNK7i9YmVUM E49tyxd9rbU/E5lNcp2DvJ6cf4eZYo4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 3C0CCA518E4; Mon, 16 Jun 2025 10:43:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16B85C4CEEA; Mon, 16 Jun 2025 10:43:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750070599; bh=Lbtuz5Vwa/cgdysdVyVn1eSaL5ZpHU9q9W99m/VIS2U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fEeoQYUkvSV+UKCyhe2VnUgE4OoTE8gOMla6mUimejqiNyx9AGGO0bpEkR6+e8GjA TwrbkH7EfhInNPZ1hsmuhpbjfc8Bgrcw1dz6RMErFRVFYDRQL92QKG0PgQDS/gPZ9G DaGlBy5tsfQjBsXx6fchbHwqDBgW4DrtIm0wE5+Tjzq8U9KNeyyed0OvoB59wHBIsN zmKi+jQaF8xJKQT4XWYOw3j+vuFct4jlzQzkL91nkvWVl2gnR7Q3ko/7fEp3mVwVFn 4t/oO+E9uMq0BYUx5Kufwfm+WvRCwxPI1eKOo1kAutdDdwTqpsoz7TrTrP550frvPi p4shshgLj89tg== From: Pratyush Yadav To: Pasha Tatashin Cc: Pratyush Yadav , jasonmiu@google.com, graf@amazon.com, changyuanl@google.com, rppt@kernel.org, dmatlack@google.com, rientjes@google.com, corbet@lwn.net, rdunlap@infradead.org, ilpo.jarvinen@linux.intel.com, kanie@linux.alibaba.com, ojeda@kernel.org, aliceryhl@google.com, masahiroy@kernel.org, akpm@linux-foundation.org, tj@kernel.org, yoann.congal@smile.fr, mmaurer@google.com, roman.gushchin@linux.dev, chenridong@huawei.com, axboe@kernel.dk, mark.rutland@arm.com, jannh@google.com, vincent.guittot@linaro.org, hannes@cmpxchg.org, dan.j.williams@intel.com, david@redhat.com, joel.granados@kernel.org, rostedt@goodmis.org, anna.schumaker@oracle.com, song@kernel.org, zhangguopeng@kylinos.cn, linux@weissschuh.net, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, gregkh@linuxfoundation.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, rafael@kernel.org, dakr@kernel.org, bartosz.golaszewski@linaro.org, cw00.choi@samsung.com, myungjoo.ham@samsung.com, yesanishhere@gmail.com, Jonathan.Cameron@huawei.com, quic_zijuhu@quicinc.com, aleksander.lobakin@intel.com, ira.weiny@intel.com, andriy.shevchenko@linux.intel.com, leon@kernel.org, lukas@wunner.de, bhelgaas@google.com, wagi@kernel.org, djeffery@redhat.com, stuart.w.hayes@gmail.com Subject: Re: [RFC v2 09/16] luo: luo_files: implement file systems callbacks In-Reply-To: References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-10-pasha.tatashin@soleen.com> Date: Mon, 16 Jun 2025 12:43:10 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4539FA000D X-Stat-Signature: qcqpe16c3tmp3ri5hopdiak979fag5ow X-Rspam-User: X-HE-Tag: 1750070601-571880 X-HE-Meta: U2FsdGVkX193wgogEr3Nollrm/QMjaJJuvzGRMRwoyKvPSVWSw7l7yYPZYhyLuspkGDFL+/KY4GKbH59m0DVyfokcgOPTLcHNMDFZCiAPkV6xKNowLm45zlxWjSXid9Weanlz8DyJPjzOLJVACPBtcK2h6Ie3ZMOdXg+aJc7hMwnKyyAyb1vhVo6k5aogu1+GX53fATUf/RR6UIFhAFFfuAoY5UvTNuELzbj6YbN85zNxiTHikPWLLj8aKgntdUP+mPh3nOke1xY1yr6i6BXe9BL1Js3jBL+mIH2S3AVXdB/QGm4+wKj/Xaxl8hRvWIWL57STLSKlCANZ8HepZegwBhqmZ8Y7WKzHyMycSgh0kM5eUE6pa6DKE17sxUuW4eQPmInHhOhQ0+6wsSnkoA7NK+4/gh8fAxnDBpyZn7UpQacwbolV8uifn027382Tb/94q5N8dgP8wYlZa3AE4qSi7FFKJ0CXFGWkCoK68S+FneBNHkIKq64OwJWzTc+NXhkEoogejWS2mqieFabIaqgBQdjlYqeGY3fXxj/1rP2TKU22Tdp27jMPCKsTO8J5oKsO1L7Nl/wr5OPxqXt4G+cIMELrrqRqXug3Ai0KhwUf9siVD/9rZ7AQYkF0zikxRtwrYTtQ6frgdpW7XmNFgYp3NX7kxXQ/D0oEr4xkq2oSRV7mZrrHUrjN+TLry6sdeuV4+b/fV/dYpmdrJPu85RIsrkALM3y+9aKjaDpz7wqnOcIQjucTX/v9RQpdqpzEK6RkyMvoHGE140Zj8XgVVpomerjSGdMxW7reE9yf4YKq741lJuMYJLr+TKXnE0AphXeOqGo9g1RyChCYX37NANt2son45m6emCpsu3Th1YKeN/NTkTV8B7d54LAsA2SsCJ0d7HgIUx+fLo3c8pcp7rBe5DgOzqWGDzSuP5WgyajMnjwFDXD6Y5exNpcSADJ95u0z7VpJAnJ8Ra2gGShjBm QaoyDGR7 xOm3QSbRRNYjOs7u+drJYsoYglK+QHoRCeulCL6mFTBfQUIE8PMsj7wCc4I17Yjg2I/F7+vEpbflg9bTxeH98aLzJ7zv3pLOV8LwAwT9P6RuyhgfWJQX1UbVzjoE2VVa0qq/hg/0BwqwPVLlFD4E5MC7mWu2kBf7Re0LrN3FBbiUu0enD1pK67VQ0trhV95haB2SueGfdL82rtmnmlXr+tsXso+qzis/8QXv87v2Eobvk5myskY5FzvURFQKrjc4aM7jjtPlMnMcQl18Bls7swpXXG+bH48zTsusUUY7EQzhI9p+EiHA7QpfWdXrCsKEQudjShngWQYXyMeNk0N3cyBdIpOVH+u8Mfru+sMQ5fJ/WhZFKAE/nhn/qlqjmGhPbvn/8X9cGgG6ReKLDydw1JbdDstfT6ULuh0I8LL3XPDOn4ts3hQ75bwZ1SqGvjhY0PaOg X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jun 13 2025, Pasha Tatashin wrote: > On Fri, Jun 13, 2025 at 11:18=E2=80=AFAM Pratyush Yadav wrote: >> >> On Sun, Jun 08 2025, Pasha Tatashin wrote: >> >> > On Thu, Jun 5, 2025 at 12:04=E2=80=AFPM Pratyush Yadav wrote: >> >> >> >> On Thu, May 15 2025, Pasha Tatashin wrote: >> >> >> >> > Implements the core logic within luo_files.c to invoke the prepare, >> >> > reboot, finish, and cancel callbacks for preserved file instances, >> >> > replacing the previous stub implementations. It also handles >> >> > the persistence and retrieval of the u64 data payload associated wi= th >> >> > each file via the LUO FDT. >> >> > >> >> > This completes the core mechanism enabling registered filesystem >> >> > handlers to actively manage file state across the live update >> >> > transition using the LUO framework. >> >> > >> >> > Signed-off-by: Pasha Tatashin >> >> > --- >> >> > drivers/misc/liveupdate/luo_files.c | 105 ++++++++++++++++++++++++= +++- >> >> > 1 file changed, 103 insertions(+), 2 deletions(-) >> >> > >> >> [...] >> >> > @@ -305,7 +369,29 @@ int luo_do_files_prepare_calls(void) >> >> > */ >> >> > int luo_do_files_freeze_calls(void) >> >> > { >> >> > - return 0; >> >> > + unsigned long token; >> >> > + struct luo_file *h; >> >> > + int ret; >> >> > + >> >> > + xa_for_each(&luo_files_xa_out, token, h) { >> >> >> >> Should we also ensure at this point that there are no open handles to >> >> this file? How else would a file system ensure the file is in quiesce= nt >> >> state to do its final serialization? >> > >> > Do you mean check refcnt here? If so, this is a good idea, but first >> > we need to implement the lifecycle of liveupdate agent correctectly, >> > where owner of FD must survive through entering into reboot() with >> > /dev/liveupdate still open. >> >> Yes, by this point we should ensure refcnt =3D=3D 1. IIUC you plan to >> implement the lifecycle change in the next revision, so this can be >> added there as well I suppose. > > Yes, I am working on that. Current, WIP patch looks like this: > https://github.com/soleen/linux/commit/fecf912d8b70acd23d24185a8c0504764e= 43a279 > > However, I am not sure about refcnt =3D=3D 1 at freeze() time. We can have > programs, that never terminated while we were still in userspace (i.e. > kexec -e -> reboot() -> freeze()), in that case refcnt can be anything > at the time of freeze, no? Do you mean the agent that controls the liveupdate session? Then in that case the agent can keep running with the /dev/liveupdate FD open, but it must close all of the FDs preserved via LUO before doing kexec -e. --=20 Regards, Pratyush Yadav