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 BCB97C5AE59 for ; Thu, 5 Jun 2025 16:04:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 420706B027D; Thu, 5 Jun 2025 12:04:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3D1106B0280; Thu, 5 Jun 2025 12:04:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BFD26B0283; Thu, 5 Jun 2025 12:04:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 09B2D6B027D for ; Thu, 5 Jun 2025 12:04:10 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B55A2C0F1D for ; Thu, 5 Jun 2025 16:04:09 +0000 (UTC) X-FDA: 83521818618.20.DB33D1D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 09FC81C0011 for ; Thu, 5 Jun 2025 16:04:07 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DhFWAWYD; spf=pass (imf20.hostedemail.com: domain of pratyush@kernel.org designates 139.178.84.217 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=1749139448; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=iJ/06LbvsSuUwde1fOnSbIVc09eHo98JrRGMzbeAP2U=; b=clFUcAbpPbZz/3FTL0bPaVSohUwDwdQcB5vHXbfo+DjW6SnlEzG+BUsrtCZbbZxo9aCXam J5W/pUbbGOyd2OnVz6sWFyeBplRHUTHvaGz2R6fpk/xKuHKUs8y8n0/8HxjebwrCvu5RUU dbGsGEqvs8xb10ENesh2ZHBu4G5CWqg= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=DhFWAWYD; spf=pass (imf20.hostedemail.com: domain of pratyush@kernel.org designates 139.178.84.217 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=1749139448; a=rsa-sha256; cv=none; b=bbNR8b7BmdQAcYM6ggkjbJ0HoFBrsDmtP//Lp7x7xBJ50UjgugpyCwH8PnyRA5asi3Be1b 6ac6nj5kH569acdl+TaFK7Ht+bPF4/dKKFX3kKn9Tze/bacj4wFqJxwOxlK8Cx44CrefLb +X+t+G36s01HvOSKbuF0oKv3vaByriE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id F22D65C68E0; Thu, 5 Jun 2025 16:01:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5038C4CEE7; Thu, 5 Jun 2025 16:03:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749139446; bh=UBysjsstSD1/iZwyVGE2p3qHDV0cPt51Aznc735XX5Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DhFWAWYDYDW66Hdk1CxVh1q2U3WmYDn8ThTTEN3uyutmc4T451vDPZzY+2IBkWRio +W6dh7PUr9A0iphvG+p1zpmq7H+tAJgvBWbOpBKZTk88c4xwVwH1C5dzHU7bdo774p h6xY9UCTaC37BIiQlfD8X1q7Dl7aQp3MWRuNTTXOAg5Povu/uLHJCeQYB6G4dyZoks Tm+ugAlfgXMsJ31oGiMy/Cd5m/d3dTJZROmXBp3BUiprR4r3meaNyQA874bB6XaEnY l2m14LdFFmoon3U8qh4RSZKLOL8mrBMWF2fQuNnlYMGcb3+bw5lTIcnkQsmGduam/x Rhy9/iPgb+HKQ== From: Pratyush Yadav To: Pasha Tatashin Cc: pratyush@kernel.org, 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: <20250515182322.117840-10-pasha.tatashin@soleen.com> References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-10-pasha.tatashin@soleen.com> Date: Thu, 05 Jun 2025 18:03:57 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 09FC81C0011 X-Stat-Signature: b73skgx99z6tjqdmraxegmgew75n98ou X-Rspam-User: X-HE-Tag: 1749139447-729728 X-HE-Meta: U2FsdGVkX19TNGYmq+lNPGGD8pmfvoGNRxxDOyMlJAB/L5hzfShV2bhs1Yd/j+0GKAgn0wuX0prcBx2S7yymFdEmboQhBYbFgCDIMokpyOsaKR+ugAYBHM3c2ZiBp7yCc7AtA4GShF+DI89i7DAHFvPpu7gMUuTxAOiKzqhMt+3/HLZnx5jaJ9s/SvFKfIBfIyzdP0fNY+8c4NX8L1i7+cJ8B+bFKCBUeAO0arzA7Wj7dutzXfcMNOfzjO4sTiBRFtMEu/Saj2V1WK9CLWtB/pORfUDJ5aSzsL7uxHXIwCdhpfuP3HRe3CCwbszRqbEzCN7GKO7EtH+lqDE4AE+AaFxbxFLHeD0qfPcGPfj00fKtNyBG6hLhbahuvEtPiGJLZoOMSvGTN9r4cv0GE1cg97jHDWDGilaOnFz1X7nGrpBYJ2UC2h6isRutuRElrdiu+68vCa7Svjf0wwARrqgLI6wkM+5pXpoby64OdBBuTVroPm/UN/1hn51k+9nPGQ+3H3kXefCGQ2ALfCU1C0D9qGueZXH++R4vT4nqU+4PSdHzs2Unxnp6tjIKcPzvzQp5Atun4F9/3jraTVlcs4QaUv8atFFLaxlfUnScDdyPUPTID443Ts5JhPl7zw9a9JwjE5MGfCB9rdo6m41oiJCRJ/IqdBPYRQPzgqr6Dh41EMt9rHYeBvxo3F5otkmuYbW7wYr0YMakBwoW96eTkYT8qSyrvXx2GHqm3I9l2mBepLrL0G26kc5TU6a0oclJo2AHFTWwHIXPMakpi3Am84rrRssIZrgr4lpxIqzkM2RitYpdDQtRg9pkAea7yQBJnaD+g8KfDetJ8cUq4LBgNObR8qbDGUetTKnyzFMh096u+Xp5DE9t/muiz1s5q4U2JjWhcw9/QG/g/uzC6J/8EpLCbLvkH7puYPElZomyo0+fNvdexL5hwhg/ksHUg4pFrdHx4RseMsKuBdKsHhmtcf4 RC1LFoZu 3rSqtrZRvCex5VaxZSEvP3wBnLV7/M+UvGirfQuNVsTTv/saH0cCrCltaGpGcLtifNR9YQrsvQAsDWLNU4kfa500nqSLl+HbwwxmVmj/BUB5dszMYv/FyPxNeLdS743tT1javdVOUXrvkp1bwPqqRLM+usNzP96llifPYsXylkTLBm6wcqTIDWrvTUMAWzO28c8fJK3HMEpix+bA8HiVSx88C7FbA64b74KHHzEm7I79gIm8nfvpM8wCi2M/gD/QitmuKASsJ3K373modreHNX2o466SHHqNXW0FEHkslNy94u5Wf4fQvotTsW3ItSmQcCrGbRC+2jk+onnB0KO2gbsXRdvyDdLb1fofv 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 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 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 quiescent state to do its final serialization? This conflicts with my suggestion to have freeze callbacks never fail, but now that I think of it, this is also important, so maybe we have to live with freeze that can fail. > + if (h->fs->freeze) { > + ret = h->fs->freeze(h->file, h->fs->arg, > + &h->private_data); > + if (ret < 0) { > + pr_err("Freeze callback failed for file token %#0llx handler '%s' [%d]\n", > + (u64)token, h->fs->compatible, ret); > + __luo_do_files_cancel_calls(h); > + > + return ret; > + } > + } > + } > + > + ret = luo_files_commit_data_to_fdt(); > + if (ret) > + __luo_do_files_cancel_calls(NULL); > + > + return ret; > } > > /** > @@ -316,7 +402,20 @@ int luo_do_files_freeze_calls(void) > */ > void luo_do_files_finish_calls(void) > { > + unsigned long token; > + struct luo_file *h; > + > luo_files_recreate_luo_files_xa_in(); > + xa_for_each(&luo_files_xa_in, token, h) { > + mutex_lock(&h->mutex); > + if (h->state == LIVEUPDATE_STATE_UPDATED && h->fs->finish) { > + h->fs->finish(h->file, h->fs->arg, > + h->private_data, > + h->reclaimed); > + h->state = LIVEUPDATE_STATE_NORMAL; > + } > + mutex_unlock(&h->mutex); > + } We can also clean up luo_files_xa_in at this point, right? > } > > /** > @@ -330,6 +429,8 @@ void luo_do_files_finish_calls(void) > */ > void luo_do_files_cancel_calls(void) > { > + __luo_do_files_cancel_calls(NULL); > + luo_files_commit_data_to_fdt(); > } > > /** -- Regards, Pratyush Yadav