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: <23585515-73a9-596e-21f1-cbbcc9d7e7f9@redhat.com>
Date:   Wed, 12 Feb 2020 21:01:59 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        KVM list <kvm@...r.kernel.org>,
        Oliver Upton <oupton@...gle.com>
Subject: Re: [GIT PULL] KVM changes for Linux 5.6-rc2

On 12/02/20 20:38, Linus Torvalds wrote:
> On Wed, Feb 12, 2020 at 11:19 AM Paolo Bonzini <pbonzini@...hat.com> wrote:
>>
>>> So this clearly never even got a _whiff_ of build-testing.
>>
>> Oh come on.
> 
> Seriously - if you don't even _look_ at the warnings the build
> generates, then it hasn't been build-tested.
>
> I don't want to hear "Oh come on". I'm 100% serious.

I know, but still I consider it.  There is no reason why the "build
test" should be anything more than "make && echo yes i am build-tested".
 It shouldn't involve any grep or script magic, it's already hard enough
to script all the functional part of the testing.

My "Oh come on" was because "it never got a whiff of build-testing"
hides how "the default build testing configuration is crap".  Of course
I don't want warnings either, but unless there is -Werror somewhere
mistakes _will_ happen.  Get new commits from you, or make mrproper to
build another architecture? Everything gets rebuilt and the warnings
scroll by.  During next-release development I will catch it of course,
but for rc I usually don't even need to build more than once before
applying a pull request.  I am surprised it took a few years for the
wrong set of factors to occur at the same time.

Did I screw up?  Yes.  Could we do better to avoid someone else doing
the same mistake?  Hell yes.

I'm not making excuses.  I'm just saying that the *root* cause is not my
mistake or even Oliver's.  The root cause is that our (shared!)
definition of "good" does not match the exit code of "make".  We all
want zero warnings, but we don't enable -Werror.  Let's add at least a
Kconfig to enable it for every architecture you build-test (is it only
x86 or anything else?).

Paolo

> Build-testing is not just "building". It's the "testing" of the build
> too. You clearly never did _any_ testing of the build, since the build
> had huge warnings.
> 
> Without the checking of the result, "build-testing" is just
> "building", and completely irrelevant.
> 
> If you have problems seeing the warnings, add a "-Werror" to your scripts.
>
> I do not want to see a _single_ warning in the kernel build. Yes, we
> have one in the samples code, and even that annoys the hell out of me.
> 
> And exactly because we don't have any warnings in the default build,
> it should be really really easy to check for new ones - it's not like
> you have to wade through pages of warnings to see if any of them are
> your new ones.
> 
> So no "Oh come on". You did *zero* testing of this crap, and you need
> to own that fact instead of making excuses about it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ