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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 82FE2C433F5 for ; Mon, 9 May 2022 20:43:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229647AbiEIUrm (ORCPT ); Mon, 9 May 2022 16:47:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33362 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229567AbiEIUrl (ORCPT ); Mon, 9 May 2022 16:47:41 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36153B1D3; Mon, 9 May 2022 13:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zxtHEZB7FJXcLD4uWhqlrNQfKLg4uYSZS3iQcpPv3Q8=; b=Um4T745eraA4H0ZgNxS0pk18PZ Xq97mepNxGxMSUjCP+wxeGnaWEH5/cdZnQBcwwp/nYhhVo0LZ0izp4JI5JLx/tuGEZhpgwmnCpwbf 2txDSDfzQXZuX51PS3ujK++12T6SuqFqyX9iHBdzrIXBEwXzKGUPjXBHtkEGWls89KE/8klzoNmKc OtRsmT+7lqC9xf9aTPvk9a7bUeFPBORXhMxzsTl8lnLlgwKsSrZfIa7TmD/4zQ2C9RPd7NtoZqmth dF3gybOaVG6RP99mI4FvocGXiSQrwuUY58gBdt2p0lR6Ir2l99ABzRmYO+DKAJ8vfOhqZfu0Trp+2 2ega45ZQ==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1noAEG-00GCg8-KP; Mon, 09 May 2022 20:43:40 +0000 Date: Mon, 9 May 2022 13:43:40 -0700 From: Luis Chamberlain To: David Gow Cc: Daniel Latypov , Shuah Khan , Lucas De Marchi , Aaron Tomlin , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, Brendan Higgins , Andy Shevchenko , Jonathan Corbet , Andrew Morton , Kees Cook , Greg KH , "Guilherme G . Piccoli" , Sebastian Reichel , John Ogness , Joe Fradley , KUnit Development , "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Jani Nikula Subject: Re: [PATCH v2] kunit: Taint kernel if any tests run Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Luis Chamberlain Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Fri, May 06, 2022 at 03:01:34PM +0800, David Gow wrote: > On Thu, May 5, 2022 at 1:57 PM Luis Chamberlain wrote: > > > > On Wed, May 04, 2022 at 02:12:30PM -0700, Luis Chamberlain wrote: > > > On Wed, May 04, 2022 at 02:19:59PM -0500, Daniel Latypov wrote: > > > > On Wed, May 4, 2022 at 1:46 PM Luis Chamberlain wrote: > > > > > OK so, we can just skip tainting considerations for selftests which > > > > > don't use modules for now. There may be selftests which do wonky > > > > > things in userspace but indeed I agree the userspace taint would > > > > > be better for those but I don't think it may be worth bother > > > > > worrying about those at this point in time. > > > > > > > > > > But my point in that sharing a taint between kunit / selftests modules > > > > > does make sense and is easily possible. The unfortunate aspect is just > > > > > > > > Yes, I 100% agree that we should share a taint for kernelspace testing > > > > from both kunit/kselftest. > > > > Someone running the system won't care what framework was used. > > > > > > OK do you mind doing the nasty work of manually adding the new > > > MODULE_TAINT() to the selftests as part of your effort? > > > > > > *Alternatively*, if we *moved* all sefltests modules to a new > > > lib/debug/selftests/ directory or something like that then t would > > > seem modpost *could* add the taint flag automagically for us without > > > having to edit or require it on new drivers. We have similar type of > > > taint for staging, see add_staging_flag(). > > > > > > I would *highly* prefer this approach, event though it is more work, > > > because I think this is a step we should take anyway. > > > > > > However, I just checked modules on lib/ and well, some of them are > > > already in their own directory, like lib/math/test_div64.c. So not > > > sure, maybe just move a few modules which are just in lib/*.c for now > > > and then just sprinkle the MODULE_TAINT() to the others? > > > > I *think* we could just pull this off with a much easier approach, > > simply looking for the substrings in the module name in modpost.c: > > > > * "_test." || "-test." > > * ^"test_" || ^"test-" > > > > An issue with this of course is a vendor $FOO with an out of tree > > test driver may end up with the taint. Perhaps we don't care. > > > > That means moving selftests to its own directory is not needed at this > > point in time. > > I can't say I'm thrilled with the idea of just doing name comparisons, > particularly since not all of them match this pattern, for example: > bpf_testmod.ko. (Though, frankly, more of them do than I'd've > guessed.) > > Maybe adding a taint call to the selftest helper module framework in > kselftest_module.h, though again, there are several tests which don't > use it. Right, I can't think of a generic way to peg this. I think long term we do stand to gain to move all selftests under a lib/debug/selftests/ or something like that, but for now what I suggested is the only thing I can come up with. > I _suspect_ we'd be able to hit most of them by tainting in frameworks > like the above, and patch the remaining modules manually. Works with me. > There's also > definitely a grey area with things like netdevsim, which are used a > lot as helper modules by selftests, but may have other uses as well. They can peg the module if they want the taint. > (The advantage of the KUnit tainting is that, due to KUnit's > centralised executor, we can be sure all KUnit tests will correctly > trigger the taint. But maybe it doesn't matter as much if one or two > selftests miss out.) That is what I was thinking. I'm convinced we *should* move selftests to a one directory. The amount of stuff in lib/ is getting out of hand. Luis