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 8A50AC28B30 for ; Thu, 20 Mar 2025 13:36:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A8A16280004; Thu, 20 Mar 2025 09:36:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A37FD280001; Thu, 20 Mar 2025 09:36:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90078280004; Thu, 20 Mar 2025 09:36:13 -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 73AD0280001 for ; Thu, 20 Mar 2025 09:36:13 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 86CF151072 for ; Thu, 20 Mar 2025 13:36:14 +0000 (UTC) X-FDA: 83242028268.29.C7DC9C4 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf29.hostedemail.com (Postfix) with ESMTP id 57EAA12000B for ; Thu, 20 Mar 2025 13:36:12 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b="r/LwXuCd"; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf29.hostedemail.com: domain of gregkh@linuxfoundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742477772; a=rsa-sha256; cv=none; b=b14TamjGbNT95Xn1d+QSkKKMsZwxzZxOdcpPqUgV3KA5hDcXlJ8Gt/mWaWf/2MgnuSYX+1 K9VzfgoSQGPYU5lauILnkGW4+5LI0FBbhy3jI30Xj/k7VWUdcU4BijT4cbcNDx9bHeiOyr QzGW1J9KiOeS75VtJ4r4P7BawJvDDHI= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linuxfoundation.org header.s=korg header.b="r/LwXuCd"; dmarc=pass (policy=none) header.from=linuxfoundation.org; spf=pass (imf29.hostedemail.com: domain of gregkh@linuxfoundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=gregkh@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742477772; 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=XFFkc2dHMi/y3hIf/Gj4dziBO/aGBAEyeYURqvx+rBI=; b=ecMgkvuzHcSXqThK6zqIBQo3P44cmfmwri2bw42JJOADuZ71opaSGzD/UXO6BAO1u8gkH9 BaNxIPIHJEX1OPIqHFSn+j/YRCdYJHiyUMVIhvhmx32DmKzXyZ7xNXn8eoYmahzDG1YvXz /3tnyArnnrAeG35QFIKLhcCQya14sqA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id C0FC161158; Thu, 20 Mar 2025 13:36:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E784AC4CEDD; Thu, 20 Mar 2025 13:36:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1742477771; bh=+nXJuo4PVgrYVzRLdytPzdcjJMPdL09Z4Vn3ItA2wxw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=r/LwXuCd/zhrldkbCAunIsE57gCSgS9itwMKb3ImZMbOZr7o+8D2nQI03PyWDDhxh OmWcLhT5ToBm/Ddz9ne3xn9vXy96MDIK2gg56dXQFdnqX2j1/0n1Y+2i7Kwcw4t6B5 vjBHDrbmsq+wg3QZhMxh0XkN9HRNLilBO64mikKA= Date: Thu, 20 Mar 2025 06:34:51 -0700 From: Greg KH To: Pasha Tatashin Cc: changyuanl@google.com, graf@amazon.com, rppt@kernel.org, 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, 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, jgowans@amazon.com, jgg@nvidia.com Subject: Re: [RFC v1 2/3] luo: dev_liveupdate: Add device live update infrastructure Message-ID: <2025032058-reassure-veneering-0fdb@gregkh> References: <20250320024011.2995837-1-pasha.tatashin@soleen.com> <20250320024011.2995837-3-pasha.tatashin@soleen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250320024011.2995837-3-pasha.tatashin@soleen.com> X-Stat-Signature: kdike964e7uto8z7747x7gua5suhacem X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 57EAA12000B X-Rspam-User: X-HE-Tag: 1742477772-800189 X-HE-Meta: U2FsdGVkX1+MQEVE8+UUFV4RG/j0D2z1IxrfiSOzZU9kX5Lp0dFei0NNia/kYa/pEwE7oz2iWV5RCnc3nJdGKnOA825RRYl4TD24eVHsjheR1C827kMnLHrhLxigVUg9iir04ej/HqmIzr/AR5bla9DY+euWL9/TJ6HS3FE7Bm6R31JTp29BJlokbGEHyYhgauagZsRplFQRw+/EC87zFQoweGMgB41vBQAyBPsU5DAtXJWNFJSsmVGkXegYCBAM1gAEE9SVxUrX91mGGIGdmxAZOToKVpUK5tPADxQgZ3QtTN6GHq3kz5OUL/VysRTDkORyk3RaTPyO8mlIgbV/707UTPInAiiQRsp3LyZOowsBEjgHPdr+PuKjVd5a3NgkemOWt1kRrnF1hZBh8TR7nLsevMztqn7i2O7RI+HuMcTnmVDDvqLpi9OjUI1cqTDHbPfE7771KJu9Xkbg8py5NjL6lt6V9lA/eQ5f6ETKrog/8ElivvRQ5DYMkM+2rfBl2g4dDwj4nuAWmwU+XYe3L37TJz6jW4Hws2jIc2XHOcpJ1jKMMDMES9pJ4LPsoxT23puGExGeL6gx/jIrFQsfo/PuDyUl/G0whCNjGIajmCayCSaZMIx095YtGKtGiWOXqD+h+pzxTZcKbHcrbQSH4YDU80cWqSWTnKwfzd5x/oCRtaEz+Jz30PgfPBeT8HUFzXIr5EWuHHGgPjqRiiIl2Ms+3tJzBhtXvCkFbq0nFHc/8xkGNCk+LcczOB9F+RkUTVvS0ezCDgAJt4dvdcGKTRfaYNi01xyr1gMYSQYg/9g+IvjCqyRjqIv07m/2Byf2l5DSIJxVNLEUIfUFG9DqWhDiMEWy/63VwxQZ07xmc9w4cVodtjz/nghWglGHKsSblTNo9JBj/p6R9cG85lCaPc+HqZVlRlnYXV5Hgezu0hD8A/epPrZIjTjQryfMtzX99FjupFahxWi1O4yWGxk 3pjbxitG Y8X1ASCDnTXHIMOD5Ssv36XdzUhLzHjQw98XHtyBnXcMtZXfp8s3hDLsj1vXQ1OHgGcg0nUmZ61LOmHQXBx2IPZE2aPlpV30OBhobcon47TfSm7NKDzPJQiEkq2spnqI4gyM+r5BAesIn5s2z3Rap8b8pvncrU3gda8nuyU+Y8WA9vAOQRhfu0BXIkXRqlS5vv+O9fK484EjkGFTkT9FbksE09fhu6j+Gox7nea3J57YRA+mV9OWQqo3DdIHFMRjFiV1Fb0dLDFpi83hGOC122i9OYO4gPDRvMjPtZcBuq/NL1SODWs1H5aUSujM/CNku2HyyigqSUEBhj7JmmuNMHx86/vXfxvsj0CgxoIEoW46jRk6H+fgkGesyVhSSg6gtQZ3umQH4hOKkishO1AWfFwutFVBsEUhvPsDvsDrBy4BxyvcFRBSnR4Ha7A== 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, Mar 20, 2025 at 02:40:10AM +0000, Pasha Tatashin wrote: > Introduce a new subsystem within the driver core to enable keeping > devices alive during kernel live update. This infrastructure is > designed to be registered with and driven by a separate Live Update > Orchestrator, allowing the LUO's state machine to manage the save and > restore process of device state during a kernel transition. > > The goal is to allow drivers and buses to participate in a coordinated > save and restore process orchestrated by a live update mechanism. By > saving device state before the kernel switch and restoring it > immediately after, the device can appear to remain continuously > operational from the perspective of the system and userspace. > > components introduced: > > - `struct dev_liveupdate`: Embedded in `struct device` to track the > device's participation and state during a live update, including > request status, preservation status, and dependency depth. > > - `liveupdate()` callback: Added to `struct bus_type` and > `struct device_driver`. This callback receives an enum > `liveupdate_event` to manage device state at different stages of the > live update process: > - LIVEUPDATE_PREPARE: Save device state before the kernel switch. > - LIVEUPDATE_REBOOT: Final actions just before the kernel jump. > - LIVEUPDATE_FINISH: Clean-up after live update. > - LIVEUPDATE_CANCEL: Clean up any saved state if the update is > aborted. > > - Sysfs attribute "liveupdate/requested": Added under each device > directory, allowing user to request that a specific device to > participate in live update. I.e. its state is to be preserved > during the update. As you can imagine, I have "thoughts" about all of this being added to the driver core. But, before I go off on that, I want to see some real, actual, working, patches for at least 3 bus subsystems that correctly implement this before I even consider reviewing this. Show us real users please, otherwise any attempt at reviewing this is going to just be a waste of our time as I have doubts that this actually even works :) Also, as you are adding a new user/kernel api, please also point at the userspace tools that are written to handle all of this. As you are going to be handling potentially tens of thousands of devices from userspace this way, in a single system, real code is needed to even consider that this is an acceptable solution. thanks, greg k-h