Received: by 2002:a05:7412:da14:b0:e2:908c:2ebd with SMTP id fe20csp2060436rdb; Mon, 9 Oct 2023 11:06:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFPsR7L2/ctbllJT5CJ0t3oUX95Qc0+OA7FBhS7GpLAlzub2tE13JYZ/ZoXPLy6uwgkz+um X-Received: by 2002:a17:903:1d0:b0:1c5:bea4:8537 with SMTP id e16-20020a17090301d000b001c5bea48537mr16792694plh.15.1696874790962; Mon, 09 Oct 2023 11:06:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696874790; cv=none; d=google.com; s=arc-20160816; b=B5NDVZJ+RQubPtShKezrUQFjK44+gErGCKxkydYEFIvqrfbkCrUEx9xAi/zqDWM80/ IPuIQs6DbjqoNxAMDjMmOMdYbz5aGBGMfkDlqqb3hvklviTOUWgT+kAreisgn3zHBSrT 5asEIni3PolBmioqq0XwTpq9ua0iEBtSYolG8bzWxq3bbExGRdSYcwD6AY4vavPBdx4t VPW62MtyCP+uXgMKho0k0gZtucu7RLow51rCREigJEs1B8wJ1bt3Hhui3tQU2AZPwLU0 Eq1dss7EHaOrig5YJmM/7LugPuOzyaozu/AvUL/nEi+rSxibhJLveXJFALgDEUTZVBjt Pnvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=k6+v8C9dOHPuWR5XSiUS7gE38om67OdcqI6XVJI0myY=; fh=leV9dbtd7GFNMnyEjsmYDdvMQQWHDrKmyTE64r0kBaw=; b=U+mL5dPq1wMxLIVfpkT/GFEw9bHLdTfKDiri6Ea5i9J+wxwKONFsOg6E3oL/4wOoS7 LyTQfeFQyB0yVdXtJIuukbDBJreus1mvbeK+BZkXvPkYmjIeHYv0iPuVkkVCxTbCwM4E AMcSThctLloHsnrJLmQ2wjJ4H8HtUJOK9C+sZheskvKRzaJhsImjMEe6YTV5ngcLYmEH bcMDGqfmcEukCuQpL7cbIkaE6RQdYZUcqzUoEXK+T9rwNSaOIpP3b7Yw/NSwNlIGUbk6 DF2eww3BM7Ay3AcIhMgLR505aeiv+VnRspprkf5JsyJV+2Zg1HgM+vjLPLbNhq4O74Dw yFhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=g3TE2KEe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id h9-20020a170902f54900b001c3ffc982cfsi10719186plf.142.2023.10.09.11.06.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Oct 2023 11:06:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=g3TE2KEe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 28B53801BB78; Mon, 9 Oct 2023 11:06:26 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1377383AbjJISGR (ORCPT + 99 others); Mon, 9 Oct 2023 14:06:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1376935AbjJISGQ (ORCPT ); Mon, 9 Oct 2023 14:06:16 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7393194; Mon, 9 Oct 2023 11:06:15 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1684C433C7; Mon, 9 Oct 2023 18:06:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1696874775; bh=qqVvnqpRR2N4XysEim0lFNvDHLgFX3LGkETYl0RUp4A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=g3TE2KEeFA9h+2fmDP9XZhcbQc0uMpaGwj7ccP0sJbXdxGQQHNymKHn3YUj4OrhjM UXzja3eHHsmyiRHb+bWSj9pFXrXLL8a6JE7SSWJPxKq/6M+s6ky94JbqAURdhJHsB7 7vKVKTBkklWclrMCflsCU1u+Io306z4YQtA+LyY1gwkjLbZNvP6+PqiKU0pqrq3N+/ opSASAs5D9NG5dfUbCyOP05KhdS2zlR3acolnen7rrWHLzBVjdTR1FX1nEXPQBfwSi cOAg557HhXwoZVS1IEqr2jSKmgPAMVSuANlP26pKsjBWedsRbD1B4V7zoC/OfANosz /MrrZ4pDjclUA== Date: Mon, 9 Oct 2023 11:06:13 -0700 From: Jakub Kicinski To: Sean Christopherson Cc: pbonzini@redhat.com, workflows@vger.kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org Subject: Re: [PATCH] KVM: deprecate KVM_WERROR in favor of general WERROR Message-ID: <20231009110613.2405ff47@kernel.org> In-Reply-To: References: <20231006205415.3501535-1-kuba@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 09 Oct 2023 11:06:26 -0700 (PDT) On Mon, 9 Oct 2023 10:43:43 -0700 Sean Christopherson wrote: > On Fri, Oct 06, 2023, Jakub Kicinski wrote: > > Setting WERROR for random subsystems make life really hard > > for subsystems which want to build-test their stuff with W=1. > > WERROR for the entire kernel now exists and can be used > > instead. W=1 people probably know how to deal with the global > > W=1 already, tracking all per-subsystem WERRORs is too much... > > I assume s/W=1/WERROR=y in this line? Yes, sorry about that. > > Link: https://lore.kernel.org/all/0da9874b6e9fcbaaa5edeb345d7e2a7c859fc818.1696271334.git.thomas.lendacky@amd.com/ > > Signed-off-by: Jakub Kicinski > > --- > > Documentation/process/maintainer-kvm-x86.rst | 2 +- > > arch/x86/kvm/Kconfig | 14 -------------- > > arch/x86/kvm/Makefile | 1 - > > 3 files changed, 1 insertion(+), 16 deletions(-) > > > > diff --git a/Documentation/process/maintainer-kvm-x86.rst b/Documentation/process/maintainer-kvm-x86.rst > > index 9183bd449762..cd70c0351108 100644 > > --- a/Documentation/process/maintainer-kvm-x86.rst > > +++ b/Documentation/process/maintainer-kvm-x86.rst > > @@ -243,7 +243,7 @@ context and disambiguate the reference. > > Testing > > ------- > > At a bare minimum, *all* patches in a series must build cleanly for KVM_INTEL=m > > -KVM_AMD=m, and KVM_WERROR=y. Building every possible combination of Kconfigs > > +KVM_AMD=m, and WERROR=y. Building every possible combination of Kconfigs > > isn't feasible, but the more the merrier. KVM_SMM, KVM_XEN, PROVE_LOCKING, and > > X86_64 are particularly interesting knobs to turn. > > > > diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig > > index ed90f148140d..12929324ac3e 100644 > > --- a/arch/x86/kvm/Kconfig > > +++ b/arch/x86/kvm/Kconfig > > @@ -63,20 +63,6 @@ config KVM > > > > If unsure, say N. > > > > -config KVM_WERROR > > - bool "Compile KVM with -Werror" > > - # KASAN may cause the build to fail due to larger frames > > - default y if X86_64 && !KASAN > > Hrm, I am loath to give up KVM's targeted -Werror as it allows for more aggresive > enabling, e.g. enabling CONFIG_WERROR for i386 builds with other defaults doesn't > work because of CONFIG_FRAME_WARN=1024. That in turns means making WERROR=y a > requirement in maintainer-kvm-x86.rst is likely unreasonable. > > And arguably KVM_WERROR is doing its job by flagging the linked W=1 error. The > problem there lies more in my build testing, which I'll go fix by adding a W=1 > configuration or three. As the changelog notes, I highly doubt W=1 builds work > with WERROR, whereas keeping KVM x86 warning-free even with W=1 is feasible. > > > - # We use the dependency on !COMPILE_TEST to not be enabled > > - # blindly in allmodconfig or allyesconfig configurations > > - depends on KVM > > - depends on (X86_64 && !KASAN) || !COMPILE_TEST > > On a related topic, this is comically stale as WERROR is on by default for both > allmodconfig and allyesconfig, which work because they trigger 64-bit builds. > And KASAN on x86 is 64-bit only. > > Rather than yank out KVM_WERROR entirely, what if we make default=n and trim the > depends down to "KVM && EXPERT && !KASAN"? E.g. IMO setting WERROR is a bit perverse. The way I see it WERROR is a crutch for people who don't have the time / infra to properly build test changes they send to Linus. Or wait for build bots to do their job. We do have sympathy for these folks, we are mostly volunteers after all. At the same time someone's under-investment should not be causing pain to those of us who _do_ build test stuff carefully. Rather than tweak stuff I'd prefer if we could agree that local -Werror is anti-social :( The global WERROR seems to be a good compromise.