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 30A7CC77B7F for ; Tue, 24 Jun 2025 14:28:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE6056B00AF; Tue, 24 Jun 2025 10:28:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBDC66B00B2; Tue, 24 Jun 2025 10:28:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD3A46B00B3; Tue, 24 Jun 2025 10:28:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 95F2E6B00AF for ; Tue, 24 Jun 2025 10:28:37 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 169C45BF44 for ; Tue, 24 Jun 2025 14:28:37 +0000 (UTC) X-FDA: 83590525074.16.47CC21F Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf18.hostedemail.com (Postfix) with ESMTP id 18B721C0011 for ; Tue, 24 Jun 2025 14:28:34 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=NMMtelaj; spf=pass (imf18.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.181 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=1750775315; 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=uDewiSmD4MwwrX0+a8LW2QGw9oFX/YyFBm3ct0LvRo0=; b=WMHYAJ7US90SGybAxkLSZjNT66gWoR6aD7EEQ/37CcY7MU0GtRbfeKISCFqDOD73xiz0h7 E5fGTVMZqlkghu0VPRFPHtIgF95F3AEutWprNkm57VUteYON2CEiG/XWS8zpCrBHtPU48z acFOBnt6mXL2gPSoVW/x5oycCdJqbo0= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=soleen-com.20230601.gappssmtp.com header.s=20230601 header.b=NMMtelaj; spf=pass (imf18.hostedemail.com: domain of pasha.tatashin@soleen.com designates 209.85.160.181 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=1750775315; a=rsa-sha256; cv=none; b=wQbAfFj5LGQpwiIKGp+uijZoP2Rx10RC/D6aMNfruadVM+fFwNI9f4H44P8CDh1tvt90+h fVsjd8D4TwyK96vEop8rKRcJQNIhp3+8DuB1MN7ikQ4EBYgpwYuzPSj/Ag6gO2LrKBRazZ i7PIqBzvaOXsosQUgLERvDeABvsfPyg= Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-4a585dc5f4aso5306711cf.2 for ; Tue, 24 Jun 2025 07:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=soleen-com.20230601.gappssmtp.com; s=20230601; t=1750775314; x=1751380114; 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=uDewiSmD4MwwrX0+a8LW2QGw9oFX/YyFBm3ct0LvRo0=; b=NMMtelaj3FTdq2k89Wqj4VYQ2BebZBBVHiSdvk8cp0Db2k5bXlZdCeY0RpNqRThMcv 8+aES0DU10osNYt2NqXF/v7xUvNaRB3ZhAhQ1h9HNYwf2qRvcL6QEsYuTrhPshj2wbGk e/rJTYAn99KI2wYNP4aiOKpaPbshOihv3S6yi5chhH8NoPPavWNDHsEbFxJbx1aYS7O/ POjM0fvTEdCG7D4RLUBg8cJvIsJeXu3sJpCba+CNd2oaa+uGJ0kBZvnEo6cfzkDeLtMs ae49HTH3nlIul0fe+CT4E/2cOhfCMbbzZrShenwAL3tIINoQbpEwkLuOv88VJlJTFXh0 PYuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750775314; x=1751380114; 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=uDewiSmD4MwwrX0+a8LW2QGw9oFX/YyFBm3ct0LvRo0=; b=FEhKe+N9vbm1N3BjLWP+3DXIt+dUU43+Iuq5QgQTWv9asXIiSnWJHV+BVtYxXys8Wn DotLl2TQZuir0LX2MqeB2xw8GCkKO+36/d/O1d/dLVZgKSjOEB424SI54YLRYvoFl0KX 2r4lafbl67LJzouzXZ/+BYAmocauXbmFmIOVkbqf9nUajS52JaIPdx4yKhGaTpziYJTy yNSj4QLhxlU3B1ip2Sfi7TGrZU2Ar1VMV7ODdBfuDdWI34nx0HoYSiMrDvE6tfJ7lNTK ga6Z8NGbWBQ/CmTlqVxaqDoQbucbDllME/dK6uJ1ssxwYr//jTaUQ5oPYEpzfD3zPHkD 0eHg== X-Forwarded-Encrypted: i=1; AJvYcCV3ce9dcEHSKjigk4E2E4zJQ0vYPjsL0/1sXCBZgeOH2UtjkPqulp/5GMlPCe8z4gI5bJTpSGAu/Q==@kvack.org X-Gm-Message-State: AOJu0YytrR7ig0iFdBxTmo0sh9cE6wvgfPH+ZVNok8KEvmUkW1JjaLIF 16cykvry+/zaka/U03pmyTxOkpbtKHq4/iKihOCAlVYWga6JvokTJ9sdbHb0P5drggOLkHFS4l1 ALCVZyujBr1VGujDBZLsDpssRGOTLAawVOtIMayNBkw== X-Gm-Gg: ASbGncsDYGpCFzQcZtFgx+iwo8Pc0EEc2S9aE5gwpH9Ld7xXvz/Mtt5t71c0n+Nmcvg mJxRCMJs4D5xhwpENAicifU1BGGovd4F3sXEgeYwdW2I8XiklGRb0lbhR1JkYUIpapRgm2hpp67 LPAme+UygJ+SPzRVmjhb5YXeoZrc3VNSbh9GXQ0Znkl51X7NR8tkY= X-Google-Smtp-Source: AGHT+IGFEQhzykPbe/44QRJkdNddUzd4cfvP60odxaU1YoPeESZ4f1vixxl/WUpJLfMlzvla3CLnCoyoFqQUs9WlBsk= X-Received: by 2002:ac8:5849:0:b0:4a1:3b18:598a with SMTP id d75a77b69052e-4a77a1fed3dmr258991591cf.5.1750775313494; Tue, 24 Jun 2025 07:28:33 -0700 (PDT) MIME-Version: 1.0 References: <20250515182322.117840-1-pasha.tatashin@soleen.com> <20250515182322.117840-11-pasha.tatashin@soleen.com> <20250624-akzeptabel-angreifbar-9095f4717ca4@brauner> In-Reply-To: <20250624-akzeptabel-angreifbar-9095f4717ca4@brauner> From: Pasha Tatashin Date: Tue, 24 Jun 2025 10:27:56 -0400 X-Gm-Features: AX0GCFtlnh5qP7763PBCjBm3puXOqOkkcghSRVKRQ0u-_lovPxMsol3pu7S1kPY Message-ID: Subject: Re: [RFC v2 10/16] luo: luo_ioctl: add ioctl interface To: Christian Brauner 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, ptyadav@amazon.de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam11 X-Rspam-User: X-Rspamd-Queue-Id: 18B721C0011 X-Stat-Signature: p896tcd8xibnt5c3nipjmmqzytnbjw1m X-HE-Tag: 1750775314-378153 X-HE-Meta: U2FsdGVkX1+sMgIYh+nSf+HHl+PRLv/3PECiG2/u4lZFjTlpxDgV89ZI40GOn/rEgXnp6OFgEoTyrZUUzPay2EJenKMbCZ8AdVR+5gfday7wyJrBe44iAnuR5tZAOYE99RxYwKTwXWt/5SRb2h+pdtQswmcZ9X0/G9EqtdfVMr1z/TybA6z4NK9mr1oGm55eVgPg73lGi3WtS3lLBZF+gbM08GMRSoZ6sHHz3PsdGCZwhiE2KR7930bST/4nKzsppAduYRVyooUTJKldvkBkeivvecBgWesy9XZxcYAAnwWjP3J7HY67Ma7eKJ1NZERlbc6oROEX0fN8gv9H0iUGLNeeBmQeH8EKx7yK9naB56MT6BpWycjXrQeP7zFu/f2luoscjAsSL+I5zUavEUvT8A9PYS42Kd6idb0+pw9r72VnD8SfToQY13q66ws+VI1lhql9ISZ7sTMu2old/Cq2xFLbPRLQ7AMuYSQUdXK9oHaXYwhKor6xYhDg181fAE563Zlgbw79lhm9EjAUmMGhIKy3F0p8MXq/gTKlrT56cABovtqwXAjiVz2MZtiCB1FhrUVBEWLzx601K3+VS9nq6fvASAJHBoK0/LqrRMldYPqTMOKxd9XsqfIKbC+48lmbMe9/+uYwE21Jtby/pRYdG6w0921j7ItRkVoJPlJyLN+RcCzY3UQWm1zrFcw1+xHHgEwCmVzd02wqPSDtduY+3VmKk5z9KjGNFIJPL5V71F0q1tqQTUUx+9y0g2SJAoIuV0TOq8iz92m4FFTnUIDyAL5CRaP6t0mzu8551DfyErPH/PYWXZOIePDQDVDswrIfWE+EbbkJQmfx+tHAoH6CftKueALsA2JRTjw5kIUznsV/0ykIzka6OqRNu2jrnMNdiMPi/sqxOiuOUEG4gwwXsdCRG2xM9A+5eRRZSVBThiVGgBAetlzBAIOJ7BnvuVUJ2cVVpYBWa47H3cnxbNU vTFrD5WX 4nkrS0NQluxO/8WT3+yR2QJ4c0tnAuVlWw0yz6+ZFl1loIueLU/WQ+Uct0hQz3QxNYsGVy/2rceGP83IXuAt0NWjUptukUmpid2EGDqQFK7n9DIc/Mcx4T9pYDlkfeWn6rjZmsj2fuz+htux2MC6WFweN0ZQxYQUe0h/JId23DwYuYRlUvhFsLkOjF1Hzh9lKX+UuYADK8rrOXxfsGOXyQGmULbu2jE/jmRGT57t6Vqa+nZBdRzOxEr7zUFcYGE/HZJAsGSD5tsA5Lx2gPH0CQrcYnbITzobAztS/4ye0PhMw4pIBcjNlTyymUd6WoSwoQXvGg9kx9nO4+JGIB4igMclcqVVaBKkq3F2XM1aVug3wc081cxetDCdaImnQ8v+aPWuBTQciCgVa5pSWiF8yylThZInFZ4Eh621ALlWZDlsNtLdVhRVq3yHMn7FSxKMkpyhPjDBAnLuwTRQ= 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 Tue, Jun 24, 2025 at 5:51=E2=80=AFAM Christian Brauner wrote: > > On Thu, May 15, 2025 at 06:23:14PM +0000, Pasha Tatashin wrote: > > Introduce the user-space interface for the Live Update Orchestrator > > via ioctl commands, enabling external control over the live update > > process and management of preserved resources. > > > > Create a misc character device at /dev/liveupdate. Access > > to this device requires the CAP_SYS_ADMIN capability. > > > > A new UAPI header, , defines the necessary > > structures. The magic number is registered in > > Documentation/userspace-api/ioctl/ioctl-number.rst. > > > > Signed-off-by: Pasha Tatashin > > --- > > .../userspace-api/ioctl/ioctl-number.rst | 1 + > > drivers/misc/liveupdate/Makefile | 1 + > > drivers/misc/liveupdate/luo_ioctl.c | 199 ++++++++++++ > > include/linux/liveupdate.h | 34 +- > > include/uapi/linux/liveupdate.h | 300 ++++++++++++++++++ > > 5 files changed, 502 insertions(+), 33 deletions(-) > > create mode 100644 drivers/misc/liveupdate/luo_ioctl.c > > create mode 100644 include/uapi/linux/liveupdate.h > > > > diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Docum= entation/userspace-api/ioctl/ioctl-number.rst > > index 7a1409ecc238..279c124048f2 100644 > > --- a/Documentation/userspace-api/ioctl/ioctl-number.rst > > +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst > > @@ -375,6 +375,7 @@ Code Seq# Include File = Comments > > 0xB8 01-02 uapi/misc/mrvl_cn10k_dpi.h M= arvell CN10K DPI driver > > 0xB8 all uapi/linux/mshv.h M= icrosoft Hyper-V /dev/mshv driver > > <= mailto:linux-hyperv@vger.kernel.org> > > +0xBA all uapi/linux/liveupdate.h <= mailto:Pasha Tatashin > > 0xC0 00-0F linux/usb/iowarrior.h > > 0xCA 00-0F uapi/misc/cxl.h D= ead since 6.15 > > 0xCA 10-2F uapi/misc/ocxl.h > > diff --git a/drivers/misc/liveupdate/Makefile b/drivers/misc/liveupdate= /Makefile > > index b4cdd162574f..7a0cd08919c9 100644 > > --- a/drivers/misc/liveupdate/Makefile > > +++ b/drivers/misc/liveupdate/Makefile > > @@ -1,4 +1,5 @@ > > # SPDX-License-Identifier: GPL-2.0 > > +obj-y +=3D luo_ioctl.o > > obj-y +=3D luo_core.o > > obj-y +=3D luo_files.o > > obj-y +=3D luo_subsystems.o > > diff --git a/drivers/misc/liveupdate/luo_ioctl.c b/drivers/misc/liveupd= ate/luo_ioctl.c > > new file mode 100644 > > index 000000000000..76c687ff650b > > --- /dev/null > > +++ b/drivers/misc/liveupdate/luo_ioctl.c > > @@ -0,0 +1,199 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > + > > +/* > > + * Copyright (c) 2025, Google LLC. > > + * Pasha Tatashin > > + */ > > + > > +/** > > + * DOC: LUO ioctl Interface > > + * > > + * The IOCTL user-space control interface for the LUO subsystem. > > + * It registers a misc character device, typically found at ``/dev/liv= eupdate``, > > + * which allows privileged userspace applications (requiring %CAP_SYS_= ADMIN) to > > + * manage and monitor the LUO state machine and associated resources l= ike > > + * preservable file descriptors. > > + */ > > + > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include "luo_internal.h" > > + > > +static int luo_ioctl_fd_preserve(struct liveupdate_fd *luo_fd) > > +{ > > + struct file *file; > > + int ret; > > + > > + file =3D fget(luo_fd->fd); > > + if (!file) { > > + pr_err("Bad file descriptor\n"); > > + return -EBADF; > > + } > > + > > + ret =3D luo_register_file(&luo_fd->token, file); > > + if (ret) > > + fput(file); > > + > > + return ret; > > +} > > + > > +static int luo_ioctl_fd_unpreserve(u64 token) > > +{ > > + return luo_unregister_file(token); > > +} > > + > > +static int luo_ioctl_fd_restore(struct liveupdate_fd *luo_fd) > > +{ > > + struct file *file; > > + int ret; > > + int fd; > > + > > + fd =3D get_unused_fd_flags(O_CLOEXEC); > > + if (fd < 0) { > > + pr_err("Failed to allocate new fd: %d\n", fd); > > + return fd; > > + } > > + > > + ret =3D luo_retrieve_file(luo_fd->token, &file); > > + if (ret < 0) { > > + put_unused_fd(fd); > > + > > + return ret; > > + } > > + > > + fd_install(fd, file); > > + luo_fd->fd =3D fd; > > + > > + return 0; > > +} > > + > > +static int luo_open(struct inode *inodep, struct file *filep) > > +{ > > + if (!capable(CAP_SYS_ADMIN)) > > + return -EACCES; > > + > > + if (filep->f_flags & O_EXCL) > > + return -EINVAL; > > + > > + return 0; > > +} > > + > > +static long luo_ioctl(struct file *filep, unsigned int cmd, unsigned l= ong arg) > > +{ > > + void __user *argp =3D (void __user *)arg; > > + struct liveupdate_fd luo_fd; > > + enum liveupdate_state state; > > + int ret =3D 0; > > + u64 token; > > + > > + if (_IOC_TYPE(cmd) !=3D LIVEUPDATE_IOCTL_TYPE) > > + return -ENOTTY; > > + > > + switch (cmd) { > > + case LIVEUPDATE_IOCTL_GET_STATE: > > + state =3D READ_ONCE(luo_state); > > + if (copy_to_user(argp, &state, sizeof(luo_state))) > > + ret =3D -EFAULT; > > + break; > > + > > + case LIVEUPDATE_IOCTL_EVENT_PREPARE: > > + ret =3D luo_prepare(); > > + break; > > + > > + case LIVEUPDATE_IOCTL_EVENT_FREEZE: > > + ret =3D luo_freeze(); > > + break; > > + > > + case LIVEUPDATE_IOCTL_EVENT_FINISH: > > + ret =3D luo_finish(); > > + break; > > + > > + case LIVEUPDATE_IOCTL_EVENT_CANCEL: > > + ret =3D luo_cancel(); > > + break; > > + > > + case LIVEUPDATE_IOCTL_FD_PRESERVE: > > + if (copy_from_user(&luo_fd, argp, sizeof(luo_fd))) { > > + ret =3D -EFAULT; > > + break; > > + } > > + > > + ret =3D luo_ioctl_fd_preserve(&luo_fd); > > + if (!ret && copy_to_user(argp, &luo_fd, sizeof(luo_fd))) > > + ret =3D -EFAULT; > > + break; > > + > > + case LIVEUPDATE_IOCTL_FD_UNPRESERVE: > > + if (copy_from_user(&token, argp, sizeof(u64))) { > > + ret =3D -EFAULT; > > + break; > > + } > > + > > + ret =3D luo_ioctl_fd_unpreserve(token); > > + break; > > + > > + case LIVEUPDATE_IOCTL_FD_RESTORE: > > + if (copy_from_user(&luo_fd, argp, sizeof(luo_fd))) { > > + ret =3D -EFAULT; > > + break; > > + } > > + > > + ret =3D luo_ioctl_fd_restore(&luo_fd); > > + if (!ret && copy_to_user(argp, &luo_fd, sizeof(luo_fd))) > > + ret =3D -EFAULT; > > + break; > > + > > + default: > > + pr_warn("ioctl: unknown command nr: 0x%x\n", _IOC_NR(cmd)= ); > > + ret =3D -ENOTTY; > > + break; > > + } > > + > > + return ret; > > +} > > + > > +static const struct file_operations fops =3D { > > + .owner =3D THIS_MODULE, > > + .open =3D luo_open, > > + .unlocked_ioctl =3D luo_ioctl, > > +}; > > + > > +static struct miscdevice liveupdate_miscdev =3D { > > + .minor =3D MISC_DYNAMIC_MINOR, > > + .name =3D "liveupdate", > > + .fops =3D &fops, > > +}; > > I'm not sure why people are so in love with character device based apis. > It's terrible. It glues everything to devtmpfs which isn't namespacable > in any way. It's terrible to delegate and extremely restrictive in terms > of extensiblity if you need additional device entries (aka the loop > driver folly). > > One stupid question: I probably have asked this before and just swapped > out that I a) asked this already and b) received an explanation. But why > isn't this a singleton simple in-memory filesystem with a flat > hierarchy? Hi Christian, Thank you for the detailed feedback and for raising this important design question. I appreciate the points you've made about the benefits of a filesystem-based API. I have thought thoroughly about this and explored various alternatives before settling on the ioctl-based interface. This design isn't a sudden decision but is based on ongoing conversations that have been happening for over two years at LPC, as well as incorporating direct feedback I received on LUOv1 at LSF/MM. The choice for an ioctl-based character device was ultimately driven by the specific lifecycle and dependency management requirements of the live update process. While a filesystem API offers great advantages in visibility and hierarchy, filesystems are not typically designed to be state machines with the complex lifecycle, dependency, and ownership tracking that LUO needs to manage. Let me elaborate on the key aspects that led to the current design: 1. session based lifecycle management: The preservation of an FD is tied to the open instance of /dev/liveupdate. If a userspace agent opens /dev/liveupdate, registers several FDs for preservation, and then crashes or exits before the prepare phase is triggered, all FDs it registered are automatically unregistered. This "session-scoped" behavior is crucial to prevent leaking preserved resources into the next kernel if the controlling process fails. This is naturally handled by the open() and release() file operations on a character device. It's not immediately obvious how a similar automatic, session-based cleanup would be implemented with a singleton filesystem. 2. state machine: LUO is fundamentally a state machine (NORMAL -> PREPARED -> FROZEN -> UPDATED -> NORMAL). As part of this, it provides a crucial guarantee: any resource that was successfully preserved but not explicitly reclaimed by userspace in the new kernel by the time the FINISH event is triggered will be automatically cleaned up and its memory released. This prevents leaks of unreclaimed resources and is managed by the orchestrator, which is a concept that doesn't map cleanly onto standard VFS semantics. 3. dependency tracking: Unlike normal files, preserved resources for live update have strong, often complex interdependencies. For example, a kvmfd might depend on a guestmemfd; an iommufd can depend on vfiofd, eventfd, memfd, and kvmfd. LUO's current design provides explicit callback points (prepare, freeze) where these dependencies can be validated and tracked by the participating subsystems. If a dependency is not met when we are about to freeze, we can fail the entire operation and return an error to userspace. The cancel callback further allows this complex dependency graph to be unwound safely. A filesystem interface based on linkat() or unlink() doesn't inherently provide these critical, ordered points for dependency verification and rollback. While I agree that a filesystem offers superior introspection and integration with standard tools, building this complex, stateful orchestration logic on top of VFS seemed to be forcing a square peg into a round hole. The ioctl interface, while more opaque, provides a direct and explicit way to command the state machine and manage these complex lifecycle and dependency rules. Thanks, Pasha