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 09D90C83F07 for ; Mon, 7 Jul 2025 12:56:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E41F6B03F7; Mon, 7 Jul 2025 08:56:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BBC16B03F8; Mon, 7 Jul 2025 08:56:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5AAB06B03F9; Mon, 7 Jul 2025 08:56:29 -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 4A99B6B03F7 for ; Mon, 7 Jul 2025 08:56:29 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0C512128896 for ; Mon, 7 Jul 2025 12:56:29 +0000 (UTC) X-FDA: 83637467298.22.F6A38E5 Received: from mail-qv1-f44.google.com (mail-qv1-f44.google.com [209.85.219.44]) by imf11.hostedemail.com (Postfix) with ESMTP id 192AE40005 for ; Mon, 7 Jul 2025 12:56:26 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=TKfov5Q1; spf=pass (imf11.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.219.44 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751892987; 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=Qk23V2JOAJIYWEJqL9VccK1Z/r5nCIAurwcBtCjyYA0=; b=hiZzxk3aXWkp0ITJlqb0UNy0k8icWFa3Y/CvETkUL4tZJQSZ0hwtdtBgG6sqfraG6u1L56 T3y8M1nSW7Z3gXbFeMFqFMOJXR7Ggv5RWMXBCOxjXMItleFuttKhWU4EYuXF6hYjBZ6jdn iQ+hx9/Iz1E/kfFbK+lSUdk1ADA76lg= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=TKfov5Q1; spf=pass (imf11.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.219.44 as permitted sender) smtp.mailfrom=jgg@ziepe.ca; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751892987; a=rsa-sha256; cv=none; b=rZPtx6+bcc5wwC92MOblds1SV2yBpJF0LeJI0RsDn4eZkj2i9ViBOGsaX55RvWXdnA8L1T yOele/91PvJmk4vuwU2ePh7JUhQ0DfMeTBku/OzOPlMHQFxlZkc/zXucWpOMo/hMWr0pGu ehBnCLtWFW91q+Ya2ouYZjXU+AGl4n4= Received: by mail-qv1-f44.google.com with SMTP id 6a1803df08f44-6facba680a1so45142316d6.3 for ; Mon, 07 Jul 2025 05:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1751892986; x=1752497786; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Qk23V2JOAJIYWEJqL9VccK1Z/r5nCIAurwcBtCjyYA0=; b=TKfov5Q16IzvSkAXN+LlYD+ArL6RDOlkL59GOoX8f8m7pKa9oPTwABBxETYTfQhhXR 1SqrRaXePFfilTRGwJxiUnBE5qQ6k8pPtfEHh2eCjHi7CuBz7fyJWyz0ZuK80m+c46GL MfWdWFFSaMBasdjEmwNHfWZQHhaWmZ9TCzXnUQIBbndc4/S2KhGY6ooQiZty4mryPRU7 MyTvfC9KlqMnHSD8BU54oELduqNW2oefV1MGGhiBLjh0Wz9P35ZHFSszR908Zl3OFzxt FQ2gfzeFxeMRaT9ABC72j2ExnYlix3miFi3Wdvw+bePZIim7ED+HQtMe/c/hbPAac4uF Xbaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751892986; x=1752497786; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Qk23V2JOAJIYWEJqL9VccK1Z/r5nCIAurwcBtCjyYA0=; b=jUp3gIYc7aIt8twQk6W6DXxgwRCOe9RaDEXvmAZweh39Z4Va3FIF3dv1Ak+TQUFcdK M4Cfb6oPaYtAkoUNGJRFsIlmsGBLY9VQEj9Mn4LWPeeo3nMoKzSXLnSwYPAcHOd5f7Mp UuQ95mAr8cs4g3ddK84njr9rpgyJWd0Y5rj6tf5w/amonb5vbSDUwdM/ySCyk8mtG6sG lvvWu4NAWnzQBKKLL+B7YmG94bh4H8YWxfHG/hKSIybjUXTG0gytMrybLHZey7+QXMxJ E19XK3Cl2B1gRXkFzo8O4zLBBX6ItA1ILUqA3OIAQRVmqNJidGQCjN6182jiLsd4Z2Pe zqfg== X-Forwarded-Encrypted: i=1; AJvYcCWrU7uYYVuPjc8+Opm2xH/wjRa7Q4aEvQ+mPDjTzVtvwxdHaCF2QMTN+P3VPz7xakUu6jIuEgOOig==@kvack.org X-Gm-Message-State: AOJu0Yyv2CKIw0+kX1OSNh4I5h3J3liHMyaw1cHPNB/o0FklMroH6VYw Chx9ehKsIBbblFYuYlN87JqWPw3rFqy+IlsQQDgbU3VPqHSnjB1lJVdo+uj8UTj1IwI= X-Gm-Gg: ASbGncsONhBG/WGCSlV3GMr57W45/01pr70sGV8KTRWuOqHw6CiW6xg1hitARDUgzWi jppjF9WArMstHVHR2+Y2bEx0XWrUuE1XkxXnfF4ZJwN2UqWHOe+U5l8YwJo+MD3WKIHisAySSTb Lcm1X5q7/CyfsTvfe42JLuJKVYcAWeSaIbZRIYwMCFrbCFpc7fKkBXpIw6Hqd4XUQtP6c930DxA CEhXvu68lWCeDV0Jdg1n/SLE/hDpXWkR12DRWH0Hqf/5W4LurpOEFrVrRdMcL0nTVND5/NuPMPh vnuBL1skn9EgxPgmvXCB//dji81oopc6RrYGowHYtOKljTSQc9660N1czuPxET+G1OSFHTvPKoz kIKdrqx9PEaSzB63xw3P2S3K7QIcN3rKkoJ27oQ== X-Google-Smtp-Source: AGHT+IHpUaaVcJ5DRQCtRGMCJ6nO666Q1wL9WL24RtajZdpjAA2S6AsDZqcLbeUtsD0vEBZQLx+sMA== X-Received: by 2002:a05:6214:2b89:b0:702:d60b:c037 with SMTP id 6a1803df08f44-702d60bd72dmr108206296d6.29.1751892985849; Mon, 07 Jul 2025 05:56:25 -0700 (PDT) Received: from ziepe.ca (hlfxns017vw-142-167-56-70.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.167.56.70]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7d5dbdb4bd6sm598121385a.28.2025.07.07.05.56.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jul 2025 05:56:25 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1uYlOS-00000006LRj-2Hey; Mon, 07 Jul 2025 09:56:24 -0300 Date: Mon, 7 Jul 2025 09:56:24 -0300 From: Jason Gunthorpe To: Mike Rapoport Cc: Pratyush Yadav , David Matlack , Christian Brauner , Pasha Tatashin , jasonmiu@google.com, graf@amazon.com, changyuanl@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 10/16] luo: luo_ioctl: add ioctl interface Message-ID: <20250707125624.GO904431@ziepe.ca> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: z4mumku31oqmit66acj4bxpmprwz7fdh X-Rspamd-Queue-Id: 192AE40005 X-Rspamd-Server: rspam11 X-Rspam-User: X-HE-Tag: 1751892986-92991 X-HE-Meta: U2FsdGVkX1+wn1k4VuUabUsDc5AWRN44S/xUnGwTl2y8AXUHIEAKOhRCIo4pnuBS1wT+FEIW5ynNJnFEyngK/vo6P4c3+X+/IwZdy9888SXls/AVkCcHSl6oHp9n1LkLOU8xvP19RTXx9zAvQGvmUbsYSzhYE2NVTRRuRghYB+k6rFYOQUqmfOfulahyRyiJv7ks/R43Uu0WEpqym3SOZ2Ftt6B8gxP9X/KBGRawN8RvSVaYxwZ1gh18Tikd8/lqiuDPJsnRrEUWsbpp/wgKpCP0gq/zQrR/mwnxanSqrROxnU8ZI7oH5xRd1Ls21exlSNX3YelrbvZfHl95SOrVwcUh0cRH7gfC1wXi+w91Xr94TAAwhxqaUx/4Eiyr1b4g46o3Wh3BMEZuJ/dx6laeHbqYrfXiQ7ZDBOvagkbfiLOTWD9zjy0mWyvIF5bY45aOfcn0U9+oDCWP4IOrbSCv4KgmxPynbaOvwofhyIQvkYD5d00x+N7XSQuxBwB7KIBvzzf/rEiU/YX3mVJ/JtjFn6O2jI79b0P5C3tUUyQphImabUhQWOEM/X+7GmbmX6CRYsqP/8x+Dfz4m8egv9VJGYxD9PgKELxYMqlp7ok8FihL1yqvDm/LvSxGce9qzxEwwdiTJAiVD6hESDf14xw0szdE4d5b4xw9U/aOcFfpGZsA+l91eI+bQQk+gw0Ptu10dmr+jp+me5SuH3VW8BxOqDJP8HMi3JvNWrNYo+gbGKbCAgRaBtKbKs1WaVcUac6UjQEAbpQ0F+OCbHld8GFf7JTSpnQAD/E0WfbOTatQymsNduS57xs3l+i6KQ2n8Ol3o3ssxkZeq45oSD7SrqhhpxLVoyEROTvCLgqi95fUsmRKRR5G6R0E+C1O3dtsq6icyV9QLDFJNcBh43y4tBmJZgLde7B/hPMHYAWLQElOBvFS1ruZJSOa9pFBG9P2ewU2H5nQRZzngsstSsGVfed RzVBX5lb dVDo4oJxO8D7iUuHmyCSEdFbU4uy9wc9e6D5UnmdLRgqLZMtRDBkk94xJbU8HEYav5MdeKGuTO71fvrDD3mmIlYl1SJzseqlV9alW9p1iEkF17pOLW954hjkzOnMIssTlzEVNFz+VDXyL6JaonBTqKAgL+aK+p2J9WPmMYAKSVtIMBNm8bayQNemYsZ4cguGeVsTbsau2AC8T01LxNRmxh2poU33S8AU1wvzHHt1iTGyPFEuesUevyAu57zHn9Pq1S2yBCn+qX2FTCdtGQ4liMGv27ZcjuXjFDa3MP5nABSsatNfCCLluMbGeupTRopKihIjdd8VQ5FMm95QviQ8XKmHf7J/M83Bauookk8G0BbumvFY= 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 Sun, Jul 06, 2025 at 05:33:04PM +0300, Mike Rapoport wrote: > One of the points in Christian's suggestion was that ioctl doesn't have to > be bound to a misc device. Even if we don't use read()/write()/link() etc, > we can have a filesystem that exposes, say, "control" file and that file > has the same liveupdate_ioctl() in its fops as we have now in miscdev. IMHO for this application there is nothing wrong with a misc device. The intention is for a single userspace process to use this as some kind of request broker and provide the required policy layer. Creating a VFS and then running ioctl inside the VFS just seems like over-engineering to me. We can't really avoid the ioctls. This is not really managing files in the sense of string named objects with bytestreams associated with them. I've also heard people saying things like configs were a mistake, so I'm not so sure about this. IIRC VFS brings a bunch of standard use models and their associated races that the kernel is forced to deal with, while the simple ioctl here has none of that complexity. > The cost is indeed a bit of boilerplate code to create the filesystem, but > it would be easier to extend for per-service and containers support. I don't think it really improves that. You still have a single policy agent in userspace that has to control this thing. On the other side you'd have a much more complex serialization job because you have to capture an open ended filesystem instead of the much simpler u64 key/value scheme the ioctl is using. Jason