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 B1C66C5AD49 for ; Sun, 8 Jun 2025 13:49:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E7F386B0088; Sun, 8 Jun 2025 09:49:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E2FC36B0089; Sun, 8 Jun 2025 09:49:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1ED46B008A; Sun, 8 Jun 2025 09:49:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id B438F6B0088 for ; Sun, 8 Jun 2025 09:49:55 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 52D26BF411 for ; Sun, 8 Jun 2025 13:49:55 +0000 (UTC) X-FDA: 83532366750.05.761CA2A Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com [209.85.160.182]) by imf11.hostedemail.com (Postfix) with ESMTP id 6ADAF40002 for ; Sun, 8 Jun 2025 13:49:53 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=Q+n2ZPaD; spf=pass (imf11.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.182 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=1749390593; 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=4hF+6UtRohKpdwZ1oZTfYRlxr9mBlwqZ6G0URvhQTB4=; b=N1k/V0sHnM/wXPvfJanJtmerhR+fGKFPPx5uvHWpNy8YBusMKrONf7Ar2oKrhiOK4v8iNz 3S5/c60jnb1kaTz5QD5uuA94AQcwFzDYFSKy4EGb6TfLaNl50xd29Rpf1SFoptGe0OTPhO keP6xX9LSZuIF6VC/zzH6hje/yzvdaE= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=Q+n2ZPaD; spf=pass (imf11.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.182 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=1749390593; a=rsa-sha256; cv=none; b=xtyg/y3gr0QLt5hcfb6gVj/J9fU9wwZ0NQYX7b8rYZasp6zMXyXiBd+7khGNwmNsI2RdbU lPur0hc0Dahxwta2lxCxn88RLUHgRJJZr8XjINmCnUw8XHNmGZWI3lF/H0ltuxCPpodQ34 cp6xEBUccVs7tcg/6iMvgpQhdVyFz40= Received: by mail-qt1-f182.google.com with SMTP id d75a77b69052e-4a58d95ea53so39692111cf.0 for ; Sun, 08 Jun 2025 06:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1749390592; x=1749995392; 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=4hF+6UtRohKpdwZ1oZTfYRlxr9mBlwqZ6G0URvhQTB4=; b=Q+n2ZPaDBf/Hz6Khm2Ad062pAGsQxxPtZSVX3h5sGXFJgdmlc8SplImK1Lc1zo0Zcd fUax49c1kmPioTQ2N9+gNoN+Abdba0oMidG6YczazMsDowPYqDe1p/+PKZVRdmHiYT25 pi0kPxCr12+zcL/mbiKwBI7oHfxMHDb7bQ1zE12hfhxhkjvhXfquPV/vWAPCbQWLZ73k t7qaxwRiv3KWrMOBiDl/EJpxCvNm66oE97X5uBGO9oZTggF7VMYl+H01jQyDm/PsOnNo HXHW5zlfL4Wqd00UtGw+bxvJYWgDEgIRWe5AiFnGe/yhkghEcDGhp8088Wez/Wo6C/F6 aP+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749390592; x=1749995392; 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=4hF+6UtRohKpdwZ1oZTfYRlxr9mBlwqZ6G0URvhQTB4=; b=Hytm/+vyWWeOMlqNI5trAfBuE+NfMhMVdpzBBpOgTR3mmw8coumY4WowaI1DKIlgL3 jt4N0fAaZDZEjpqpi/7dCMeG3pPrg8x+iKduARuecK2j3OayXsti/XJlLbmxUFdgdyIA SAgr/68jbrMHPcNer5B8pXNaBC8PSy/cR2s9/4s3XgLwTcm2ghx8qsMk3qhJ7h3y4E7P b9zOIJ08JlGB7/JldYYTwwiXafm/os0TTh0X7Cmx2/GJ9DwM6an7QKzoTLMhP7eZ7akC ggkSJNAdIoZAvLb1YHfpJ3gGWS9nIRSFJ+G/nm3tMuVMCUf8NXDR1jvtmR9W/ix7GFzl HwQQ== X-Forwarded-Encrypted: i=1; AJvYcCUmfFjJ5q1wI+hrg5efCEEzPrZx2yWD4KnjYFIzsQM73yIkTi1G4wRWAOAGusF5dTvwSeU1veUpZA==@kvack.org X-Gm-Message-State: AOJu0Yya8Bw414tfoFYpbcyhgueLeT1uu51a0DzNbYTdkOTPq/v6tUuM wzUWMCiU0R3qltHjQNCi2baKGp84aABnD2A1hIETaB0iGRgJnjMMhkX8VMTMJfc1J40vvkbf1QV 54i4qOhyZR0+m07JjWjG/+KTOE/zRALbGlv1tdYm+Gw== X-Gm-Gg: ASbGncs61c+T42GZ1WiMKb7PiFpP4z9H17WDfwGNMW5gN5ZrQztJnvBy27n6DZAsbVo uUhfYN79pTDIv6WKH927i58oPdNIDPMTwPzsl62k+gYB9kn6R/NgwQ1r21Zm7OMXxwYs34WxVAy 1rCOBu4TTJ4qZ6dcHgaWS97pLjBpHjGw== X-Google-Smtp-Source: AGHT+IGaVOqjIzAB561vdH5Hbbg07f5eH4frJqvp4egHE/9NCFYNrscEPGV/Tobtkh4P8BLSDloZ7s9mOifSf/ln61U= X-Received: by 2002:a05:622a:5a0f:b0:4a5:a598:bd8d with SMTP id d75a77b69052e-4a5ba9952c4mr182042171cf.0.1749390592477; Sun, 08 Jun 2025 06:49:52 -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: Sun, 8 Jun 2025 09:49:15 -0400 X-Gm-Features: AX0GCFsi4mFrjkMNphkUTbPiCT0VoL7ft4Nnhm6lamBfB757JhUYg6mKdNCbvJk 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-Rspam-User: X-Rspamd-Queue-Id: 6ADAF40002 X-Rspamd-Server: rspam09 X-Stat-Signature: 7i5q586u14incipwehm86wguznxdj5yu X-HE-Tag: 1749390593-74152 X-HE-Meta: U2FsdGVkX1+6z4VNA2Putq+TRwQOjTokalV0GfGVUTkELULHzObuYGwsfyZaxHJtXGnk7+WZw6QPTq6zzD69FqNMOPL1b+dehExqnFS6rkhhVsA6z1Z5G1whYLf77COnTcEH9FNLJdzqof4dkQ/c9AXp0wOleoTvBnpRGLc9k1V5NbA6h8fDvUyY8aDko1HWxoBOyuSmSeR1mPK03Qm3LvSqIokoaoYCqTmq3aXgZr8jH8gXq9kmhzgZCBAgMjFdXS5jO1sPvwCZUfBQdD+J9sWZrU44Mogl66L8Pq05fxwKuYBY9yEHp4/y2zFSh0oTnD9jO8JsK81VhC2z1fwKgdFlDIutZ3t9qqlalC3o9zDlhHCstG4pFlxnhmcqbi3GyEpsAmEjiYSrapFHlcfLLL/YTHpKWJkkcklFMcaKRL7V8rFmzMxD1GMXY40D44t3g0EC8ydisfiaH88toNTSYTw6s5KUHefxo7qK6TVUFX5Io0c9vt1MDtuJXqg7XU56MLJy+awC5qZcPJ2mFgJ6Y5WTNuo/rhn8gLqvu188rS7kS3wuk3l9UEbWwEM3i8EJRnDaMezDVh1cVm3O1UjkdJol3X3lsGSe/AFPLwtZe9NznAw3L7cTwGIhq3u7c2tPXItkTgJHe7YqOr7ITvor+msgLDxAvpV9r8fdrw5adqQQIbg4vF+PaFTTU/fwPL0qZaBTB5hJEJlYRapFrrUj3ZbwTq5PShg7UNrJr5hJ0sUwbXgDDQNdkn1eM71E0mtbZ/qCeVB6WfGilwsa1DrpwvKxFvshL9VkF9y6redFMW8ZvU/QzlFJ59ygdvq0na5ga9yU/VZegBE/FDqXK7AEp3471wTUQvIU5OQ8T8adykUbXllwAIfwkSHAtYRNhqKc8OntcIXPHwqBFW1ZlvdkoBxwNX7S130KFX6u2g4INyeH2ItwpQZjUOA/FELMejtcDY2yZ+XQqYRhSRprhrK 8RBzBfQ2 0PMJ/Itmsgd9g7vAsadRZLrLjDsi8VFVQf+DGJnUn8/+JIBf22shFXOBaCbxxwzEyDQFpRpXZxjrjiOgBENaWnEwM+kciq4HfIj9nAJq1zN0r0a61DPFX1TMPSW40Pl8CdIPUAKoPlFrXiPf9cMvlVZH4j+GO6ivWL7617CXUnn2pGqZ5WQ7NEp1/n/EHCMsFhgAPZcLet06H6tPGxvWaKYVT4vDNbuu+cRuYhLP/5OghOmnB1FC+Ad65YDrIW24534+l1BVHUAr70gjdw/FIdhb+mar3zzPlFSwmbIT23ozBJyRTKcGivV6oTWSzkclIezsHnmqqh5aYLyNllORCqQGYWcc76ypKYUT7Xudv6hmSlP4iBEl/u58y4fRkfygTmXQdIuw04kUS0JwRr5vZv144+FfRf/1lInW6CJILu36hM3ZNPenaQqcYnn3305Ly3cdcXNR62PjkJ9Q= 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, 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 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? 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. > 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 =3D h->fs->freeze(h->file, h->fs->arg, > > + &h->private_data); > > + if (ret < 0) { > > + pr_err("Freeze callback failed for file t= oken %#0llx handler '%s' [%d]\n", > > + (u64)token, h->fs->compatible, ret= ); > > + __luo_do_files_cancel_calls(h); > > + > > + return ret; > > + } > > + } > > + } > > + > > + ret =3D 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 =3D=3D LIVEUPDATE_STATE_UPDATED && h->fs->fi= nish) { > > + h->fs->finish(h->file, h->fs->arg, > > + h->private_data, > > + h->reclaimed); > > + h->state =3D LIVEUPDATE_STATE_NORMAL; > > + } > > + mutex_unlock(&h->mutex); > > + } > > We can also clean up luo_files_xa_in at this point, right? Yes, we can. Thank you, Pasha > > > } > > > > /** > > @@ -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