linux-kernel - Re: [PATCH] thunderbolt: test: get running under UML, add kunitconfig

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABVgOS=VF9tJKppbpkbLBxThXMStsQz808m_w2g9CRXLiv1LBQ@mail.gmail.com>
Date:   Tue, 15 Feb 2022 14:35:02 +0800
From:   David Gow <davidgow@...gle.com>
To:     Daniel Latypov <dlatypov@...gle.com>
Cc:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        KUnit Development <kunit-dev@...glegroups.com>,
        linux-usb@...r.kernel.org
Subject: Re: [PATCH] thunderbolt: test: get running under UML, add kunitconfig

On Tue, Feb 15, 2022 at 10:39 AM Daniel Latypov <dlatypov@...gle.com> wrote:
>
> On Mon, Feb 14, 2022 at 10:41 AM Daniel Latypov <dlatypov@...gle.com> wrote:
> >
> > These tests didn't work under the normal `kunit.py run` command since
> > they require CONFIG_PCI=y, which could not be set on ARCH=um.
> >
> > Commit 68f5d3f3b654 ("um: add PCI over virtio emulation driver") lets us
> > do so. To make it so people don't have to figure out how to do so, we
> > add a drivers/thunderbolt/.kunitconfig.
> >
> > Can now run these tests using
> > $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/thunderbolt
> >
> > Potentially controversial bits:
> > 1. this .kunitconfig is UML-specific, can't do this for example
> > $ ./tools/testing/kunit/kunit.py run --arch=x86_64 --kunitconfig=drivers/thunderbolt
> > 2. this removes the manual call to __kunit_test_suites_init(), which
> >    allowed us to control exactly when the tests got run.
>
> kernel-test-robot points out something I had forgotten.
> Doing this prevents us from being able to build this test as a module.
>
> kunit_test_suites() defines an init_module() which conflicts with the
> existing ones.
>
> There's some relevant discussion about reworking how kunit modules
> work here, https://lore.kernel.org/linux-kselftest/e5fa413ed59083ca63f3479d507b972380da0dcf.camel@codeconstruct.com.au/
>
> So I think we have two options for this patch:
> a) proceed, but disable building the test as a module for now (tristate => bool)
> b) wait on this patch until kunit module support is refactored
>
> Basically the question is: does this slightly easier way of running
> the test seem worth losing the ability to test as a module in the
> short-term?

Since this was originally changed to support modules (so clearly,
they're being used), I don't think breaking module support (even
temporarily) is going to be worth it:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2c6ea4e2cefe2e86af782a5b8e1070f4d434f2f2

Obviously, when module support is improved, then this fix will make a
lot of sense.

I do think adding the .kunitconfig file is worth doing (though
obviously there are some small problems with the way results show up
separately from any other tests due to the issue above).

Cheers,
-- David

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4003 bytes)