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 CFB8EC71148 for ; Fri, 13 Jun 2025 14:58:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 575936B008A; Fri, 13 Jun 2025 10:58:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FEC16B008C; Fri, 13 Jun 2025 10:58:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EDD86B0092; Fri, 13 Jun 2025 10:58:40 -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 1CF8E6B008A for ; Fri, 13 Jun 2025 10:58:40 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8DEDA1D6B34 for ; Fri, 13 Jun 2025 14:58:39 +0000 (UTC) X-FDA: 83550683958.16.F8D3535 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id D85DB4000B for ; Fri, 13 Jun 2025 14:58:37 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZtLOza4k; spf=pass (imf07.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=1749826718; 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=nhKrJ3VxQG8V4S5vMNn/Y0gWVH1MsCGarzoAKmD9Wto=; b=Gue1w36NvGLP01+QxeLILZ3T26QgiZfZ0i2BNaczt5TzT+A2WQb+WhwLAcAeNQMiRnbpFs Ade64Avyo0K+A0JCgr7Yul6QUbc/gMIwpqg98ywicExfb00UQRjgUxMb9IHoqVq9vEHJpZ LafSa34TpMPGTJEiH3X88f4dqScG3TA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZtLOza4k; spf=pass (imf07.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=1749826718; a=rsa-sha256; cv=none; b=dZUjqYlJyTuhxS2qMfuPJiBTq5YoaUZ8/iXxUK9rNSYBAAcGf+9p1b6+O5aIDkkUJGD0Nx sU68YGafNfqcTn3efmmm9MHB9oOwRwoL3WGRDBFtDHAXMUw8mTv3lcbliv4az76UW+1w1f GF0e75u4ubuFZTTD0mORfI2Jn0J2fQM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 41EA25C4BEF; Fri, 13 Jun 2025 14:56:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 198CFC4CEE3; Fri, 13 Jun 2025 14:58:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749826716; bh=iB17qoOb8HlU/gXIO+LtqUhl3ctgMUcVmL/kKRQHq+w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZtLOza4kFt33ZPiPPvZkUgKUFAaVPI2F6rZSPV7N0hMGTWjezapJgshD9Sttg4i8m l5k0K0vhi8JwswN72Z+VXR7wuyng4VrG619zkgMDH+ascjJJL6zuIrF1wGF/z6d6Vc lHeiF3Cmo5CwIZhBbf0AfngBPM8b5JlPSnQCUVIHFrvCg4APYyFjwnMe62M1E6MzEl /xPI2F9K+8uFKgLHuD8fKgbmnoo+/fSPZ0+HZlds4VrKVFxG8QcjcATIb40v4Lj6gB rkVA9NyNpRnRMY4k+2JJLiIJM2cnns5QfIVkF9oGS4hfyUXbiswq6VBHnoNrf57D17 9nk3vU67O1/dQ== 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 05/16] luo: luo_core: integrate with KHO In-Reply-To: References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-6-pasha.tatashin@soleen.com> Date: Fri, 13 Jun 2025 16:58:27 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: D85DB4000B X-Rspamd-Server: rspam07 X-Stat-Signature: 1h5194ycgzbtregbrjqup51epqe96mqe X-Rspam-User: X-HE-Tag: 1749826717-956183 X-HE-Meta: U2FsdGVkX1+wgwEjyCF/4Yd58QXtYEl3EPKCLnhe9dmUiK4qrAdvNzcJvIlKlkf7KNoSoQ7iphH4xGLNOjL02xrEv87B1ROp5Asuh0nzsoqV5i9oR7CznvwKpRbOeYN6WOtcpQ9oHqCeraIx6JXzZc32/7WR4IwbZT5VJdrqtRGEFjYejJetW8FA9BWx5gI3g7jEIW+L8tvRDhHYDckX19BI3VWTMFYyZ/PIU9anIFBpuosXRXUIIVsCXdUKU9ZWih5/lSB44L8fHzLHzAHLlNn1GnOg4uhB40IRhYENjIN76NWDDntOpQ1rwLzbJOOAkbnjLyZ1OSXx04ky7y2WUQ0/MDHNjl39vX8xb91sh2He9XxAmf3bIqh0g6FVgK8rTbDhBLvB0uZy4i//yN6t1OPvDWEaO5N4/wH5IvMYWz/rNd2CkgWF6th08FzJm+trbLAAxZeMf1fouX2XrLCM55cs04NK+gsQfNUf/WBMh9pSXR7LdcQDXVoO05WmmmR4idbum8VlJ8f4gS5k4PHfPJUVObO2FX09u/9XXl6Jo96NE1YuuAidCunv4CvpwNXwPHHPfUQwN+Wi0+NXr7VyVSds9C14w4l0X6iMNl0fUCd5EuHmXdoSfjxZQkRRLydVMLYIh5i4DZEAGN2kEGob2azLUBaz6poVRiyOqp4Bv4aT9Xst6qMSeZluILkBLU9Tl9iTGOgBF/6bCDcx3CsMLSCBeksp1Lv8Qf8vhGNfDb5jtUrNIL/8mX0TjjJSNWUZMkyB2cfNPWqRAJ3GLkmeBhMSYMVFyzNMv+K2PjY8NRCv8LNTX6ol2wgtFrLvbpu1M5zeHxN8ulzUvOdNi/xAby2rGxsCSLFmKhpnnMa+EQB54J7dvno+6IUDayuo+/EV3x8B51SRHuTGg3ZVm5D6B4vYtp691IFot3ZoZ61VJOM1TPDfy6ooOo+rMzVf1pP8Ch3RmYEZhr5+QrHLtd6 Y6u0ygjI 3iv+FRUyHyDXMXakipS7MQMEZhnOj4gcJaxmJYRYyol40g76YwX8XmG8koAN6PWde1RoghuyaV4moV9jik8Mi4lGG7nVBPn9WpWfBhJTvy7NEujneFJZKJJZdzjQRVX1zsLGWMY0nEsrphtGIdW/8H/EXwzLRYi7gNx51BgmENqIayBDPxw4jPFUN2ZTvAUS4cZGyXUAv5fioHqIgBYkHpAtNekw1yLI/WEae4zCNfIp5JoER44K9yj+e11kJUfaJBWhB19Fh1ScLHzGadr1yk4aKKJZ+ubqrleSl 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 Sat, Jun 07 2025, Pasha Tatashin wrote: [...] >> >> This weirdness happens because luo_prepare() and luo_cancel() control >> the KHO state machine, but then also get controlled by it via the >> notifier callbacks. So the relationship between then is not clear. >> __luo_prepare() at least needs access to struct kho_serialization, so it >> needs to come from the callback. So I don't have a clear way to clean >> this all up off the top of my head. > > On production machine, without KHO_DEBUGFS, only LUO can control KHO > state, but if debugfs is enabled, KHO can be finalized manually, and > in this case LUO transitions to prepared state. In both cases, the > path is identical. The KHO debugfs path is only for > developers/debugging purposes. What I meant is that even without KHO_DEBUGFS, LUO drives KHO, but then KHO calls into LUO from the notifier, which makes the control flow somewhat convoluted. If LUO is supposed to be the only thing that interacts directly with KHO, maybe we should get rid of the notifier and only let LUO drive things. This can be done later though; it doesn't have to be in the initial revision. > >> > static int __init luo_startup(void) >> > { >> > - __luo_set_state(LIVEUPDATE_STATE_NORMAL); >> > + phys_addr_t fdt_phys; >> > + int ret; >> > + >> > + if (!kho_is_enabled()) { >> > + if (luo_enabled) >> > + pr_warn("Disabling liveupdate because KHO is disabled\n"); >> > + luo_enabled = false; >> > + return 0; >> > + } >> > + >> > + ret = register_kho_notifier(&luo_kho_notifier_nb); >> > + if (ret) { >> > + luo_enabled = false; >> >> You set luo_enabled to false here, but none of the LUO entry points like >> luo_prepare() or luo_freeze() actually check it. So LUO will appear work >> just fine even when it hasn't initialized properly. > > luo_enabled check was missing from luo_ioctl.c, as we should not > create a device if LUO is not enabled. This is fixed. > >> >> > + pr_warn("Failed to register with KHO [%d]\n", ret); >> >> I guess you don't return here so a previous liveupdate can still be >> recovered, even though we won't be able to make the next one. If so, a >> comment would be nice to point this out. > > This is correct, but this is not going to work. Because, with the > current change I am disabling "/dev/liveupdate" iff luo_enable == > false. Let's just return here, failing to register with KHO should not > really happen, it usually means that there is another notifier with > the same name has already registered. Okay, fair enough. -- Regards, Pratyush Yadav