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 58E8FC5B543 for ; Wed, 4 Jun 2025 15:18:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EBE9D6B0605; Wed, 4 Jun 2025 11:18:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E95E26B0607; Wed, 4 Jun 2025 11:18:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DAC7D6B0608; Wed, 4 Jun 2025 11:18:02 -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 B9A6B6B0605 for ; Wed, 4 Jun 2025 11:18:02 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 5FDFE80FAD for ; Wed, 4 Jun 2025 15:18:02 +0000 (UTC) X-FDA: 83518073604.15.886AF51 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf24.hostedemail.com (Postfix) with ESMTP id B3DD818000F for ; Wed, 4 Jun 2025 15:18:00 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cifnpytl; spf=pass (imf24.hostedemail.com: domain of pratyush@kernel.org designates 172.105.4.254 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=1749050280; 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=MTTvHROZYJXrTxQ5yDr/0EZUhqa/R8CivuvUNvO1CRY=; b=MWdjdBCJ92lld3za3KgTmaWf7Xj27IKCcx0/783BkI6cFqaKL+H3zR+NopnUoYpIbXvbvU cBV42aZh+7FWULW1v/FrdwOg42Gpk7g55jxcHp9MVQjWuVjPEvkfml2NriLEZ5EW3TCMCh YQa/70dvQLagTerj3sb0wQ74lTsqD+w= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=cifnpytl; spf=pass (imf24.hostedemail.com: domain of pratyush@kernel.org designates 172.105.4.254 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=1749050280; a=rsa-sha256; cv=none; b=27sQ8RPqZL4A2K/Eq7dTGsr0hiGQ77/7+ljv7pk32vKs02wmzdTZsfPpxDwIyk+5xpAmWr zZsVY6Hsxh24aSuwP3Kag/4yQXJos1pU5ZugruPmQWHlZTlG5yv2KbYbWgltPucRqlWXiY DO/Wf2unievp5g3G1oACfqkVUEpnnbY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id D53B86112A; Wed, 4 Jun 2025 15:17:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E704BC4CEE4; Wed, 4 Jun 2025 15:17:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749050279; bh=EjP0tX3z/aTAdpLBP8CzAHIQr7J/MGL6tjjJP89Xo24=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cifnpytlG90RGruI6sDOS7EhPallxy0BNw64RpE0xSzYWipShW0QF1ZHjyBscGuLh k7eDwaFPh+XMIXF/iuKyEQxOH7ySWyZvdVMi+u7kNfwqdl6ObTUX4Gts59QmX3wcRh Nncq6rP6+SIT9KRtdrDP1wIrfXFxTfXogFevDZkA1P3Hn8f18LdD+Cyb0wc1D8Tx1M /ngsQ1Ldztt2JiQynqjsrzohetey34v53vyDSo2Eyk0rDrgydfhBNIO/+xH9EgHkaC IwEY/TvqZ6RWa3x/ah4pnO52kMq3sYmNyRmNcS5YV9JKqnQ8kkTcMR//9MxvtKwCR6 O5z+/9CQvTBwQ== 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 04/16] luo: luo_core: Live Update Orchestrator In-Reply-To: <20250515182322.117840-5-pasha.tatashin@soleen.com> References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-5-pasha.tatashin@soleen.com> Date: Wed, 04 Jun 2025 17:17:50 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Rspam-User: X-Rspamd-Queue-Id: B3DD818000F X-Rspamd-Server: rspam09 X-Stat-Signature: 175wyaotdc4iiwokdq7wb8wki1tpnruu X-HE-Tag: 1749050280-780234 X-HE-Meta: U2FsdGVkX1/4M9lsxgzngKOSrjnwwR+PxwPoYpPtFPR4czjgCHuXtJYkk8jo/pVJSsFy3QzQXnfQzc5JtKIOsLyCPZvRYoiPE5/+0OAOwrv3FtWHuHSU8qVcTJdsxFUu80gFrD6t4kK5pTx+NMM3MtYaLiTZb7zhN2vcixHxqjabj1J1evPJK4KSUkvUuj9hoPClYrJbYbNvQKWov6Ip5LwbJH89LqeJ2tN5srqsbC1XpzRCVw+j1VAOn4eYMzbVcv+phGNqNca5sFuGICMRskPjbNwBPIW/jwa1vdqngb6tGH/swj+LvBZtK0wjfHSxPrRp9MqLjsYqmy+ZnD3jaWB3a/TpDxXjWaheTtdridpHVkO0jmYCzVKc345pdAhmKfHZp+lDJV4YSDYUs5H6VpN7wNJWyAZtBsDJTg3NTXXAN8PCj5mvJIcqdiOWdK2vW9oYcvqUL9Nvf+ixQDDefV9wOd1qEI2gF68jpjf5aVeHxGBaeNuo2TgyXIryJt4YpLfeXuQ9CX146Q7uJNR3gDyGX4TKyIZskCol3bzcUdlzkJDctgZCcTVtZwcH6J4GoYDctKPk65GIDM62g82gCM43iHnaj5B+XoHMc8uevNfIWNtn+vfVRJbW1rNO2p9pnMLPJaCg18Ju5X3VUI7+aUC8mE74LG92PUNANyC+8Xw4lsbzbwAiDor6uIzVW+73ql2ZN+OBL9cDJQqSmFj6yc1iLpgKuZCQTm3zD/U/KWQ+Qxcqw1SM2VFGXNiqGm5e0T0T3oXdRJ32tRIWC4KvOe0ha2pQG+WYmAR9nHlVz+N+u4sh5kE8UH9TtLPJsTZuTsTbiviN/eIuw+e62/EHlTU1TSolENOvJ/tN0YZGoeRLwcg57P676p49Nd9uoWa8VHj2lZdgBkDQgJqg4YI2c6rhjrOALWLAlO/TUZVQXk5u1vrBR/X+L8YgO4kHHex3TpUhrKzHgXTvcrOLkNP o8qOWS7v qsluoGiUIP6Nznm3eMWRSwxZXGHmvT2FqD8ty3F7Y7bUltw0oFMMYPYiyQMvg3zXcI9mdYi5CD9IPt/1IjMD4Dv2WS6+z70gavtM+FL+UaLPNYwuTrshWnGYX/sH01/YwVtfyYbvilXHBbPZ9jde/3zq2oku2+PJqy8iIN5fDUIn0W4TFvEEUiv7FQ99K+gPY3kxQnU5YgrfZ5Fhuztg+dg0wWUzk4FA5OFOHfQqFvWX3sW4Q7mRVFx3aPvc/jywIbDAO8hR4o+2z2S+jiH7yzhitCxYj6RIT9ZRvWFvxPANgg35Yo5CvFA4Zgsh8EBqoUz2bpOVxF7cSnrnJUyx6ZJhgmwnC/zeNw247 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: > Introduce LUO, a mechanism intended to facilitate kernel updates while > keeping designated devices operational across the transition (e.g., via > kexec). The primary use case is updating hypervisors with minimal > disruption to running virtual machines. For userspace side of hypervisor > update we have copyless migration. LUO is for updating the kernel. > > This initial patch lays the groundwork for the LUO subsystem. > > Further functionality, including the implementation of state transition > logic, integration with KHO, and hooks for subsystems and file > descriptors, will be added in subsequent patches. > > Signed-off-by: Pasha Tatashin > --- [...] > +/** > + * luo_freeze() - Initiate the final freeze notification phase for live update. > + * > + * Attempts to transition the live update orchestrator state from > + * %LIVEUPDATE_STATE_PREPARED to %LIVEUPDATE_STATE_FROZEN. This function is > + * typically called just before the actual reboot system call (e.g., kexec) > + * is invoked, either directly by the orchestration tool or potentially from > + * within the reboot syscall path itself. > + * > + * Based on the outcome of the notification process: > + * - If luo_do_freeze_calls() returns 0 (all callbacks succeeded), the state > + * is set to %LIVEUPDATE_STATE_FROZEN using luo_set_state(), indicating > + * readiness for the imminent kexec. > + * - If luo_do_freeze_calls() returns a negative error code (a callback > + * failed), the state is reverted to %LIVEUPDATE_STATE_NORMAL using > + * luo_set_state() to cancel the live update attempt. Would we end up with a more robust serialization in subsystems or filesystems if we do not allow freeze to fail? Then they would be forced to ensure they have everything in order by the time the system goes into prepared state, and only need to make small adjustments in the freeze callback. > + * > + * @return 0: Success. Negative error otherwise. State is reverted to > + * %LIVEUPDATE_STATE_NORMAL in case of an error during callbacks. > + */ > +int luo_freeze(void) > +{ > + int ret; > + > + if (down_write_killable(&luo_state_rwsem)) { > + pr_warn("[freeze] event canceled by user\n"); > + return -EAGAIN; > + } > + > + if (!is_current_luo_state(LIVEUPDATE_STATE_PREPARED)) { > + pr_warn("Can't switch to [%s] from [%s] state\n", > + luo_state_str[LIVEUPDATE_STATE_FROZEN], > + LUO_STATE_STR); > + up_write(&luo_state_rwsem); > + > + return -EINVAL; > + } > + > + ret = luo_do_freeze_calls(); > + if (!ret) > + luo_set_state(LIVEUPDATE_STATE_FROZEN); > + else > + luo_set_state(LIVEUPDATE_STATE_NORMAL); > + > + up_write(&luo_state_rwsem); > + > + return ret; > +} [...] -- Regards, Pratyush Yadav