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 X-Spam-Level: X-Spam-Status: No, score=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 337B2C352A4 for ; Wed, 12 Feb 2020 20:02:07 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EF755218AC for ; Wed, 12 Feb 2020 20:02:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="EaXusB6f" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729055AbgBLUCG (ORCPT ); Wed, 12 Feb 2020 15:02:06 -0500 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:60165 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727600AbgBLUCF (ORCPT ); Wed, 12 Feb 2020 15:02:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581537724; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xACQJzdDDlbOWzGGCryoyeWskqYfJq+P7a8dbWxnMZg=; b=EaXusB6fxxGR0qZaqZr8nVMssqse3H0+S1yYgDuim2BZfomOvQPQ5adUouehb7O9xf4IS3 eC6vlqo7Fsddv0mC4gwuYQtXK5FWEVUL+Pz+ThzewEILmzzAINDytZWMJpiUeqzNxLyVV4 Ak5MwmRrHo03jv33LCTnAamEFK3sH6s= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-425-RmmUsNWMNiyLqUdBOgPXhQ-1; Wed, 12 Feb 2020 15:02:02 -0500 X-MC-Unique: RmmUsNWMNiyLqUdBOgPXhQ-1 Received: by mail-wm1-f70.google.com with SMTP id a189so1184599wme.2 for ; Wed, 12 Feb 2020 12:02:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xACQJzdDDlbOWzGGCryoyeWskqYfJq+P7a8dbWxnMZg=; b=Q9HBFZ65c80lTTJYjGCxlh7LuC1bIM69Hm5cSywxq5Ffepg2EIhE59lKivGlIV5nbF 04DrZUBGs5vVw8QdTTRLC6+rw2F5aaOYR1mhTk9x1vxToWWqgvll8cd04w0FpbSebz1O AKU8ypdi3S91OlBmTPjXyz5A6w4hnpZIxDkBfYGnPDpmYcawUG3+/fT/+LXCUBV5rbkg u6EqaEeVBWu+K6hdErfFxcTHv6/NTctgKr096/rSn3Y4wIgwzhXNc/o9uYh+29QjnX/9 klySl7Vr/q6qRG7PqcngYK6EcHlJ5yvUqdkkmkoZ5ya0M/Jv+bVpdVpRBac/Yksbklmk tB6w== X-Gm-Message-State: APjAAAW+Yr8Fs/siq6WoZeVLl5tfLX/aPvlBKqGocBGkHXpFmar5krKY EVqEF8i28t9E23TxrYQ35vmoUrCtShuk1rEdGqah2jPxTPpcViMehTUI7piB3f+1//o6KgZ6/ye dIox836lTt3E76hbrwXJI9W36 X-Received: by 2002:adf:e2c5:: with SMTP id d5mr16732615wrj.165.1581537720864; Wed, 12 Feb 2020 12:02:00 -0800 (PST) X-Google-Smtp-Source: APXvYqwmfvhQhntZ0xl323TsLbJsGJRLD3EnRwc6SDjJpS5+J/aqGrVF/uNojcfTxi8DzEt/rbz3dA== X-Received: by 2002:adf:e2c5:: with SMTP id d5mr16732593wrj.165.1581537720554; Wed, 12 Feb 2020 12:02:00 -0800 (PST) Received: from ?IPv6:2001:b07:6468:f312:652c:29a6:517b:66d9? ([2001:b07:6468:f312:652c:29a6:517b:66d9]) by smtp.gmail.com with ESMTPSA id e16sm1954758wrs.73.2020.02.12.12.01.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Feb 2020 12:02:00 -0800 (PST) Subject: Re: [GIT PULL] KVM changes for Linux 5.6-rc2 To: Linus Torvalds Cc: Linux Kernel Mailing List , KVM list , Oliver Upton References: <20200212164714.7733-1-pbonzini@redhat.com> From: Paolo Bonzini Message-ID: <23585515-73a9-596e-21f1-cbbcc9d7e7f9@redhat.com> Date: Wed, 12 Feb 2020 21:01:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/02/20 20:38, Linus Torvalds wrote: > On Wed, Feb 12, 2020 at 11:19 AM Paolo Bonzini 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.