Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp657776rwb; Wed, 28 Sep 2022 07:34:21 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6QHNlOGXMmYQX2WxBqTd2hFJeRggL8sjJ84qeo7EjAgVCWCxMeRrCNqQxCEF2wN2PEIPG5 X-Received: by 2002:a63:4e4d:0:b0:43c:5c1d:4a60 with SMTP id o13-20020a634e4d000000b0043c5c1d4a60mr23546685pgl.338.1664375660997; Wed, 28 Sep 2022 07:34:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664375660; cv=none; d=google.com; s=arc-20160816; b=w9rMitxGIpY8WRoW/CENEPIWp8K6iyUJ4LP1irTbjk58rG5mYFP+X/O23qa6VDwBFL znrTD475EDd6X7BdWp+2eL/mJgLhSlD7E34uDjOj4CHRHa2RgV0dk6hH1xLJqq7aWLon JDXGR+iiXfcgUXYVDlxWAwCUI7b1W87fasjftmc7DNyeeE9PYuBhyYoocyuIq0jPNQB9 6yYg5UzeLfFz8Iove8H2eXG7w4DEL4u1Fsjbh1veBOp8Mqb0xtmZQwocM+c0hggC445J HoEYnme7+x1ELKo90BuDC566EjnGko8lhnDPvCsw2K5Us6Md97UM5T8dyX9xvH3z7oOR IMPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Xl3s6np3thQqV7b5PLy2sMzW5jKteWMBx5DZFvaLryE=; b=lDcYsXmPlEPOVzd6OGgPSDlY0IOWOkIHu/+mEpY5rYBHA4rM8uG0r2+bSTvFN+PQ7b tr8s1e2v/ICXn5ynz28JfY6sq5s4Ry2wOsuBcchXo+8uAKqWHgLBOcthm4j+LChJ9eUy eifb42uaVN8SQkT1K7DmiUcjQ7HL6vVzHTGQy8S9KPKhtT+FMEByADsHq565kor+xQ2H iNVWDqoctMRziOyTbKrhFcWj+3xu3tHtz49kwHeKagQOUm9ByeFM8Wi/MYTtxAtyvknb xw9GF/x8f0FjuYCrSZpUGlaj3rnOivYrqRep8LrNOwueQAveWs/ktGLNSldg3KyBQjA6 +PYg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=JGOorsiY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j71-20020a638b4a000000b0043517bc149csi5683790pge.303.2022.09.28.07.34.09; Wed, 28 Sep 2022 07:34:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=JGOorsiY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234246AbiI1N7H (ORCPT + 99 others); Wed, 28 Sep 2022 09:59:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37368 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234208AbiI1N7F (ORCPT ); Wed, 28 Sep 2022 09:59:05 -0400 Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8EEE6F24E for ; Wed, 28 Sep 2022 06:59:02 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id d15so7870901qka.9 for ; Wed, 28 Sep 2022 06:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=Xl3s6np3thQqV7b5PLy2sMzW5jKteWMBx5DZFvaLryE=; b=JGOorsiYUNjvI8/WD7E2CgaiXHZQgB0JDGDdZb+8DhWqv7w5VxaqdmkMVPU3vKlnA4 hGfpg+dHdXAbwVeRNVK5yuL4XBBMjhpS9U6LcEIoXkhsRjeTo9XwC9RvddgpBIpcLM7E oX/OcunbT/1d8V348Ux6/ZEPF+DnP1RUNhqMdE2pXckOJlyNmWEfwJmz9yz7ipVMyu3e rfHcdl10jK5xZBtHvAfVTZS5FFEwY5A1u7/X82VuJ4xaNY1kHjDsV1BBsXLBsGezoCnl 8XuU1qyer25lMYkjlYc6Ty3UKKNY37O0cr+quxDXsiwIk2si9Mo0kkFvKE2WWqyl+3YR QR5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=Xl3s6np3thQqV7b5PLy2sMzW5jKteWMBx5DZFvaLryE=; b=K5qAzdlp3rqOUWsHctQ2rg5yucv15YPM4gveemAM/A6+TYetdMuqQj0f/oeDfl11vd 7+uu4DpuZp8KNFt7hesmM4EEQpbzUejmGbggCBNkoBzdKNIwBFjJguPx6dJWB4qYEe9f KT0Bn12b7dUm2GEu61uvxAF9f3AgES0RZ763IrnUkpwsVN2g3tZftGys6atNPj4ynP7h uBrIGJSm1HnAKQzGvAMArA8rPb6Uyp/Rwb0DIaHVY7xqvePXLzG+jc1ITb80VxeaB8Cu Br5LACldGu2I9jxLH7PqDrMXs65GFfiXRhOJardv4Pdeor7vmYPUFft/kF9tQ/Gf3ndw eqeQ== X-Gm-Message-State: ACrzQf1e8xkik4A2xkXf4832JST2rm1nwuAL4NT8E4v1aePs5eQHOhUE Q/RafbWLYI1zd6LfuPR5ukl5iklkZBISDAQLnzbN X-Received: by 2002:a05:620a:29c9:b0:6ce:7681:19e9 with SMTP id s9-20020a05620a29c900b006ce768119e9mr21006494qkp.297.1664373541846; Wed, 28 Sep 2022 06:59:01 -0700 (PDT) MIME-Version: 1.0 References: <20220823142456.3977086-1-joefradley@google.com> <10f97a94-ab35-fbc7-4dd7-98586a027c8b@gmail.com> In-Reply-To: <10f97a94-ab35-fbc7-4dd7-98586a027c8b@gmail.com> From: Joe Fradley Date: Wed, 28 Sep 2022 06:58:50 -0700 Message-ID: Subject: Re: [PATCH v2 0/2] kunit: add boot time parameter to enable KUnit To: Tales Aparecida Cc: Jonathan Corbet , David Gow , Brendan Higgins , kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Sep 24, 2022 at 5:42 PM Tales Aparecida wrote: > > Hi, > > > This series is > Tested-by: Tales Aparecida > > 1. Tested using kunit_tool: running tests and showing output as expected. > > 2. Tested further by running QEMU through virtme-run with: > $ ../virtme/virtme-run --show-command --kdir ../linux/.for-amd/ --mods=auto --kopt kunit.enable=1 > > 2.a. "KUNIT_DEFAULT_ENABLED" works as expected when "kunit.enable" is omitted > 2.b. kunit.enable=0 results in printing "kunit: disabled" on boot and on loading test modules, as expected > 3.c. kunit.enable=1 runs tests on boot and allows them to run when loading test modules > > 3. Regarding taint > 3.a. /proc/sys/kernel/tainted is 0 when kunit.enable=0 and does not change when trying to load test modules. > 3.b. /proc/sys/kernel/tainted is 0 when kunit.enable=1 until the first test runs, then it becomes 262144 (2^18) as expected. Tales, thank you for doing this testing. > > > On other note, there's something I would like to delve into below. > > > On 23/08/2022 11:24, Joe Fradley wrote: > > v2: > > - Added enable check in executor.c to prevent wrong error output from > > kunit_tool.py when run against a KUnit disabled kernel > > - kunit_tool.py now passes kunit.enable=1 > > - Flipped around logic of new config to KUNIT_DEFAULT_ENABLED > > - Now load modules containing tests but not executing them > > - Various message/description text clean up > > > > There are some use cases where the kernel binary is desired to be the same > > for both production and testing. This poses a problem for users of KUnit > > as built-in tests will automatically run at startup and test modules > > can still be loaded leaving the kernel in an unsafe state. There is a > > "test" taint flag that gets set if a test runs but nothing to prevent > > the execution. > > Do you have any info on whether these use cases would have something against writing tests for static functions using the documented approach of including the tests into the actual runtime code? > https://docs.kernel.org/dev-tools/kunit/usage.html#testing-static-functions > > Otherwise, would them agree to export the symbols that need to be tested? > > I would really like to understand better what are these use cases :) I feel using the static functions as described in your link is a good alternative to modules with embedded KUnit tests. However, this is a different use case then I refer to, which is the ability to have the framework embedded in the kernel for both production and test with the control of test execution gated on a kernel command line parameter. > > > > > This patch adds the kunit.enable module parameter that will need to be > > set to true in addition to KUNIT being enabled for KUnit tests to run. > > The default value is true giving backwards compatibility. However, for > > the production+testing use case the new config option KUNIT_DEFAULT_ENABLED > > can be set to N requiring the tester to opt-in by passing kunit.enable=1 to > > the kernel. > > > > Joe Fradley (2): > > kunit: add kunit.enable to enable/disable KUnit test > > kunit: no longer call module_info(test, "Y") for kunit modules > > > > .../admin-guide/kernel-parameters.txt | 6 +++++ > > include/kunit/test.h | 3 ++- > > lib/kunit/Kconfig | 11 +++++++++ > > lib/kunit/executor.c | 4 ++++ > > lib/kunit/test.c | 24 +++++++++++++++++++ > > tools/testing/kunit/kunit_kernel.py | 1 + > > 6 files changed, 48 insertions(+), 1 deletion(-) > > > > Great work! > > Kind regards, > Tales