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 1B535C7EE39 for ; Fri, 27 Jun 2025 08:27:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 99F356B00BD; Fri, 27 Jun 2025 04:27:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 950638D0006; Fri, 27 Jun 2025 04:27:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83E3F6B00BF; Fri, 27 Jun 2025 04:27:44 -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 6A27F6B00BD for ; Fri, 27 Jun 2025 04:27:44 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 18531C05F2 for ; Fri, 27 Jun 2025 08:27:44 +0000 (UTC) X-FDA: 83600502048.16.1D668DC Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf05.hostedemail.com (Postfix) with ESMTP id 28031100002 for ; Fri, 27 Jun 2025 08:27:41 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="2aC/CWCX"; dkim=pass header.d=linutronix.de header.s=2020e header.b=CmuK24lM; spf=pass (imf05.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=1751012862; 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=kwOcZZs1ZIVtoa5esxxBWO/UwD8QHSKhv8lKZGDgSx0=; b=kZAKibSjGJMrMCdD5GH75GOz/4A2ZBvl/VisnZUUDpFbmboAkNCzYOGzeZbkksj4QL2kf0 LhrCdvpdNb00c0MWRrS+serWqo2rSZNLPkH+ztBfnCoHkYVYXOVSMR2V6+pemBRPRNDZzc EVvGyqD0nUjHFekSlVD2EBJypcQmrtk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751012862; a=rsa-sha256; cv=none; b=U3X+2erhLYl3ti4j7ek/1+qEEoYAYmI4O6pK8yI9wpR9G+H48AKyqVWZMq8KJ72tKq3ePh RQiR1tNDTsw6m9yZHO658ZdjpgLgHxxlzIHIXQTNPYmWkgdQpIAODcH/SmQAugobsR1xKO i12UUfTqQXPRhi1dl7LwsSmbUS2sSSA= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="2aC/CWCX"; dkim=pass header.d=linutronix.de header.s=2020e header.b=CmuK24lM; spf=pass (imf05.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: Fri, 27 Jun 2025 10:27:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1751012859; 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=kwOcZZs1ZIVtoa5esxxBWO/UwD8QHSKhv8lKZGDgSx0=; b=2aC/CWCXE3jx9ogAHfeVvi5askDWzS4IIKA+1ZfA5SSTxSLYBQ90m6Dy2nICwxv8qzRoGL rY6faDt9BJM+h83DTYHmU2Hh5lgLpbyej4lAKL3nKPN6lPO4+y6zJDpRWeq6XmAJNwvkhs lGslEcJtbzrxI1LQsXqONZI9p7AOL1ZwoFSh6tfVaanUB1UnrcbnUPincQuvsHUo9RBv01 dwTADTWtGWwrTj2m21XatcwxDmi1F8SIRGrHmBmYpJLoGXdpFTy2m8yJ9XpPikUfOshPNg VZ3uW2mSn2xV8eSUmW9NhS/5YVQmsUXxwrqWyDgJIxA3l6WEGRs3rpHnniX1jQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1751012859; 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=kwOcZZs1ZIVtoa5esxxBWO/UwD8QHSKhv8lKZGDgSx0=; b=CmuK24lMiNHqVe9jMdhvIIcCp3aCMFD6MbSCB8x5brTssfB2wvfSQdz+md2aVmzdnSIPBf zKnT8k9vrlWiU0Ag== From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: Benjamin Berg , Masahiro Yamada Cc: Nathan Chancellor , Andrew Morton , Willy Tarreau , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Brendan Higgins , David Gow , Rae Moar , Shuah Khan , Jonathan Corbet , Nicolas Schier , Christophe Leroy , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com, linux-doc@vger.kernel.org, workflows@vger.kernel.org, Kees Cook , Alexander Viro , Christian Brauner , Jan Kara , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v4 12/15] kunit: Introduce UAPI testing framework Message-ID: <20250627100608-9eff2270-8f5b-49d4-9fe3-54a12a14dd25@linutronix.de> References: <20250626-kunit-kselftests-v4-0-48760534fef5@linutronix.de> <20250626-kunit-kselftests-v4-12-48760534fef5@linutronix.de> <66deaafe1974c989e949975bafe3ab0b2ae3f5ff.camel@sipsolutions.net> <20250627060129-4fe09191-4714-4856-9de5-c8e5cf5ed0d6@linutronix.de> <8cfa715301c7c357c5d6c82fabd9b53d2fa01182.camel@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8cfa715301c7c357c5d6c82fabd9b53d2fa01182.camel@sipsolutions.net> X-Rspam-User: X-Stat-Signature: b319nuzopzrbgcrcs4yk67qgopawzrmb X-Rspamd-Queue-Id: 28031100002 X-Rspamd-Server: rspam08 X-HE-Tag: 1751012861-986956 X-HE-Meta: U2FsdGVkX1/Nf3gcz35yU5Qa1bMDCMo6rXhRKstnhUn1MX6M/FyjABSFFRqZrcWe8avgQMSdukEP8B0y+KmWv3q3y6zxD9zw96LracAQi3AL7zahiRbRxQe0P1+ePharOft7GareA69oqZDmWEkzfjeaJ5nbe5ZvFezO/PMKjytRDvdqQNaHAB4oIO/ZZPNU6GCay+91S0Ji9nPpQAIAPffWf5x8+eqQatDiY02ebCoNub4V9rNVzHWuFj2eKpkzYoLeteVlnju/ixio+9ExfMDz40JyJgk9pFogiMvgJ3N0eK+gNd5CDpdtGtXnugCdWQPwww+d+WARf1B2dwSUr0+hpN2SLmAF1UPt/R6Cms/XkAFSl75d2mrVHax03PJUHRHACXAakYyHanzK/u8qJA94S/Czq6ebHxphHrAqOlrEkuj6a/qXkJe0TIqzDKoOSWt1ExyB8ibl3TTrZTWgPAh1k7c9GmfQebHpgkKmZFKpYBwwY34crUK+sPJIw//ZZhuWuz2uO3tbvGN4vtu5kzWQF/wNoyjcZtr+fAcglLHkT7uhoD21nD5o5DgEc7V4onDzXGjEm/h2FNP4s7nbYpW+o3RTJeCXKVqyVMRzfmkqt9kXCwLDrN3gW/lWcpeKoep7+dQrL7MJNZBKFrQ0QavvoWJIzNzXm2yiqMHBS66KT3VMF6cF0tUdd9C1+tHQzbKn8aZI40j8nRi38qtT2BxyDBulRkafvhnAqLCk2wRUSj/h1aeKuR1oK24mjU9KKHgfaSaiZpY59C2tC55Mk34CsPNtML/8l838fLGIbzV4X2HTQPmKglzKtsmysxR/Nj9UfplXYe+By+OgEyDDuVPRDLqTH0oZ16LXrLCKZEi3t7zOgwZN7fdwQg0WM8Chsa7YlZ4kQ1arjfkdqHFC6W1kgsa9cFp2/seOYlbLPsPD0+Iwdt+6P9OoEbwUJc7OVw3DxZsxZ2sjKjrP+vA yGqivZRW 6v1rYE0LMoW/XEkNAohBILjVHTkrR4XWeXWx0TcdeKF/csRtSalJvHw9BZzqoxnOeUnkcS0rRozpuNVj81gr8PKO/blOVtcN2izJFswg8jlax6rs9S4Nr/FKFvQT6w0upYUfja6kfjDHbY42dS7ctlyNvOS16k4GiTHGfF+/rryDWZkwaMtPszmM0zd9FAAQhbIP5nFGiHBC/fn4An8NYNH8N4FNUN+eFupllM4KUG38jt72M2FASxMHLiBb+xYqoguJweS/8bDtS3RnDwdomR8btlD5XCzP2p9oPAc+e2iN7pWyxwXHPDfKptIEt3jwJVkLpnoE3+wp18i/O9iEXdjiFi+XZJtz3CKZgCCblhYO7a1ss/nnLnoodtJ49jJhE45ubewVaElARQWQ4yarQUIQ0LMfM1tONK8wYagV9k9wx8ArQwgjY/wffGEXxt+NkcgRZhezQ/SNX/pm3dEJSF7J+wMbzFvJ/mI82rfBLGZcwOeprwW1G8zy7ZckH4rc+D8Jkig+yy2Ev3KKG712T+c9H3175vAl3/3wsWbcfQdHKjEbtPMPByFSjUkru1OAT6HdG5hI4FhgmpqQ= 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 Fri, Jun 27, 2025 at 08:58:11AM +0200, Benjamin Berg wrote: > On Fri, 2025-06-27 at 06:20 +0200, Thomas Weißschuh wrote: > > On Thu, Jun 26, 2025 at 08:11:17PM +0200, Benjamin Berg wrote: > > > I ran into two minor issues trying out the patches, see inline. > > > > Thanks for testing the series. > > > > > On Thu, 2025-06-26 at 08:10 +0200, Thomas Weißschuh wrote: > > > > Enable running UAPI tests as part of kunit. > > > > The selftests are embedded into the kernel image and their output is > > > > forwarded to kunit for unified reporting. > > > > > > > > The implementation reuses parts of usermode drivers and usermode > > > > helpers. However these frameworks are not used directly as they make it > > > > impossible to retrieve a thread's exit code. > > > > > > > > Signed-off-by: Thomas Weißschuh > > > > > > > > [SNIP] > > > > +/** > > > > + * KUNIT_UAPI_EMBED_BLOB() - Embed another build artifact into the kernel > > > > + * @_name: The name of symbol under which the artifact is embedded. > > > > + * @_path: Path to the artifact on disk. > > > > + * > > > > + * Embeds a build artifact like a userspace executable into the kernel or current module. > > > > + * The build artifact is read from disk and needs to be already built. > > > > + */ > > > > +#define KUNIT_UAPI_EMBED_BLOB(_name, _path) \ > > > > + asm ( \ > > > > + " .pushsection .rodata, \"a\" \n" \ > > > > + " .global " __stringify(CONCATENATE(_name, _data)) " \n" \ > > > > + __stringify(CONCATENATE(_name, _data)) ": \n" \ > > > > + " .incbin " __stringify(_path) " \n" \ > > > > + " .size " __stringify(CONCATENATE(_name, _data)) ", " \ > > > > + ". - " __stringify(CONCATENATE(_name, _data)) " \n" \ > > > > + " .global " __stringify(CONCATENATE(_name, _end)) " \n" \ > > > > + __stringify(CONCATENATE(_name, _end)) ": \n" \ > > > > + " .popsection \n" \ > > > > + ); \ > > > > + \ > > > > + extern const char CONCATENATE(_name, _data)[]; \ > > > > + extern const char CONCATENATE(_name, _end)[]; \ > > > > + \ > > > > + static const struct kunit_uapi_blob _name = { \ > > > > + .path = _path, \ > > > > + .data = CONCATENATE(_name, _data), \ > > > > + .end = CONCATENATE(_name, _end), \ > > > > + } \ > > > > > > For me, the compiler could not find the files for the ".incbin" unless > > > I added an include path. i.e. adding > > >   ccflags-y := -I$(obj) > > > to lib/kunit/Makefile fixed the problem for me. > > > > Can you share some more details on your build setup? > > This worked for me as-is and also passed 0day build testing. > > Funny, I ran this on a Fedora 41 with gcc --version saying > gcc (GCC) 14.3.1 20250523 (Red Hat 14.3.1-1) > > I tried both 32 and 64 bit builds for ARCH=um. > > Attaching my current kernel configuration and the last few lines of a > V=1 build. > > The kernel I used is a bit newer than what you had. Applied on top of > ee88bddf7f2f5d1f1da87dd7bedc734048b70e88 (bpf-fixes merge). So this happens because you are building inside the source tree. scripts/Makefile.lib has this block: # $(src) for including checkin headers from generated source files # $(obj) for including generated headers from checkin source files ifdef building_out_of_srctree _c_flags += $(addprefix -I, $(src) $(obj)) _a_flags += $(addprefix -I, $(src) $(obj)) _cpp_flags += $(addprefix -I, $(src) $(obj)) endif Apparently GNU/clang assemblers don't look for .incbin/.include files next to the including files [0]. In contrast, the ARM compiler does (at least according to its docs) [1]. Maybe we can work around this in the macro, but I assume this will become even uglier. So for the next revision I'll use your proposal of explicit cflags. Or if Masahiro prefers to have a more global and generic solution, we can do that. [0] https://sourceware.org/binutils/docs/as/I.html [1] https://developer.arm.com/documentation/dui0801/l/Directives-Reference/INCBIN Thomas