Received: by 10.192.165.156 with SMTP id m28csp1682093imm; Tue, 17 Apr 2018 03:48:07 -0700 (PDT) X-Google-Smtp-Source: AIpwx48wzU6IIgv+WfpIs1quMI+Zxit8ktllWhvsHRHGP8nk2IkoVovzIUP9YrZr11EDCb5PQkZk X-Received: by 10.98.162.2 with SMTP id m2mr1504287pff.251.1523962087924; Tue, 17 Apr 2018 03:48:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523962087; cv=none; d=google.com; s=arc-20160816; b=SDK82XHb+2J99XQQvswImKjz5R620AvmPwpT1LtIIjiRy20YUn6yI372JCbtqrUm/7 06/B4qzHnoHfY3uE8L5X7UjKOSPN53sIDw+0HvzuJ4kjpmGC2IWGFOFg8ba98vFFUz27 u17ABoH5dBSfi6aXL5AzJTrOUCMeoGj5uo4SbP4ezPe/9ph0QwN5dHX6M9iKJykwHvbO Kv3Qt9hIhD7JkLn6dqOZvF08u0hluDCp/r6wu514UkQaGm3riLAdcYSLfYy3Ho8mWNT1 FBlv+P8LR6Ag0QrEVeSpSRqIfp6yHgHwxeNgoJQtuq/7CTaS5VvE1f0+7uH3A4vEX0lX wbyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=kItfi/iZ7JCBTvdV0HKvw3inLTwHtRa8WcXRci7HoGk=; b=byZ+KwwKLcKpibwsIrM4DS0mVxM0XfkNLJg20msjKptqK7geTnX1YcN2/TQuus8r4D 3FotBDb87LKuBd2ZSiHybjkrsA6b9Je7ZK8yX0SAOo6ZuEVztyByji/otP2R2SCP8rzi w6sJ4ebHoJNplS9ZjM5Z1+8Qjb+uFhg9YkGVvct+64rdh+O6ZegrqzqaTo7IppcuzVs1 QRlT75rDKIqI1ZcfprRd2QPRxrQz3O4dat73F+HE0QiovOrL9D7Q+sSxrM3f+aH+jraT X1REXTik1fxtXEZyaOXvdckizIaXcA3OX6NV30W7MI0AyMBx1MLd94+8yfs6SQj5dAjP 3Dbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=eeOWfW5+; 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 p188si4081605pga.206.2018.04.17.03.47.54; Tue, 17 Apr 2018 03:48:07 -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; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=eeOWfW5+; 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 S1752633AbeDQKqp (ORCPT + 99 others); Tue, 17 Apr 2018 06:46:45 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:36807 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751980AbeDQKqn (ORCPT ); Tue, 17 Apr 2018 06:46:43 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id C29AB21BE3; Tue, 17 Apr 2018 06:46:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 17 Apr 2018 06:46:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=kItfi/iZ7JCBTvdV0HKvw3inLTwHt Ra8WcXRci7HoGk=; b=eeOWfW5+a5jMp8A3CFxPUrMrkO5eREZgDJ3sW65BzxE17 4Px69LjbV6imFyfjepjzXcNDRFjLMO3zI+9ZU32cbQdYOtGGu0cQBAboppEHw6j0 jpuCzHvn7nRcAU1/injD9qhy/H1yagms6mE5aWp0ldHVocRgUWSpAcNOFSWjscqA 7OSdATImlG4DMTkRFdyw+6VBIg0+QUuK3cHujt7Z3fTJyFMywFYvROX+FYiIPEPt iwQ/9CJ2ahyFZ/8cJiann5mBCXF37QRpFL5FFiLrX2n22Flu0smWNPkvvWKSWk9X 7brlTY+n+4X5wHeC626DYskWpV60Av8V3QMOzqOtg== X-ME-Sender: Received: from localhost (unknown [46.44.180.42]) by mail.messagingengine.com (Postfix) with ESMTPA id E8F88102DD; Tue, 17 Apr 2018 06:46:41 -0400 (EDT) Date: Tue, 17 Apr 2018 12:46:37 +0200 From: Greg KH To: Pavel Machek Cc: Sasha Levin , Steven Rostedt , Linus Torvalds , 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 Subject: Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes Message-ID: <20180417104637.GD8445@kroah.com> References: <20180416153031.GA5039@amd> <20180416155031.GX2341@sasha-vm> <20180416160608.GA7071@amd> <20180416161412.GZ2341@sasha-vm> <20180416122244.146aec48@gandalf.local.home> <20180416163107.GC2341@sasha-vm> <20180416124711.048f1858@gandalf.local.home> <20180416165258.GH2341@sasha-vm> <20180416170010.GA11034@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180416170010.GA11034@amd> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 16, 2018 at 07:00:10PM +0200, Pavel Machek wrote: > Hi! > > > >> Let me ask my wife (who is happy using Linux as a regular desktop user) > > >> how comfortable she would be with triaging kernel bugs... > > > > > >That's really up to the distribution, not the main kernel stable. Does > > >she download and compile the kernels herself? Does she use LEDs? > > > > > >The point is, stable is to keep what was working continued working. > > >If we don't care about introducing a regression, and just want to keep > > >regressions the same as mainline, why not just go to mainline? That way > > >you can also get the new features? Mainline already has the mantra to > > >not break user space. When I work on new features, I sometimes stumble > > >on bugs with the current features. And some of those fixes require a > > >rewrite. It was "good enough" before, but every so often could cause a > > >bug that the new feature would trigger more often. Do we back port that > > >rewrite? Do we backport fixes to old code that are more likely to be > > >triggered by new features? > > > > > >Ideally, we should be working on getting to no regressions to stable. > > > > This is exactly what we're doing. > > > > If a fix for a bug in -stable introduces a different regression, > > should we take it or not? > > If a fix for bug introduces regression, would you call it "obviously > correct"? I honestly can't believe you all are arguing about this. We backport bugfixes to the stable tree. If those fixes also are buggy we either apply the fix for that problem that ended up in Linus's tree, or we revert the patch. If the fix is not in Linus's tree, sometimes we leave the "bug" in stable for a bit to apply some pressure on the developer/maintainer to get it fixed in Linus's tree (that's what I mean by being "bug compatible".) This is exactly what we have been doing for over a decade now, why are people suddenly getting upset? Oh, I know why, suddenly subsystems that never were taking the time to mark patches for stable are getting patches backported and are getting nervous. The simple way to stop that from happening is to PROPERLY MARK PATCHES FOR STABLE IN THE FIRST PLACE! If you do that, then, no "automated" patches will get selected as you already handled them all. Or if there are some automated patches picked, you can easily NAK them (like xfs does as they know better than everyone else, and honestly, I trust them, and don't run xfs myself), or do like what I do when it happens to me and go "hey, nice, I missed that one!" There, problem solved, if you do that, no more worrying by you at all, and this thread can properly die. ugh, greg k-h