From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 607F21F3BAB for ; Sat, 7 Jun 2025 17:11:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749316313; cv=none; b=O4PptHKJTGdiyERZcMC21lfUCp+Ym90HaEvForeWOIlAKMD0sDkhFF6O487kBpj/MFqHjwuIS1wwtAf0iedFhlDkXoDIs7i24qGjGdBRsM3SukGvAOVCXDES8QK3YK+I/DJR6cXG9O69HunvQYAF5YGEsHDNUy0vnami4jMWUz0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749316313; c=relaxed/simple; bh=xCjDvC5VWjJ5q6LZN7UNywkRQBZa6ThceH1qu0z8bUo=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Zk9h1FA1VL1xy+sCl0fzBcCnI1XmA6BRTbp6rXd2AuSE7WVQfu6PS/mP/SyzozDjviJL6h51DZmH78vQem01Bo6vWpDRUaCvvAHiL5NwXBLgs4H+xbVpUmSSiv5UcLVGSXVCUQHPt6qEucRMS9bOPTLwjU4pDjG+CtxNtaHa/NY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=soleen.com; spf=pass smtp.mailfrom=soleen.com; dkim=pass (2048-bit key) header.d=soleen-com.20230601.gappssmtp.com header.i=@soleen-com.20230601.gappssmtp.com header.b=SG+A0ZfT; arc=none smtp.client-ip=209.85.160.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=soleen.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=soleen.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=soleen-com.20230601.gappssmtp.com header.i=@soleen-com.20230601.gappssmtp.com header.b="SG+A0ZfT" Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-4a43e277198so24689851cf.1 for ; Sat, 07 Jun 2025 10:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1749316311; x=1749921111; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xCjDvC5VWjJ5q6LZN7UNywkRQBZa6ThceH1qu0z8bUo=; b=SG+A0ZfTRvZ1EZK/PAFxgmd1jwdfVOqh1Dy4PV1c5G8fctyAYa1SDMXn05MhoQdAOU 4Vxsq2iROyiWYOP+kvsxKyO37gdV7ohriayK9mcUdgQ2cOXfdTcYrjRT9YcrzxzlrevA 9SGao3NbD2fNDZ19cg7nwsMpjI8T3PmXjug3RUOmb1EnIqvnu88nl8VD9s87/RJpHpvM pXn5D0Y0TaO3m6y/foqoOAQitkgSFB54l4kM3PQNjLU1frVacURCXsdq9NQDs8ROvnU4 bV68dcpMk+/u35N8KcpiBKrAxX5UtmqaqpU/JOByX0bJPcSFDSOiiXuR1RyTGABSY53M mwTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749316311; x=1749921111; h=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=xCjDvC5VWjJ5q6LZN7UNywkRQBZa6ThceH1qu0z8bUo=; b=UDJ++UWgSTwlnxP2vwHEVxUaaY+/22Rg09dHU3TJej8Twi62Q3VgAiCUEMjpA4Z9mL Mj7617eEGlru4QmC0jzkT4pH8b0SJldZolBhMLWhZrTMsyVd21XNfsh/NOyL2zBDl+4J bfebZrkvSgqMypG4DPKah2gLpRl2yJbRD+NpUOEInBWoT35vioKD312ZH3KJiifwIFkq U0Lp404bOLkZOapaNgJYhAaNB71TjJse6cAASLHv+mxGACj4eHfp69kgnotX5jl5ox3o gxm251nhEiuezk/F/7DpGiHQyzmTdEM0IthyHtL91f1YjfVfhRR2xGaDT10HOcPga8nb ZZqA== X-Forwarded-Encrypted: i=1; AJvYcCW5QN3p93a69MD4DpnjhG5bJpqHlyFOq2mrnqOD7TXiII9QfpOFmAU/pdN2j0B7EpZCkSzbUEEGzM0=@vger.kernel.org X-Gm-Message-State: AOJu0YzwR2lBgwCAubXETz+GnoZbGGIjmiAEhZY+uWpcGWoO1F9ut/K8 LR29fSxeFCec39qeIH5ucLRsPOzFNMIpcMD0bOfHCGD9mx45scazPEHnRpdNcw5LV8d4v/CRlPa gh08l6hnth6e+K7Df16MJyTCZNbwfwkYmgoCJ0JsJ1w== X-Gm-Gg: ASbGnctoiL10tjZcVB1a4YzPkRw5U+Lfe5bzUmuPgXzEMM6oSAMWKR5AYfmVAFjie/x Wu3YO6HxxOAVsZEZH2JNZdcNk5P0/XbPik8xBIdUFjQ7mKIaZtVZjHofq64bAUo74OElkpctpQV CtMYQv4nyKP+RQGMnC5HWj8WrmSei+xJ5Eocqs1x/xbcOFvFYKn5c= X-Google-Smtp-Source: AGHT+IHlSewL0I2vem9w0XYHFAWl27pFyN/ynItNRVl7X1CCmIYg2bBDpzo/TCiXt0R5950IoAoIr0C9zLp8Pm4BRfk= X-Received: by 2002:ac8:7dcd:0:b0:4a6:e7a8:65b2 with SMTP id d75a77b69052e-4a6e7a866a8mr81570511cf.10.1749316311198; Sat, 07 Jun 2025 10:11:51 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-5-pasha.tatashin@soleen.com> In-Reply-To: From: Pasha Tatashin Date: Sat, 7 Jun 2025 13:11:14 -0400 X-Gm-Features: AX0GCFvnA9qdFD2JyIoGnpA5SZYSuxL26F_4ltSyZwRGc77_a-JtPWOeIGmCXfU Message-ID: Subject: Re: [RFC v2 04/16] luo: luo_core: Live Update Orchestrator 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" > > + * 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. > The reboot syscall is allowed to fail. Since freeze happens once we leave userspace, it is the only chance left to conduct proper verification that serialization assumptions have been maintained. For example, if, after the prepare phase, some mutations are not allowed for preserved resources (such as DMA re-mappings, etc.), the freeze phase is the only place where we can perform this verification and return an error to the user. So, while I agree it could simplify the state machine by allowing cancellation only from the prepared state, I think it is important to leave this ability for the freeze phase as well. Pasha