Received: by 10.192.165.156 with SMTP id m28csp1677825imm; Tue, 17 Apr 2018 03:42:27 -0700 (PDT) X-Google-Smtp-Source: AIpwx48P1CtYWVcGZrkpN+SJTAq4It8uric8nogYJ9+zOl3Lq4sLgZ0ejoXq7tlkHroZip3zjKZE X-Received: by 2002:a17:902:b68e:: with SMTP id c14-v6mr1550647pls.286.1523961747294; Tue, 17 Apr 2018 03:42:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523961747; cv=none; d=google.com; s=arc-20160816; b=v47oDLvxgbfKe4AfESLSVcP7yKF4VAnTJ7mB5ir9hi4EVXEDXGOgWH0VsO4aeE9YQD cbk/VnEofZ1Af7qI9A3K7E39pN9izO0GR80HFeaLQWxeh54neOOdMggD9/J1edYU0pTW PvuecA7gyZnBR1jBJRFg4m+oDWMvjthWtMylbaK77cvoSSVdiGZNM+aCMVjOhdxFwOvf D3coICAw23pQ0XKLwN2UNkNMoBQBb+CZfETlAIpmo5ctwnNAYGhkbH0NIL9lwUmPcF6u YRkwlX0HKHfEU/3K4FeCRLk9Zov/OICH7p2CDgUBr98VuIt4jN0Owz2LPqu2W4juQl6O ygCQ== 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=h50jmYGNogjIiun9Q5WY2Zq1caxv3/JfQWDR2YR3ek4=; b=Ept/9DiWpCR26rxBBUa+wKtBryhnoK0cq/oQ9+JomX9FbtbZDlc9qnJV9nEU/B+0jn eDBTmNyEABX+lyVS4avG8AmrWhCDCwDPC7XwtfHZ4W3PeuKBhNUZ+eGYvROtITwTcrWk 5cnF8QlhcACr1ZDjFHQodIKtQ4+p7XJnX6ZTfmk8dBUX6U8x453SycL5OdJ2VSHWfpC4 CTI4AT2OJf7V000xLxjJntZlERA749bzzJmtXv9B0tDrjkCKnXWI+DR2oCgnkrSe9ohn xVxdtutxoXQwH6ByI3VeYQs/zYAATAiy/shh/pluz1/5RJaecwp+l90pHkUZXN2ZQCCN 2Fbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=K2BKWEoc; 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.42.13; Tue, 17 Apr 2018 03:42:27 -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=K2BKWEoc; 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 S1752273AbeDQKjq (ORCPT + 99 others); Tue, 17 Apr 2018 06:39:46 -0400 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:47423 "EHLO out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751211AbeDQKjm (ORCPT ); Tue, 17 Apr 2018 06:39:42 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5445021B04; Tue, 17 Apr 2018 06:39:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Tue, 17 Apr 2018 06:39: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=h50jmYGNogjIiun9Q5WY2Zq1caxv3 /JfQWDR2YR3ek4=; b=K2BKWEocPZbdnkP4SHg5rpcJAPveC81bJtd0aosalqvQj Xyj93uk3DKuIdEHtKUlz3XYey42BLuc0LRBo3Bn2KBkz5sjli+gOI1izsXwzNE3D W3DLwl/MkQOpISqVmsJys7YkYinFZPCDO+L8sgg7hzA90zVApGyyalJs3toI3Qqr 8BmiJ9Z21t6sjyJve9vE7CSfnNOBQ7TCD9DSYm6XOtR+o5wCyQqxJ+KTW3ix5ykp dLI10B/e/ICjufjQT82WVBegKyhBymv5QgqGlpvNcHJrFhdopGNXNyXn9wTZh9gz WKzjFf7iJ/SMI2hhsKw6Lgs45QdMDRfeSNCNV15fw== X-ME-Sender: Received: from localhost (unknown [46.44.180.42]) by mail.messagingengine.com (Postfix) with ESMTPA id B5986102C4; Tue, 17 Apr 2018 06:39:41 -0400 (EDT) Date: Tue, 17 Apr 2018 12:39:36 +0200 From: Greg KH To: Jiri Kosina Cc: Sasha Levin , Pavel Machek , Linus Torvalds , Steven Rostedt , 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: <20180417103936.GC8445@kroah.com> References: <20180416155031.GX2341@sasha-vm> <20180416160608.GA7071@amd> <20180416161412.GZ2341@sasha-vm> <20180416170501.GB11034@amd> <20180416171607.GJ2341@sasha-vm> <20180416203629.GO2341@sasha-vm> <20180416211845.GP2341@sasha-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 11:28:44PM +0200, Jiri Kosina wrote: > On Mon, 16 Apr 2018, Sasha Levin wrote: > > > I agree that as an enterprise distro taking everything from -stable > > isn't the best idea. Ideally you'd want to be close to the first > > extreme you've mentioned and only take commits if customers are asking > > you to do so. > > > > I think that the rule we're trying to agree upon is the "It must fix > > a real bug that bothers people". > > > > I think that we can agree that it's impossible to expect every single > > Linux user to go on LKML and complain about a bug he encountered, so the > > rule quickly becomes "It must fix a real bug that can bother people". > > So is there a reason why stable couldn't become some hybrid-form union of > > - really critical issues (data corruption, boot issues, severe security > issues) taken from bleeding edge upstream > - [reviewed] cherry-picks of functional fixes from major distro kernels > (based on that very -stable release), as that's apparently what people > are hitting in the real world with that particular kernel It already is that :) The problem Sasha is trying to solve here is that for many subsystems, maintainers do not mark patches for stable at all. So real bugfixes that do hit people are not getting to those kernels, which force the distros to do extra work to triage a bug, dig through upstream kernels, find and apply the patch. By identifying the patches that should have been marked for stable, based on the ways that the changelog text is written and the logic in the patch itself, we circumvent that extra annoyance of users hitting problems and complaining, or ignoring them and hoping they go away if they reboot. I've been doing this "by hand" for many years now, with no complaints so far. Sasha has taken it to the next level as I don't scale and has started to automate it using some really nice tools. That's all, this isn't crazy new features being backported, it's just patches that are obviously fixes being added to the stable tree. Yes, sometimes those fixes need additional fixes, and that's fine, normal stable-marked patches need that all the time. I don't see anyone complaining about that, right? So nothing "new" is happening here, EXCEPT we are actually starting to get a better kernel-wide coverage for stable fixes, which we have not had in the past. That's a good thing! The number of patches applied to stable is still a very very very tiny % compared to mainline, so nothing new is happening here. Oh, and if you do want to complain about huge new features being backported, look at the mess that Spectre and Meltdown has caused in the stable trees. I don't see anyone complaining about those massive changes :) thanks, greg k-h