Received: by 2002:a05:7412:da14:b0:e2:908c:2ebd with SMTP id fe20csp2355949rdb; Tue, 10 Oct 2023 01:04:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGUFfYqyV9clt+UFuW/TWL+EnFh+wBhMXXQCY5oWqY5HILbgIh/hKg8R2XidG/MpnLkctuI X-Received: by 2002:a05:6a20:7348:b0:154:d3ac:2063 with SMTP id v8-20020a056a20734800b00154d3ac2063mr18223703pzc.27.1696925091667; Tue, 10 Oct 2023 01:04:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696925091; cv=none; d=google.com; s=arc-20160816; b=uPD4/Jt+IGGOw9tFZXjIb3mrwwfHfDbYHRNtzitKfo0CcJL6ljxi+udizMQy76bjEZ hczFzWkiHtMq193UOilaGMaw+HZeSrYGTHKtSaNQCfrnD59wIA3x/pmOuLaPxsZjyN2U K8Qo0nAUsbFaQr7qBCkQogAlFspOx0Cw0Z49eXcA+SYyb4wmf/7f+0nrhyHhpmrKZ1Z1 ilFx9AgN4moSTJ4TzOL3gtj2mKEmF/ECysPR6dRHeO53mjGEnicRfZBrrY6u5R2B0E+U igQLaNQPO5azDTDLi64lGnJctYDBXBjCz5wJkTDP/VrgrZL/kx9Y55VO9BORUHxVCHmy CcVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :organization:in-reply-to:subject:cc:to:from:dkim-signature; bh=yIpzC3VCLiAKfL+p8zS10jOgQUNJCzOt0i8V/lXaDtQ=; fh=nluZmH+Yzx5QEo1iAOutG0X5Ra7ayZCXQKWnONEzH+k=; b=uN+Pwsv/WdD+lvd9l8MF9O7UBi/DG+UpBLWWj0TejHbnobnBFRyDD+LAbjw743rQOf K52IyWPQ/zEJ0JhdMlbz8ZbkhHW3g8qznU5Epp7+G3JKl4xGG2HDORr//Zmu8Mr9Cp0y jdKfBJ3AZas1Mo11ylGEXV2AgZoCQcqYurZG9W2u55emLKGyozXPkxQetBtj3CuW+gBL 54mXyKO58+vV9J5YOtJleN7ETtJj70Z0f8HIRypzzvO4tLUaxQSFKPC1lVig2Ki7d0vB uNAOKmPhQUitUW1HeM9nYb9Ld6pjDpuHK1ME9s3uuUQwR0Vz5mqBbaNXpg37cHZRR0OM 8l9Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=XtueLShw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id j10-20020a170902da8a00b001b8ba81d04dsi12382996plx.395.2023.10.10.01.04.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Oct 2023 01:04:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=XtueLShw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 989D482D87B0; Tue, 10 Oct 2023 01:04:48 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234634AbjJJIE1 (ORCPT + 99 others); Tue, 10 Oct 2023 04:04:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49430 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234631AbjJJIE0 (ORCPT ); Tue, 10 Oct 2023 04:04:26 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2EC6A4; Tue, 10 Oct 2023 01:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1696925063; x=1728461063; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=9LiiwaafL7vqK3S5UC+zEZeuqHkrKCe3GV3w9WmVU4k=; b=XtueLShwNhFTt1rfpMfXbn/ayQ6lkipJceGENEZob9WWbOEkhQLyuFQO u24AtSpGBWak0wyABqnpW2Ty//226gZ/q4Em5jko9PwkTzZokxuGZTlBT V1WRmDDetUFnNgTJkFfV3h2hkNTazKE0MJDRbBPskIfdwGXjr9OA8hWoR BbBRzBechS2GhO4qH+pgmaXJ4uq5QrP7f4jmtRAXnBRQcJYLb5cuovGep 6k5ECXqiyzbldtqWGd0PIQFe8YeNXk/5rp2ZifKKrfpu4aWQRl/7JL7ar LxdCG9EYez9btVvxaXolKtviW8BLTt68xuZdUF3NJc2zvbaAXqNGPvyJq A==; X-IronPort-AV: E=McAfee;i="6600,9927,10858"; a="363684569" X-IronPort-AV: E=Sophos;i="6.03,212,1694761200"; d="scan'208";a="363684569" Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2023 01:04:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10858"; a="927050497" X-IronPort-AV: E=Sophos;i="6.03,212,1694761200"; d="scan'208";a="927050497" Received: from pors-mobl3.ger.corp.intel.com (HELO localhost) ([10.252.42.155]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Oct 2023 01:04:20 -0700 From: Jani Nikula To: Jakub Kicinski , Sean Christopherson , Linus Torvalds 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 In-Reply-To: <20231009144944.17c8eba3@kernel.org> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <20231006205415.3501535-1-kuba@kernel.org> <20231009110613.2405ff47@kernel.org> <20231009144944.17c8eba3@kernel.org> Date: Tue, 10 Oct 2023 11:04:18 +0300 Message-ID: <87sf6i6gzh.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=2.7 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email 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 (fry.vger.email [0.0.0.0]); Tue, 10 Oct 2023 01:04:48 -0700 (PDT) X-Spam-Level: ** On Mon, 09 Oct 2023, Jakub Kicinski wrote: > On Mon, 9 Oct 2023 12:33:53 -0700 Sean Christopherson wrote: >> > 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. >> >> This is a bit over the top. Yeah, I need to add W=1 to my build scripts, but that's >> not a lack of investment, just an oversight. Though in this case it likely wouldn't >> have made any difference since Paolo grabbed the patches directly and might have >> even bypassed linux-next. But again I would argue that's bad process, not a lack >> of investment. > > If you do invest in build testing automation, why can't your automation > count warnings rather than depend on WERROR? I don't understand. Because having both CI and the subsystem/driver developers enable a local WERROR actually works in keeping the subsystem/driver clean of warnings. For i915, we also enable W=1 warnings and kernel-doc -Werror with it, keeping all of them warning clean. I don't much appreciate calling that anti-social. > >> > 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. >> >> I disagree. WERROR simply doesn't provide the same coverage. E.g. it can't be >> enabled for i386 without tuning FRAME_WARN, which (a) won't be at all obvious to >> the average contributor and (b) increasing FRAME_WARN effectively reduces the >> test coverage of KVM i386. >> >> For KVM x86, I want the rules for contributing to be clearly documented, and as >> simple as possible. I don't see a sane way to achieve that with WERROR=y. > > Linus, you created the global WERROR option. Do you have an opinion > on whether random subsystems should create their own WERROR flags? > W=1 warning got in thru KVM and since they have a KVM_WERROR which > defaults to enabled it broke build testing in networking. > Randomly sprinkled -Werrors are fragile. Can we ask people to stop > using them now that the global ERROR exists? The DRM_I915_WERROR config depends on EXPERT and !COMPILE_TEST, and to my knowledge this has never caused issues outside of i915 developers and CI. Maybe the fix to KVM_ERROR config should be - depends on (X86_64 && !KASAN) || !COMPILE_TEST - depends on (X86_64 && !KASAN) && !COMPILE_TEST BR, Jani. -- Jani Nikula, Intel