linux-kernel - Re: [PATCH 4/4] kunit: tool: Disable broken options for --alltests

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] [day] [month] [year] [list]

Message-ID: <d14b6a0c72788e78bab2bd1f0bc2c49891ded5d7.camel@sipsolutions.net>
Date:   Sat, 19 Feb 2022 16:43:19 +0100
From:   Johannes Berg <johannes@...solutions.net>
To:     David Gow <davidgow@...gle.com>
Cc:     Jeff Dike <jdike@...toit.com>, Richard Weinberger <richard@....at>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-um <linux-um@...ts.infradead.org>,
        amd-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
        KUnit Development <kunit-dev@...glegroups.com>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>, linux-rdma@...r.kernel.org,
        x86@...nel.org, felix.kuehling@....com,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] kunit: tool: Disable broken options for --alltests

On Sat, 2022-02-19 at 16:00 +0800, David Gow wrote:
> On Fri, Feb 18, 2022 at 8:26 PM Johannes Berg <johannes@...solutions.net> wrote:
> > 
> > On Fri, 2022-02-18 at 15:57 +0800, David Gow wrote:
> > > 
> > > Note that, while this does build again, it still segfaults on startup,
> > > so more work remains to be done.
> > 
> > That's probably just a lot more stuff getting included somehow?
> > 
> 
> Yeah: it used to work (a couple of years ago), but something has
> broken it in the meantime. It's just a shame that bisecting things
> with allyesconfig takes so long...

Heh, right.

But I guess you could "Kconfig bisect" first, i.e. see what option
breaks it? It might not even help to bisect, if it's just some option
getting enabled over time. Or perhaps the kernel is just too big for the
address space layout if you have allyesconfig? Though that shouldn't be
an issue, I think.

> I didn't realise X86 wasn't defined in UML: 

X86 is the architecture, X86_{32,64} is kind of a selection for how you
want things to be built, and it's thus required for UML on x86, because
UML imports stuff from X86.

> that's definitely a bit
> cleaner than !UML in a number of these cases.

It looks like some (most?) of them don't really work that way though
since they're not really platform specific, they just know only about a
handful of platforms that they're compatible with.

> Not all of those issues are fundamentally solved by "depends on X86",
> though: there are a few which might be other missing things in UML
> (maybe the 'dma_ops' issues?), and/or might be the result of -Werror
> being enabled.

Right.

> We do want the ability to build PCI drivers under UML, as it makes
> running KUnit tests for PCI drivers much simpler and more pleasant.

OK, fair point. I'm thinking about this area in general also right now
for iwlwifi, and obviously we're probably the only user of the virtual
PCI code that lets us connect the driver to a simulated device on UML
(but the driver doesn't really know) :-)

> And indeed, it does work for KUnit in general, it's just that some
> drivers do have the issues mentioned above, so allyesconfig picks up
> every broken driver.

Right.

> We don't actually build the PCI drivers by default, only if the
> "--alltests" option is passed, which does include them, as we do have
> tests which depend on PCI we'd like to run (like the thunderbolt
> test).

Makes sense.
> 
> I did try this as well, and it just got us a different set of issues
> (there are a bunch of drivers which depend on IOMEM but don't state it
> -- I'll try to send fixes for those out next week). 
> 

Fun.

> Ultimately, the 'broken_on_uml.config' file is just there to pare back
> allyesconfig a bit for KUnit's purposes, but we still definitely want
> as many options (and hence tests) enabled as possible long-term. So I
> think actual fixes to either the code or Kconfig do make sense.

Makes sense.

> Is 'make ARCH=um allyesconfig' something we actually want to be able
> to build? If so, no amount of adding things to KUnit's
> broken_on_uml.config will solve the underlying issues, and we'll need
> to at least update the Kconfig entries.
> 

That's a good point, as long as people are doing allyes/randconfig
builds on UML, we probably need to have these fixes anyway rather than
disabling something for KUnit specifically.

johannes