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 F20C7C83F27 for ; Wed, 16 Jul 2025 12:47:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 91FF78D0002; Wed, 16 Jul 2025 08:47:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8CF8E8D0001; Wed, 16 Jul 2025 08:47:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 797AE8D0002; Wed, 16 Jul 2025 08:47:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 63C388D0001 for ; Wed, 16 Jul 2025 08:47:14 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EC4A858BA4 for ; Wed, 16 Jul 2025 12:47:13 +0000 (UTC) X-FDA: 83670103146.27.C0FC2A3 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf12.hostedemail.com (Postfix) with ESMTP id 0CCFE40004 for ; Wed, 16 Jul 2025 12:47:11 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=hBXk9ORg; dkim=pass header.d=linutronix.de header.s=2020e header.b=4wpPEXIQ; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf12.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752670032; 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=WqfXUKy/vI83eF5nnnMHFFlDFX1raXpxewjeTec5Ggo=; b=RapzRDC7QXxIjx9Zt4a2pMS6XqzYLphvAfdobkAicf6l0LXumObz+UDDE9RgKxBUQyF7ic +1JmXrdbBOg6uAaRta1EE1GmKr35DDiKihCAtkOcX9pEP68KC/09w6gZyI6d6ae3RMFOGB uLHA9H8gfTPUbN2KoWmhaVjjodUbD+s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752670032; a=rsa-sha256; cv=none; b=k1SkLBVDqjSTEao4+ZlYYgNhRYbFkNViYgcQS3V3pM0PMQie/RM2RLQGSh6cDOsUqUuiXE NwruO/gZhmeHjB1Z7TDo10ycdBwpwuyb3wIVl2Pqm/4czDWPnb4rlyrneanW808b+zgO5/ xX4goVTsR8NHK2q3JTXeK19Lbdms0Ks= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=hBXk9ORg; dkim=pass header.d=linutronix.de header.s=2020e header.b=4wpPEXIQ; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf12.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de Date: Wed, 16 Jul 2025 14:47:08 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1752670029; h=from:from: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; bh=WqfXUKy/vI83eF5nnnMHFFlDFX1raXpxewjeTec5Ggo=; b=hBXk9ORgvip2fx1qyGcConFE63IkenS1aAXA6eJ6doGYW++1cU3VJSc0JzMFQj7LTWshqk Vhquw/noFUdu6pxfO7FPkb5czREFUp0MBUrDfqR2d/vluvtY/G7lH7+KuWqB03OpaoInRs L/B+kjzkNt5CHR2QoZ60Jv17oeMK2neWMSYK44dxthcG145eSDybmwFox21j5NxnRa1NoU aj/eQABZqwK7WtQUr2WWbAkRUgLkoz85F5O/djCoFSMPAXMX9ikBKZ+UrxTA9IqPVVYS0e 9OdqKFV4RnZ+d17O6Yo7bXW/9aIDUrlbpV7vxhihos6ZoopawP8NFRbaiDMkhA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1752670029; h=from:from: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; bh=WqfXUKy/vI83eF5nnnMHFFlDFX1raXpxewjeTec5Ggo=; b=4wpPEXIQztKghYoI9EjheWn47o+FrWS3vgZvNaE5ZQ8pjZYorhP73E+pv8wj4oRarkW1Xu 6Hu3/+yQbFNOXoDw== From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: Christoph Hellwig Cc: Al Viro , Luis Chamberlain , Kees Cook , Christian Brauner , Jan Kara , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 06/15] fs,fork,exit: export symbols necessary for KUnit UAPI support Message-ID: <20250716143500-d42ea724-1bac-476e-80b8-1e033625392a@linutronix.de> References: <20250626-kunit-kselftests-v4-6-48760534fef5@linutronix.de> <20250711123215-12326d5f-928c-40cd-8553-478859d9ed18@linutronix.de> <20250711154423.GW1880847@ZenIV> <20250714073704-ad146959-da12-4451-be01-819aba61c917@linutronix.de> <20250716072228-2dc39361-80b4-4603-8c20-4670a41e06ec@linutronix.de> <20250716101207-c4201cef-abbe-481d-bca5-c2b27f324506@linutronix.de> <20250716132337-ee01c8f1-0942-4d45-a906-67d4884a765e@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: 6ejkdw15gjgtqcsfh46r8utqp6zzw49w X-Rspamd-Queue-Id: 0CCFE40004 X-Rspamd-Server: rspam10 X-Rspam-User: X-HE-Tag: 1752670031-224186 X-HE-Meta: U2FsdGVkX1/S0QLC6nHXURORcXbNqZobimhxfUu/69xa9PuFRT6xXHByXRAkn5QZdKQYeeEXvhvAa6QX7GQqdxWmJgrr78FqQYQlJnxgtNXvSHo9jN1+2cIQ9pC5t1l0gHK6Z7FVwZJGAiWb/9/Vjdi4Uxc2Edp6sth62/yq5U3FH2hB3Ve6O/syaquBijtW2Msrjjcq4VPelqlJppZUaExAixdtHJJNmL5fz7jiNrmOrtU8jJena0uJ4j6dEMK6aLCYRuvFqsORGtwEvuk6LT04HNkyChM8XaI9ecyTPQGLuKnhq09sOrB9Cb+EVAFt0O/NHbYEIAiDirZg9/XAdadjvI16eVDvEGJIrg45NrZKW0zooO2jO5IE911dwNmyL8DbDZBMVvfXeh3D1HzQ0uLCqb7WTcyx23kX7lbEwK8yQTIvoMMtCh5qLE0zCqY5gfihyMGTpYcVrD0jifNaTOiUHjCujEuPMoPLVQ0/jrb3ZK2+xKx4E3u7VCmswf+8ECMscOdhzG5PUJPJTgswjXBvXlrRR5hn509NAVR9QAGoA3rxo7cPARja7DU8lA+IqwbeLW0rQcF1eufJ5NCekw4Ohl+ChDZyBInBOrT1XyCRTr67kbh99/nALhxj9eW96qtuLwYaNG0w0KC1Ux5B7z45Vkxp5GIifSyYiyeB4hzE6+LdR/yIIP8AHQCAdOZfr0/hUeGrHLlHUlJpGixqrm21IYYzxUcttxPTVqWCw/Go30J5O9gGYL44h5X7w0TFF1g9Osp0Tged3rLXFNt7m/khUsBTlka1L41+Q+g8O/pLcWrgObyGwNwaGZ8xIklwX6KVVFUzIDcH2U5IsmPkAnyeBr9lHds590twgFbIC9ObrdDT7ftch7fqhZBiDNGK+PCeAMqsw4vmzsEUEURXJqmem9dDCXBofM5rWpWSKdXtbDTdo3dmw94PYUOggi5tNRiU0WDtEATR6c4KaFp 1+RwVpB4 IBfvd0z3HjbOBaL2jL2UsuTtTP682pK0tpYgfI0g3/+lifnoz+aijtWmpTu6tkRTaVhNchnWrHuWAIfdcxZJot5Nvy2r6KYq0argZls4azlCW6Tqb/47dkytgf0yx5bwTZC1TGkZMrSW7VySqGurMhMkTDw9aewv6/R9zyPeHBVneVA8jjYx8wbxVzK+1H+3kzuRoSYNVlrTjPI01jGGl5KwjTrF1xaK+G+SaJaOmIlU8HaAbuypwQON2vVjpeITL9bJkiiucHOKyurGm1AGOjPBwdKLcxQrEn2FBOhtrIgptxyppbXo5mDxboCewAicZAWbSPn65yjx/48OVtO9663Rjy82GXHm28bj7xQ9utznyqM3jJ3gbJUGG+X/4DAuPDTv2NDXOnO6fxe7Ji+jxti5E/WL870AAHnWR3axFNbMGVUznUbxOtnMqDmMJ4XhSBC3wnic8rrDyl3B8LcF24fy/t7L2huw9o1C4 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, Jul 16, 2025 at 04:36:38AM -0700, Christoph Hellwig wrote: > On Wed, Jul 16, 2025 at 01:33:05PM +0200, Thomas Weißschuh wrote: > > On Wed, Jul 16, 2025 at 04:11:04AM -0700, Christoph Hellwig wrote: > > > On Wed, Jul 16, 2025 at 10:39:57AM +0200, Thomas Weißschuh wrote: > > > > Let's take kernel_execve() as example, there is no way around using this > > > > function in one way or another. It only has two existing callers. > > > > init/main.c: It is completely unsuitable for this usecase. > > > > kernel/umh.c: It is also what Al suggested and I am all for it. > > > > Unfortunately it is missing features. Citation from my response to Al: > > > > > > But why does the code that calls it need to be modular? I get why > > > the actual test cases should be modular, but the core test runner is > > > small and needs a lot of kernel internals. Just require it to be > > > built-in and all this mess goes away. > > > > KUnit UAPI calls into KUnit proper which itself is modular. > > As such it needs to be modular, too. > > Not if you depend on KUNIT=y. This is exactly what I did in the beginning. Then I got told about the distros using KUNIT=m [0] and decided that it does make sense to support. We'd have this discussion sooner or later. But I'm still not sure what difference an in-tree-module-specific export should make. > > > That being said some of this stuff, like get_fs_type / put_filesystem > > > or replace_fd seem like the wrong level of abstractions for something > > > running tests anyway. > > > > This was modelled after usermode helper and usermode driver. > > To me it makes sense, and I don't see an obvious way to get rid of these. > > > > Or do you mean to introduce a new in-core helper to abstract this away? > > Then everybody would need to pay the cost for this helper even if it is only > > used from some modular code. > > I have no idea what you are doing as you only Cc'ed the exports patch > but not the actual work to the mailing lists, so I have no way of > helping you with the actual code. I can just tell you my gut feeling > based on the symbols, and they are something that doesn't feel outside > of very core code. The actual code using these exports [1] was Cc'ed to both linux-fsdevel and linux-mm. In addition to the cover-letter and the exports patch. The rest of the series does not interact with the exports at all. [0] https://lore.kernel.org/all/CABVgOSmdcOZ0+-k=SM4LibOVMKtcbF27p6N40kuDX_axTPZ=QQ@mail.gmail.com/ [1] https://lore.kernel.org/lkml/20250626-kunit-kselftests-v4-12-48760534fef5@linutronix.de/ Thomas