Received: by 10.192.165.156 with SMTP id m28csp1042756imm; Mon, 16 Apr 2018 13:04:02 -0700 (PDT) X-Google-Smtp-Source: AIpwx48fgpWrES4Ns+900H1u0eO24RuO3+5zxhxNPSxjYUHgA/H2uUvbSJSXoc50uBWOdwVmrLV+ X-Received: by 2002:a17:902:6ecd:: with SMTP id l13-v6mr10407623pln.113.1523909042306; Mon, 16 Apr 2018 13:04:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523909042; cv=none; d=google.com; s=arc-20160816; b=V31GWcJLj4agi14/jVA9JuGpuiqtfOLFLUgxg/FHcgo0zRlUGGZ5vK3+G2q6wHCT+D zF0z1xjmXxyUAoG76gPUtzeWxriVKYMG6OsI3ltRjXOjYhFapQUoeyl3a5/gOZsMueAl NqxXPecZK7YBJvuP1RhA5iKabdZCdqqP+n0mND9P1D/zt4Lpce00haLvelKXozgEzJx3 VAgnf+P3EPUmiFgyKtVABkCwcmiLZbA5zmpGR+P90qW2VVlyb8MGpVmTMzOcYDCHHIgQ rCIRiw6tOiq7Oap09CGwk22dqfNBiWltkl11QrIx0gCm7IS5hS7Pbrh03EGbmMFtLMMa Uq7A== 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 :dmarc-filter:arc-authentication-results; bh=JTSK97ovT3YNjU/lNJm2dMkkVxgbvCaYDV2QaLX+868=; b=X7Q7aLa+OjtH/lYnxkLsEInk3uMrQy+e3TK7Ijni2maP5Emk+ksSsSIGXcsRZufykX oINZs24pEavsEYqWiqxT8GqAVLT2sX/nS86syo+kFO52AybWCg7oM77k+/s5olLaTT8o f3q/F20+wpCIcc0NxQuAgR8qIr8HZ0whkR5q23MhQlI0ftwvhOy4EP7FjmGOcJhEm7xs iIhtHMZe73izTblvs6P6s71oAWGUIvOBev5zBhUqIQ6k2jXLzC0c082EF7cqKVMQdzQ/ pKl7gINNmeUhDxMY/hYCnvhcZ6jODNCmL4l0tXyzYbokJljI7H92Rpyw5pH8AHjoFmlg CXEg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n3si2024707pgd.534.2018.04.16.13.03.47; Mon, 16 Apr 2018 13:04:02 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753580AbeDPUCi (ORCPT + 99 others); Mon, 16 Apr 2018 16:02:38 -0400 Received: from mail.kernel.org ([198.145.29.99]:51492 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753244AbeDPUCg (ORCPT ); Mon, 16 Apr 2018 16:02:36 -0400 Received: from gandalf.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (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 ED6D321771; Mon, 16 Apr 2018 20:02:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED6D321771 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Mon, 16 Apr 2018 16:02:32 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Sasha Levin , Pavel Machek , Petr Mladek , "stable@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , Cong Wang , Dave Hansen , Johannes Weiner , Mel Gorman , Michal Hocko , Vlastimil Babka , Peter Zijlstra , Jan Kara , Mathieu Desnoyers , Tetsuo Handa , Byungchul Park , Tejun Heo , Greg KH Subject: Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes Message-ID: <20180416160232.2b807ff1@gandalf.local.home> In-Reply-To: References: <20180416153031.GA5039@amd> <20180416155031.GX2341@sasha-vm> <20180416160608.GA7071@amd> <20180416122019.1c175925@gandalf.local.home> <20180416162757.GB2341@sasha-vm> <20180416163952.GA8740@amd> <20180416164310.GF2341@sasha-vm> <20180416125307.0c4f6f28@gandalf.local.home> <20180416170936.GI2341@sasha-vm> <20180416133321.40a166a4@gandalf.local.home> <20180416174236.GL2341@sasha-vm> <20180416142653.0f017647@gandalf.local.home> <20180416144117.5757ee70@gandalf.local.home> <20180416152429.529e3cba@gandalf.local.home> <20180416153816.292a5b5c@gandalf.local.home> X-Mailer: Claws Mail 3.16.0 (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 Mon, 16 Apr 2018 12:55:46 -0700 Linus Torvalds wrote: > On Mon, Apr 16, 2018 at 12:38 PM, Steven Rostedt wrote: > > > > But I don't see in the git history that this was ever reverted. My reply > > saying that "I hope it wasn't reverted", was a response for it being > > reverted in stable, not mainline. > > See my other email. Already replied. > > If your'e stable maintainer, and you get a report of a commit that > causes problems, your first reaction probably really should just be > "revert it". > > You can always re-apply it later, but a patch that causes problems is > absolutely very much suspect, and automatically should make any stable > maintainer go "that needs much more analysis". > > Sure, hopefully automation finds the fix too (ie commit 21b81716c6bf > "ipr: Fix regression when loading firmware") in mainline. > > It did have the proper "fixes" tag, so it should hopefully have been > easy to find by the automation that stable people use. > > But at the same time, I still maintain that "just revert it" is > rather likely the right solution for stable. If it had a bug once, > maybe it shouldn't have been applied in the first place. > > The author can then get notified by the other stable automation, and > at that point argue for "yeah, it was buggy, but together with this > other fix it's really important". > > But even when that is the case, I really don't see that the author > should complain about it being reverted. Because it's *such* a > no-brainer in stable. But this is going way off topic to what we were discussing. The discussion is about what gets backported. Is automating the process going to make stable better? Or is it likely to add more regressions. Sasha's response has been that his automated process has the same rate of regressions as what gets tagged by authors. My argument is that perhaps authors should tag less to stable. -- Steve