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 B7784C83F27 for ; Wed, 16 Jul 2025 08:40:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41AD26B009E; Wed, 16 Jul 2025 04:40:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CB306B009F; Wed, 16 Jul 2025 04:40:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BA4E6B00A0; Wed, 16 Jul 2025 04:40:04 -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 189B26B009E for ; Wed, 16 Jul 2025 04:40:04 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A1B90802BC for ; Wed, 16 Jul 2025 08:40:03 +0000 (UTC) X-FDA: 83669480286.12.3A0F595 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf27.hostedemail.com (Postfix) with ESMTP id BD39940009 for ; Wed, 16 Jul 2025 08:40:01 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=v8Oyz9kS; dkim=pass header.d=linutronix.de header.s=2020e header.b=THfnqitT; spf=pass (imf27.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752655202; 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=Jco++hyHdbIu/TIuhMr6dAmZZnmYOnbilSFqBhBBsns=; b=likEvMMkF9CV48Okcv/wv7n+jqxjmk9D6Xmwk9RGmIAYojLMrmT1Y47HLh4onjmy8olGcy hVc5xmEbaNkaUXCJJSgFV6ODyCC4Gl64vtJLAWjWq/KlLgSgD+2USbNwPA2zz2WqCQqoEq t0xkSYujdiIzygUMdqucEoS1ld++HvY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752655202; a=rsa-sha256; cv=none; b=cEWOoGOIoBfLuxzc27/xa2GHYn8AuXPlPV0wL93vdqd7osBDtQkh+TMu+zmWgM+ya8RzU5 8ObY9VNjm+8nrRcdsfyAOonFnrbzBy2tRQqd4G5dhUuo3VJTdl7AMruLibAoDcf38rAvQW GGk0YqENaHmpLnVfkTF3lwATBRUha6M= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=v8Oyz9kS; dkim=pass header.d=linutronix.de header.s=2020e header.b=THfnqitT; spf=pass (imf27.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de Date: Wed, 16 Jul 2025 10:39:57 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1752655199; 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=Jco++hyHdbIu/TIuhMr6dAmZZnmYOnbilSFqBhBBsns=; b=v8Oyz9kSetVsZIud2t2NkpwliXNDmacL2MFfhuIIH3hGinp7yzfp1Hw+fr7/7MAXCokFj9 /Ax2U+RlgDybB8RRArY6d1XojZ1xLOv76OzVgyJ174UhVkwIdZ8WOBQdJb/wQQ3FcccTIo L7L958b7z3cRBjtCzeJk623ucRPFSuyV0jovt73+X//iHc8ZPazTmz3AIx45tTnb3u7Erv r/DtCuoMuwzM+v088CgyJbuHmK/D+TdsNcZelp+HakFeXdUOU3fp/cKDO7bELFTFLQgWfE sMefrLfrerN11Y2tLJXoJ4NGlfeGC6O3qogUchsQnf4zLuc529Bp+0C0aDb++Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1752655199; 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=Jco++hyHdbIu/TIuhMr6dAmZZnmYOnbilSFqBhBBsns=; b=THfnqitTCj9NZEIu4dy792cKr0Pful9b/CaZpduRD0Rntz3+Vk6lY8Z91YA+H39PfC8uH5 cVk+8gu02gc67YCg== 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: <20250716101207-c4201cef-abbe-481d-bca5-c2b27f324506@linutronix.de> References: <20250626-kunit-kselftests-v4-0-48760534fef5@linutronix.de> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: BD39940009 X-Stat-Signature: iwghqwwz7rf4tzhi3gjfsysnmwx7hghm X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1752655201-784792 X-HE-Meta: U2FsdGVkX18VyIwLu14v6S9os5+fcbdFltu47Do9fwS2+lPUTCqfMEnZKbvKsJ58dMdCB5Qh+q6N3DVOXNBgI4+N0PIYEgSIYSRWbWg3d8xznChDzDNt1J5WpQAv2xlpQsWkRUhEmBscD32c26H6FZ1F1nH8GXfcOe1skbBS7k+larUwhUS0rc3Y4ywS6rxvzjHxg0OsdSu98Vg7GTljF70yztPVyLgj9vw89GfTr7GWHdjvptnzdE+poosI9EmA0k88KmaI6zpNJ8I6HC8rveLzc+qHnkESP2BN+jM8TyaXU5+jZKVPxSomQLcR7DCkn5nWzNK/cUcj6fMmse/w8h3P1cevEy4eo8YSlXO+LFJYQD43jI19jP4peP5xYjyZlOsbAe/GyGICng6pPUtovq90o/MtmRqxYUZ8jb8Uszdl9XV6uu/efxHwK2rpSHnp5wLeCt+zfxirb2C+S4D95qBDKE9b656/5phCZYSPM7FVU6qiwVhyz1reqR/o+XQ2XOnAElIxIhnBGWNN/czQH53z485SYqF0rJ5Zrf4MV6DFfp/I0CpLw3PgrfN+lrDJqtQx5u8/UU4RQKfWpzmx0NoFNf0IQ+cfWRDFAj10YfSnwEudOkKXTAr1NOANrJoBTrN/+fL8FQQjefXYrnH9bJNr66gW5//Of7h1KMUzdFgVV1+arF1c1l7tovU0kJ5La9IdI+xG6BzIov+/DTe4mVtHUSDbAtOYUGXEKFRi5214K8rexxmW2Lvrnh778n8BxW6nCz6Saep1/RiEPOJs8VWkSBxaewH4rvwaAKr4p9Cr3oi+e5r5BjHC9JrIVEmWBc2/1/5Sg039sTQrRWSF6+KxiDC4bBjU5TbHvjiWLZq5RH9+K2Jm/lgAfqPVybVG/behOHzLghYbtluhakXz9HmBYvn7uKR+Bvd5gk5irMt9L0zq07r0cgeHsZbsXCnrDWYkVAKIc/vWAEJAIRn BlvAn5Jk sVHXoBphWIwSYcAeHkOSHJw8dl6e7RXAwOW/MCksO/KV9Blbx41Q5sTai3xC99QETvEYqpYggvWA15D8RaKBBC8JDQDcGLjjHkkHbXFtI7lO0AYD8EZs7PBVVvrtUTPNWzRD6XBbVzpllS9LvfcJAMP0ObN1gk9UyEQ6+SN6BnZZ2VvHNSnp4SfZWBkgvZlxvW1dazCExYZhOBBW+OsPB1f4Pz2inxkrz+eu3+8OO5Rmzi1QrId8o7W7ReKclYOyBn10yX33+Bxvg+9x1MP2jvRIyIOlfxa3e0i/HKvRAQMi9jmyLlkgfyvRfZ4SnCXShfd70N/58Rwy3e1FC+v7CETvGWlvV4a8LPiotyTRHBH2txahOs5MFRlT72APof1PAZFA0Drpv4RrAh7R6fvq9CKmg+Xb/RMUhq1/jigp8GgH3zliBhOjTmVv7mA== 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, Jul 15, 2025 at 11:21:43PM -0700, Christoph Hellwig wrote: > On Wed, Jul 16, 2025 at 07:30:46AM +0200, Thomas Weißschuh wrote: > > On Mon, Jul 14, 2025 at 07:52:28AM +0200, Thomas Weißschuh wrote: > > > On Fri, Jul 11, 2025 at 04:44:23PM +0100, Al Viro wrote: > > > > (...) > > > > > > On Fri, Jul 11, 2025 at 12:35:59PM +0200, Thomas Weißschuh wrote: > > > > > could you take a look at these new symbol exports? > > > > > > > > > > +EXPORT_SYMBOL_GPL_FOR_MODULES(put_filesystem, "kunit-uapi"); > > > > > > > > What's that one for??? > > > > > > What are you referring to? > > > > Reading this again you probably asked why put_filesystem() is exported. > > > > As I see it, that should be called after being done with the return value of > > get_fs_type(). Not that it does anything for the always built-in ramfs. > > The alternatives I see are a commented-out variant with an explanation or > > making put_filesystem() into an inline function. > > The right answer is to rework your code to not need all those exports. If I saw a way, I surely would do that and I certainly tried before. For the first revisions of this series I didn't even try to make this code modular to avoid these discussions. > Nothing modular, and especially not something testing only should need > all these low-level bits. 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: > It gets neutered by CONFIG_STATIC_USERMODEHELPER_PATH. That could be worked > around be overriding sub_info->path, but it would be a hack. > It does not allow to implement a custom wait routine to forward the process > output to KUnit as implemented in kunit_uapi_forward_to_printk() [0]. > That may be solved by adding another thread, but that would also be hacky. So I can either hack around the official API of umh.c, or modify it only to cater to "something testing". Then we have put_filesystem(), it is the counterpart to get_fs_type(). But while get_fs_type() is EXPORT_SYMBOL(), put_filesystem() is private. I can leave out the call to put_filesystem(), the result would be the same but it is still a hack. create_pipe_files() and replace_fd() are used together with umh.c. But while the umh.c API is EXPORT_SYMBOL_GPL(), they are not. In general KUnit is already fairly integrated into the core kernel. When built as a module it contains some built-in components and even has its own member in 'struct task_struct'. Having a built-in helper for my framework that wraps the calls to the non-exported symbols into a helper function would work but again be hacky. Or the code becomes non-modular again and suddenly nobody cares anymore... Thomas