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 578CAC71136 for ; Mon, 16 Jun 2025 14:58:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B6FCA6B00AD; Mon, 16 Jun 2025 10:58:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B47806B00AE; Mon, 16 Jun 2025 10:58:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5DA06B00B1; Mon, 16 Jun 2025 10:58:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 95EA66B00AD for ; Mon, 16 Jun 2025 10:58:24 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 45BD51A0651 for ; Mon, 16 Jun 2025 14:58:24 +0000 (UTC) X-FDA: 83561569728.15.F26F346 Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf14.hostedemail.com (Postfix) with ESMTP id 6035C100003 for ; Mon, 16 Jun 2025 14:58:22 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=L6QEUsRB; spf=pass (imf14.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750085902; 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=DuMKK0wxk2Ppc1cObPUWbdepum9enQdFn8eNSrTwIrE=; b=kTdk87JCJ/MKo+pfK/T51t1PYKVyS5f5MbTbXjtD5lcPz8BoOtvbX3nor7Ha7gtWRCbCml nmMniczxB1teTp8Hl5qwBAb4j7lEUKFJBQFzbYq/DixB2wzOIMWLVBqaU8fHPkrKrmFz2J QEfv2zvi0kUxgO6HD0kMPKuMtX9Cno8= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=L6QEUsRB; spf=pass (imf14.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=pasha.tatashin@soleen.com; dmarc=pass (policy=none) header.from=soleen.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750085902; a=rsa-sha256; cv=none; b=BWo8LFiYjMm+6eR0UxfA0JHo08dvE/uznXqeI+BZul4vr3/MgurhyPhRI54nJNJeiOJud1 13FusYZ6yF1Y5r8mGUijTeXeRZTn05dy/21kRSbemxDPjB7hjg1xS0K8SrSoT/0CiWTpaR 69PFbO8dZmXnpDMsehAppCknV8nDZWc= Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-4a43d2d5569so59163661cf.0 for ; Mon, 16 Jun 2025 07:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1750085901; x=1750690701; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=DuMKK0wxk2Ppc1cObPUWbdepum9enQdFn8eNSrTwIrE=; b=L6QEUsRBqT+Y7BvLoIlqoxrhsS0X5eaqP8Pfy662uVBez1RvEqaJD6UdalJY9nuOat hVnp1zidB3APNCvn1L2EQxlYRMX5eaNyWwdTvEnvmxoKLP7BNOtQaQwhjXTkjk3/kRE+ Gne+NorGyxui8ZSNI9iQALsXbG0StLSCcyNlLc7TK55WmPKsQZJnDWyNVoRZL4wshCZg uDBjNXBu/0St1Lxdo+c2Mr2FqVi0vPrdWu/3hMzS+wgWynNqy0Dfjy/x4TXuyt1rvYWZ R/pide6PoDzfshpcXml0/enNSQYOb9qwoiVxyII3IchwxUOYxTCLiPoIrQKMg5mECi3R 3zTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750085901; x=1750690701; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=DuMKK0wxk2Ppc1cObPUWbdepum9enQdFn8eNSrTwIrE=; b=dPtvk8bKKeYRp/POyVqB///W2UseEw0lIk4E+LRGYZuj0Ox5FO5ryFQu9uzX3teShA HsHjU0g6AHqeK7qEX0j1Rgfl+xweune2x6cXuOU7/7Fk/5/hszyxzsGYTLPb6N7C394G yNs5LIbqSqU2EGonuXPzvGgl+S0A5LYTyEQm9V4ivlMJwPuDIfOdk9nB8scodX8QpDQ8 x3lM3iCu9AXJEvN4LkY0Jd6/LcpD+f4/9MFJCONJt84sktpdDKoiI/GKQdILWeHUA+UX /UNxyz4GyBKzUpdOYNDKQvKhZK931tCIpcL23ojLDBktyVwxI4/u13ur2prLoUJaA6Wt YX3g== X-Forwarded-Encrypted: i=1; AJvYcCUkg9Qv3LdmvaQeRu52ikoofBZoRf3PsrJTrSt1qcz1omvxAxJgHDtrcwdjNzROLc98VxleeSBZlQ==@kvack.org X-Gm-Message-State: AOJu0Yz3G9zYEvsjx7Ue304TtW6TElROUJB0s8dXqXxlsmsMo46h+Gzn tQT/9kOP4r6je9YqEBSvD3PNvXHYRE+97y6aajYXsGp5izisw3nMgtdogx1OUBBlRoQb8+cMVrS 9QWzKqYObzDoGwEDjpF6109i00DDyYguFp8/SZjoezA== X-Gm-Gg: ASbGncu3UhvlvFuoGfx4oBDDU8Vz1fsSTpZXkakbAw3nFQrz6YI3QM1ttSYOPCPfDyS /wraqXI6QeSEdruwC2V/9CPckkhyXdpWdHE0+twdDB8+b8jFn6zhYitSDY9DUMPoNlOTcntt6di q/VMmXW+kqik2eyYGYvENTJHlmBtvW3BSxex7SrUql X-Google-Smtp-Source: AGHT+IHeqnVp8310ARaaqnrcuIV7Bf4XtpwoW0IDiqPPSGX8Jd8nm+uznItPFIhEpr0JFzT8rjNxr8wKmjb6IQDf1UQ= X-Received: by 2002:a05:622a:1814:b0:4a6:ef6d:d608 with SMTP id d75a77b69052e-4a73c609abfmr154969901cf.38.1750085901185; Mon, 16 Jun 2025 07:58:21 -0700 (PDT) MIME-Version: 1.0 References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-10-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Mon, 16 Jun 2025 10:57:44 -0400 X-Gm-Features: AX0GCFtEAEaQHrRq3yY3LztJjK9AZdUJhVhSl24FNdkzOUkQ_-QE0qUF49S7jzU Message-ID: Subject: Re: [RFC v2 09/16] luo: luo_files: implement file systems callbacks To: Pratyush Yadav Cc: 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 6035C100003 X-Rspamd-Server: rspam03 X-Rspam-User: X-Stat-Signature: ersh89e9mqm7royqas6j5y9z9gg5cksu X-HE-Tag: 1750085902-682250 X-HE-Meta: U2FsdGVkX19jPbRSlyHqZZdlKFE6phBSvNgx59FTQcSgItYDzPPR0q1AU0uWA7XaKPbgWWbqczanEnLJoRjkDeEKOckzLs3ZK3TGAqEjGooersP0EAxRQwwXiwhhT5CXFvq+TYX9VPWMf6+j1ZJcktJeIS71WcULw6EqFmDj/s4nKUoVw3qJ12xdKMZki9MdboVcz+cG/d3wZ/bDXwcmvE0Ys3Rz3cHjxmfsHlCWUqJhmiYPJ+uynmEFP6QEQaa655LD4Z9LlLUzzI72LJxmSjTDQd2zTvMGWZYiTOOt0gQbHy3rnb9SP1rcb/nxBIdVcmrm9DRjV0CtK00S8LzwDxH49KteJPe4x4pZ3RY1ZHiPMs8m2VUC9MZxwzlVlWaPMnItzp7erCzWCDam2lU2OL3mE+iBFI80gBlYqj7vNwKunIZgoxMjZRkgKL9vBQXunZ609wpbobfDX3cidAw05fABVAUu8ZOcE/+M1zCkDHHFyna/C3hVVhVpRT/Offh9q19ZMvjUZlO753iRBoxXbfN7L0Fh9QZW/VZ5gnv4jjHqhlo8jqTvtyrwqPGqEZtLQObLkL0OqYMwiBjvEicgR8ROoxREKWVoMO47B/5/YfXvRO5N0GxY4Rzjqdca+ywU52kpfHaLpiHOw3HBJlplGFR0fqO8uYs02X1uzfFsDbh74Pxo+e45q9w0BBexmZj4C+9FgW5Umn69OQIeQhg1TF11UECRhl6AAaBbw8OOYbCTY2KNbHIkWZLxMqutfnlnMk/J5dnHrf8CdK3LcNZbuPYJdOzG5Y+SbjPE9UHDfZzSmjZSCHfzwAE2PKsrlSkJHjIheb6Cn1FhP95N6Yi566zyg64w29lQq/6cMTv/djSAc0hxeR8kt6jDDGtQ5JtXWWU/Bn4WvSl0tyafCxncPIN36BdoKFt2UWG/crJmoxexgm7IbG48MCcPjnjMfbqSobXVLCjOLRu6EiExFcy Vpl9jvpV EpbCYQgKu79Jcf3AE295HnaNEtSUFds+lQz3BST3MSFO0m1XfoXvYnlyAAfdNi0D/J96223LqKOaDJoo69TKBxWSHCPBRhMOPmzhsvk313qXEfC2tXdusGQnxxw== 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 Mon, Jun 16, 2025 at 6:43=E2=80=AFAM Pratyush Yadav wrote: > > 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 prepar= e, > >> >> > 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 = with > >> >> > 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 quies= cent > >> >> 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/fecf912d8b70acd23d24185a8c050476= 4e43a279 > > > > However, I am not sure about refcnt =3D=3D 1 at freeze() time. We can h= ave > > 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 Yes > 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. Right, but in this case the agent would have to basically kill all the processes the regestred FDs through it prior to 'kexec -e', I am not sure it is its job. However, we can add some pr_warn_once() when rfcnt !=3D 1, I think this is a minor change. Lets do that once we have a more developed userspace setup. We need to start working on liveupdated that would through some sort of RPCs calls store and restore FDs. Pasha