Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1016780ybj; Thu, 7 May 2020 12:47:32 -0700 (PDT) X-Google-Smtp-Source: APiQypK34Vpn5ZAfvzAD3H3POT5LJP4vW4rylOXYP9N1bbQ2JY9lmZ5snooWmLKR5s84ZrgPYl4G X-Received: by 2002:aa7:dacc:: with SMTP id x12mr13867729eds.363.1588880852313; Thu, 07 May 2020 12:47:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588880852; cv=none; d=google.com; s=arc-20160816; b=QHFkP4LJfMFE8KbhxnI6oPmNHAGe13oKkY+jg5HevfXLaaf8SMF7qnw3Ekmu0S3K6m fK51vqw3n0xhm2vMKI84p0218gl5KE5QxtDavGcXmVNClK/LylHTc29Ibss5Ni5OdZ4C uFqu5rAGcesxpwrCtrbxKN534zv/v9W39poG1dKpewm0vwBRmRSk+GP5QkiehLre5hMw UnFKfYHbNxPWrMd2t1wc60gBZd4AjxVmZ+dObSSzq5obwc8AKgBSBfYaN0boZ0e1hDLU uJuxHp5c0couvjttYhZFSRqmFyeTI6wKVqfyA/XyNSf4HQTREtXG7qNRzh5UsgVH4Jbt 8NAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=c+BDpk0OTf5ORxZiUmUZzYi4HzcFtsw1m2Y+TmOA6Q8=; b=FH4foj7CnjDV+l2MakDYNXRXexdyKGsy5W46ga7M9GF/PPz7HyZD6BV6yNOd+DTZwK Tl4Czr4PY8s4sgTaRhRsGcJ7pEIWxE3A4O1rF9VTi+xJ9wmGjmYX6eFYavKuZ9yUz/hJ c5F1uTs8jnFPVtv1/7OGGMK3PrseNfp1uYCuwAXsWlIY3dzAb5OTFZuBIcXMhi/fWVFZ s7ojhYu+jpde+pwwtExBImLyNe6LJqNUQafvZbNj3xfayBjUQPeh38iUUmwZg7enl+sd i51yzDIlYQOZg1IOvFvmmXh5U1GEUAT5hyXkzcI0EDwjVbwjjyAa5OrYVvXpZnaEixA3 kvSg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id b10si3725299edw.150.2020.05.07.12.47.08; Thu, 07 May 2020 12:47:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728439AbgEGTpP (ORCPT + 99 others); Thu, 7 May 2020 15:45:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:37766 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728229AbgEGTpP (ORCPT ); Thu, 7 May 2020 15:45:15 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 944F8208E4; Thu, 7 May 2020 19:45:13 +0000 (UTC) Date: Thu, 7 May 2020 15:45:12 -0400 From: Steven Rostedt To: Joe Perches Cc: Valentin Schneider , Jason Yan , mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, bsegall@google.com, mgorman@suse.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched/fair: Return true,false in voluntary_active_balance() Message-ID: <20200507154512.1065cba8@gandalf.local.home> In-Reply-To: <96fe70f11245433ce4f19bffaf2d167dbf69a2a0.camel@perches.com> References: <20200507110625.37254-1-yanaijie@huawei.com> <20200507132828.1af39b80@gandalf.local.home> <20200507133024.18dbe349@gandalf.local.home> <20200507144534.09abd685@gandalf.local.home> <96fe70f11245433ce4f19bffaf2d167dbf69a2a0.camel@perches.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 07 May 2020 12:06:56 -0700 Joe Perches wrote: > People describe changes as a "fix" all the time for stuff > that isn't an actual fix for a logic defect but is instead > an update to a particular style preference. > > Then the "fix" word causes the patch to be rather uselessly > applied to stable trees by AUTOSEL. > > It's especially bad when the 'Fixes: ("description")' > tag is also added. > > It's a difficult thing to regulate and I don't believe a > good mechanism would be possible to add to checkpatch or > coccinelle to help isolate these things. > > git diff -w sometimes helps, but that's not really a thing > that checkpatch could do. > > Any suggestions? I'm unfamiliar with how the coccinelle script is used, but I thought there was some discussion some time back to have checkpatch not produces the same kinds of warnings to code as it does to patches. A lot of useless updates were being submitted when people were running checkpatch on existing kernel code and producing warnings that are not worth "fixing", but something that new code should try to avoid. Basically, I'm fine with a warning that tells you that 1/0 is used for boolean on code being submitted, but we really shouldn't be encouraging people to change the code that currently exists with such updates. -- Steve