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 EA4DCC7115B for ; Wed, 18 Jun 2025 13:16:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 71D486B0095; Wed, 18 Jun 2025 09:16:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6CDA86B0096; Wed, 18 Jun 2025 09:16:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BEA86B0098; Wed, 18 Jun 2025 09:16:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 4868E6B0095 for ; Wed, 18 Jun 2025 09:16:36 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9C013BF78A for ; Wed, 18 Jun 2025 13:16:35 +0000 (UTC) X-FDA: 83568570750.09.90DA09C Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf02.hostedemail.com (Postfix) with ESMTP id C907580006 for ; Wed, 18 Jun 2025 13:16:33 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ankVo7Tz; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of pratyush@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=pratyush@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750252594; a=rsa-sha256; cv=none; b=YCt2MElTzNUP5+JANCWMl2q6UvXitEiMr0O5mYQf3Q17BsZdTUSFO3tsOp4dsFBO7ph81c Q5DsahOLCdiWwS4C6yBeGvut6EFDFX6Ahw3RFfbtxqTWnxtd3PAQngk2p0EAH/o/VS5gAw sxSu9WC2tNWRYBnGAd3Y8o8k/oKwbec= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ankVo7Tz; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf02.hostedemail.com: domain of pratyush@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=pratyush@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750252594; 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=bSGefNmJbTUhG+h8i2TQetJX1N9elir4jh4g0Ve8Nv0=; b=e/OuYJm0VKvuYcVyYefkc143NAJVBT3Du2s8aW6JWaztaWP+AvXP/pQQRt3DIVlO5hfM5t XXGVKEeoHYFs+i0iktNLVW3WChzLM4mU1bu0UGmJGrN9iIjOYtS3QL56c/EjyVXtl572SN vL93YP5d1NEdm1I/uQhpwIhkHYugiX0= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 4B95D4429F; Wed, 18 Jun 2025 13:16:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94324C4CEE7; Wed, 18 Jun 2025 13:16:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1750252592; bh=xjecfFW5v6eKSOI6V0Czl6riZVUJooaKA8suMig3d4k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ankVo7Tz1dI7sCR33wFCuIARshHMf2jU+/ch40Gue8vBjlnfhiTW8pUW/m6gwht9e SzxnWzkJsxnJCThpoj+YcpqsKgZn1K2NjfKzuLyK0fflpMWhWv15VBHgcHqTOOAOSP guzb8ACWx8Si8roiR/wOdJAIeFWhuf1cmRoW1sgkLuPUtIX/bXQ1Ob6XxeKvYzojPV bga3jJkrX+/p0QxYuE1k22WTOeEXeYO9VO+QqrEL/iZO5/NIAGov//Ybshyha58WmZ u2Odxs0G+IuzobOT67lYvX5eljcDYHLuKLnNhKWGS1JjUpOJo7Ka+eD3QrTds9yUSM SLQMhdbwNsW4w== 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: Wed, 18 Jun 2025 15:16:23 +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: rspam08 X-Rspamd-Queue-Id: C907580006 X-Stat-Signature: q9ugrwijdbdgiu3cjfg6ddwchrbk4qbn X-Rspam-User: X-HE-Tag: 1750252593-958673 X-HE-Meta: U2FsdGVkX1/k1J1RbZPM1R4LD835v6UyEzooJUC4ECO6J/tg1YO6dZqtOnfuE9E8PIKlfa/8xZpyaHbtOfTHBwlFh5qj4zWCd4GgigSuIG318ScMru9SAZEkRFXZmTzF5pwD4JLHISblpA2JVKpdVI7S5yWiRkNk4h42L+Eh7eZG1udfrg6D20cyD4qeMnEKmkD8u6ezU0DHlUNxd1L3kEsYeXfztvvNelJghCYue9DEyOHP8LTNDPZDw844o2F4BLB0sB8eRlDQIL6HIyLl3flEUwoRtjGAveVwnPZx/UedzzAhAgHIQn0qukxk92v4U607OK8dvz4qFuqQmhGm7fgYsp/xuJORcW2QradcTu3g5kbK1Zatgujoc+PrPULUCpmLxv4QY7JcKsVwOlyebwMGpB8jmTAWNbFyA7VREPeZxQhEBZhW0/tOU7HGBsRAhNvctxfBZrVR1fy6MQDNY8YoakAP60Oy8ARpv6FIMGDTQKEikGrYlvB5UpSgFB5FrHSvRPToDIktunEeYujXbtr6n49PPLe8ztuKoVuKW1zmfQPcl034KOAbHrQhtqKoqwJpUVE42oeVHg0/jeWwQ21QTJvNgbF2Zbnj3HgvWbQByrt8SoNHxUxvH/8rtb4xmXk4LNyZtYt8eb5RB6n9i6NdnMEBFtfU/ZdB2Mi10EnEAhxAyv8pDBY2MiqOOxbmdyuGFZ39jS0AQ06mrzEP+ewvtT2Coqh+pohF44Ow5GT8T/Zg+XZwbthPnh1TIT7v2+Br6Yc4ocaYi4QbLTujBwPWm4lTHGnV3Jd3+geEaLQ5Cdgds7mtVSU9il0OkSSAwUgfbqPGbRVSzpHYt2EN7QleFGCLKTaWfGsSA5FH0CnJYvU2hyB3ZHUf1UDWhCpEVNSCHgbRhvZApyFl0QknwQPdKU4gsy41oou6nn1c22jH+T39V51SdkYempGrLShl5SjySA0oMeYZ9ULb6J5 2pKCte4g NTULBO1sI9vAr1QbB/+ajlJYMjqSwWfqG6xDPkWuRrWSAivUqnZBcKX87NwrmwifXzSObNPOkkOpxQHqb0VPujyZYE6IkgXMmmolCWckkI4cbPyPshVeQtZTbpKPhwBQz+th+Mwa0AOebjgjexmagZNi6lefhuQmRYhpq6YEr9omzEvJPDwaMiLtxRXcuiwV/Bp9qSS9L3VTonV6jNiKH4Z5ffdrlVNnspQ5DWHFdpjmkpKlX1tbTnIVi+k0rH5tpKoxfcyh3y9lPWRnEweJTa4haE9xNcUD/yb4c4yBoeZep36cAnFRqkPpIyjW7Jtg41UaZFD1cgDqixZyY1xHSTzPGCZ83lWbyivxTXYx1hpU0CrBliM2y1JGMWFNMJ8ArOtt5hxf3TE23CNIdZE4eKSwrHBB+Hy4Xc6+MtGotCf8UZjHPFqcBsDQt9xmPH4Nq05XT 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, Pasha Tatashin wrote: > 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 prepa= re, >> >> >> > reboot, finish, and cancel callbacks for preserved file instance= s, >> >> >> > 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 quie= scent >> >> >> 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/fecf912d8b70acd23d24185a8c05047= 64e43a279 >> > >> > 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 > 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 Or the participating processes can be cooperative and simply exit cleanly, or at least close the FDs before triggering the kexec. The whole live update process needs a lot of parts to cooperate anyway. > 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 Sure, makes sense. > that would through some sort of RPCs calls store and restore FDs. I have been playing around with some ideas on how to do this. Will try some things out and see if I can come up with a PoC soon. --=20 Regards, Pratyush Yadav