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 D6FFFC7115C for ; Wed, 25 Jun 2025 16:13:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7A5D26B00C5; Wed, 25 Jun 2025 12:13:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 77D9E6B00CB; Wed, 25 Jun 2025 12:13:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66CED6B00CD; Wed, 25 Jun 2025 12:13:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 512FE6B00C5 for ; Wed, 25 Jun 2025 12:13:21 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E6B99121801 for ; Wed, 25 Jun 2025 16:13:20 +0000 (UTC) X-FDA: 83594417760.12.D45FF03 Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf13.hostedemail.com (Postfix) with ESMTP id EDE6920007 for ; Wed, 25 Jun 2025 16:13:18 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Hkmn7lEQ; spf=pass (imf13.hostedemail.com: domain of dmatlack@google.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=dmatlack@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1750867999; 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=NWTU9KjLztibLwJOI0I2c5PwZ/pOAGxqqconYH3Cu6w=; b=pxjX309DB1Sv7mhntAnWUC2vGWKumeVM6dy0BnU2ja0cjQyaNYH7oiLOdkdPd40DfX+98Z kuv5s2helzwLPxC57rfiv290Hqu6QGNULSINthvsSgTIYPYGzcZOr/lTp8UfXtQS15YMWP lFWqbknCbIbFXtExKmvjWAv8tcAOLQg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1750867999; a=rsa-sha256; cv=none; b=ltXxwW96I5XPHFao2pSSYMKkpeQ54GJWxQ62xVmkAqqrqN0lLkDaqYrfK15AxA2Nzkc5zS cgbfs+phiG+F9fKzCsUlxix1lQqIjAl2mfQiZ9qCjTJJF6CJQplv9FZeQTdjHryz3uRUgt 6L7KhYrVvndzq5ITv8wozNY7wJ/kqb0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Hkmn7lEQ; spf=pass (imf13.hostedemail.com: domain of dmatlack@google.com designates 209.85.167.49 as permitted sender) smtp.mailfrom=dmatlack@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-553b51f5218so47838e87.0 for ; Wed, 25 Jun 2025 09:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1750867997; x=1751472797; 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=NWTU9KjLztibLwJOI0I2c5PwZ/pOAGxqqconYH3Cu6w=; b=Hkmn7lEQZ7VX1mowvGjqfYmeBr70+Xaw02xSFGLlEQT5KNbV62NM9mI9idQ27Rmzsy sRNVlXE+gCQa8noAoPx3h894qAn0Jjo0BZwNiVnkiiCluRKJNKsM8QpLebncV0l8aQBT zRbGSwSExWdmmTG0TcgtDXT2qJlB7T1DZqzu51bKIJF89ohOdYOtZzAYYC1prubmPIfL MJxssHE3BtkmbqnGYw0nz3GRdvDiniSpBA3/BbES49QTDT2whr1RaXDqkxFCSdp2z7gI fP7z7p4uo1MD1rJWsw9jLX1G6jbWiDvaqtw4DSBkgg9iBCas0CVxonU5YUlPtNxuWwjC gb6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750867997; x=1751472797; 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=NWTU9KjLztibLwJOI0I2c5PwZ/pOAGxqqconYH3Cu6w=; b=GQB/B7I/KsfaJbuBC0P1+lwwqNfG5MSVE4KfSCjdinXTzO6Aaa36E+uCquwY604nLj Uaa1QJkxNgbDgMIAdwGEsTJ0Gpp256+iTkWzip0c0T3WxRulLWp/XnTaWYixkH6/z3KD GMPQ+fv3S8sv+OxfWcze06CTebdafzXHF2688Xa2zJdbArVHwu8XMxQVrdfLdP/0/eIl EQQ990U2RKQE4U0vjIvKBnsULBg2t/ZfDtdVtOj10QtI97vUnX/G+UTTy76edy4sAIlq Qvtp04EBk+WPlv9HpndFZvjTp/+/6er6+72vwF+95DWO42kvxPT34FjMcXXIELhOU2Ho F6YQ== X-Forwarded-Encrypted: i=1; AJvYcCV5yX7Sc8WwMZAxlF1uFo30Vng6IUYPthf0Etk/rIaRWNPMWqAWFjY+EdI7EZzIyz0UNB4dRhyrsA==@kvack.org X-Gm-Message-State: AOJu0YzSe+KWh8eafTeGC/lRH6bigEnNvOIDerwt4rCMgdHVfouBjyPV k5b1bdbRAdB4J0Wv3jx4TgBlCv3sOeDsbtGbHFv7iVeblNmA6A5FCuKB5g5v38Nbs0w6IwKT6Fz mM5/IwFZUdgGwv4GcrKlE8NYKuIxwn0805ipepgRh X-Gm-Gg: ASbGncuch3AmRm7Ri96XCtlfAv5Ls1pcfjm6INOH6DdYnsjFB6BviDXU1HISiDm6ghM QbfIaaFS8fOxR6kzVAAQTPDl7y5drl+TZa2euMR3ym7i8WORk2Z0cWFn3c5o/UOA9tAU5dlW6z9 4gSZwAwok+MsUDTkVW1/aoqnA5YOBJmUnZzmliyNBvLqY= X-Google-Smtp-Source: AGHT+IEmyNKuINV9suiw750iH+/qWaKx6g6apKTMylHrEHA2ab9ubUUotR8hKdCWlG9C6/ymBT3mjUvzDbJ2PDC7/J0= X-Received: by 2002:a05:6512:132a:b0:553:ac33:ff24 with SMTP id 2adb3069b0e04-554fdfbcef6mr1162599e87.55.1750867996478; Wed, 25 Jun 2025 09:13:16 -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> <20250625-akrobatisch-libellen-352997eb08ef@brauner> In-Reply-To: <20250625-akrobatisch-libellen-352997eb08ef@brauner> From: David Matlack Date: Wed, 25 Jun 2025 09:12:48 -0700 X-Gm-Features: Ac12FXzsaTglwRDvyxmqrDF18P44C8borysbshJSxnL6KDEw4fT_csftD9wd1t8 Message-ID: Subject: Re: [RFC v2 10/16] luo: luo_ioctl: add ioctl interface To: Christian Brauner Cc: Pasha Tatashin , pratyush@kernel.org, jasonmiu@google.com, graf@amazon.com, changyuanl@google.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, 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-Queue-Id: EDE6920007 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: 17iqr6c5ttdrkxzbheajbgs7zcjaey4a X-HE-Tag: 1750867998-61872 X-HE-Meta: U2FsdGVkX1/ZmRpDP7J77gESTHZfyGccpGD/QEedI8SPlFQZVlpR3cwwfNOfaxNcjaImd9qpMM2EqldCE8vkZdlcAmhs2ebQ7ruBP9T4Vam/uUqcnyngZUT2QtnCs64YXK0S00gWpDKu6y3XeMXN6wNvGX90+7LyAeQG9vT2MFoDCDnndi2zhyzuvyGhiA1zHUu/hYhnhUIZVXropd+D9Q/f9S4E07JCcQccWL0+g1AlPqbPclCPVxnOwvBwaGTOIs1vbf4uzCsgeMzCs2yQCtA93HNw9lB6gzu6wIpUMuloKi8HQOtu6sOepfJhXl/NjP6sReuWQw2HOnVMXxPrZFI6NEEcZYr7LR5LfWvzEKdkZtrMD+DV11zy+9BhPpAxnb8DihE3IfcqZtxu5PB/jtvZGzOhi5oMePYPzHHG0Py1EFaUC3YPnrMMJW98aBJsxyv1ZIyWbZ1m2q0lN1gnNW8Vf3Kq6SGQSRLLwozlFJYx082944sHiSbCXk7MJBSVTWJ/F1KAga6/4ZEai48ZF2NCfoM5d6NM7SQOypWGMBmlot0dx8dxXnuWyWo1Ktz1Z+OwjEpLEdoR2LK0aat+6Zbxba4NuY1UdcBWPlTSPz8q6AFgz2RaBWZ3iSqA9gYbyIzg5eSkTUSinjft9VRaQQM70DvHG5S2knawxObfMqr0DAHFG3olZm2DP5kdLaj6o8KSLAdoluFrIBiRn5HXMCkOrgUlFEp8A9dC0I7wO5OT5imTXNbCKWo+TNaVlWOzBmsIKwrTy4MQEzLXg4OQ/ZXj5Fl4PF4cHUNXr4NRAYvGvU9wf/A8micv/73jtIrPE8AkDVaZMjP84FVNQddXHqTjwR/lIOH1oS53ehqE5iQO8S/bfS7ip56uTqA+Qgv24gxQt05FPvuy36w2maeX5UBHremOZYySh2nhkiJ1UrKQQI9OP4SBX1ntYFrY1UcvsYFuiSUo9zhEycrpNs/ B5eOv2Wh p6bu7vkdFdYi+7uuyew5LbLObUlP/KWhOSUVnwdmJ1FYE1FVwG/M8urFFCl+/LrAzv7Jo4kh+4D28qn3e3ueo3RzSnn4MkSGSY5tjfFVn0NgC6IEZYOckyBEh9xTVqcfccqWvb4UI0AJMnxASfACuQpMyDbyuemu/EnPl5Dy8All7W7trWmtVQaOyRn37U4RTFS5mJ233uUEpFsKNsxOPvyLXzdV0k4MYjZjMs8DU+oWXE7qo5wBme+tdobTGSrcz/VIf0R010jTze0HTYfnpY243vTPvpiL07CxKIDRnXcIOz2Q= 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 Wed, Jun 25, 2025 at 2:36=E2=80=AFAM Christian Brauner wrote: > > > > 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. > > I'm not going to argue that you have to switch to this kexecfs idea > but... > > You're using a character device that's tied to devmptfs. In other words, > you're already using a filesystem interface. Literally the whole code > here is built on top of filesystem APIs. So this argument is just very > wrong imho. If you can built it on top of a character device using VFS > interfaces you can do it as a minimal filesystem. > > You're free to define the filesystem interface any way you like it. We > have a ton of examples there. All your ioctls would just be tied to the > fileystem instance instead of the /dev/somethingsomething character > device. The state machine could just be implemented the same way. > > One of my points is that with an fs interface you can have easy state > seralization on a per-service level. IOW, you have a bunch of virtual > machines running as services or some networking services or whatever. > You could just bind-mount an instance of kexecfs into the service and > the service can persist state into the instance and easily recover it > after kexec. This approach sounds worth exploring more. It would avoid the need for a centralized daemon to mediate the preservation and restoration of all file descriptors. I'm not sure that we can get rid of the machine-wide state machine though, as there is some kernel state that will necessarily cross these kexecfs domains (e.g. IOMMU driver state). So we still might need /dev/liveupdate for that.