Received: by 10.192.165.156 with SMTP id m28csp818919imm; Mon, 16 Apr 2018 09:11:42 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/RQHKjzKtkSj6UY1REzo3wWMUXsBxEGjkgz/guGco4JY6f+RpmMO2C4DFR85Km7dQ8Co+h X-Received: by 10.101.97.200 with SMTP id j8mr13474157pgv.443.1523895102823; Mon, 16 Apr 2018 09:11:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523895102; cv=none; d=google.com; s=arc-20160816; b=RVPp6AnOII0NoFHy1mkcIBEHGWfk6xvHcge+3TPjInf88SgC+fypoS1fKaL9SSIXTW sFQKbraaq3YeK2cIxZuHZJrs/6YsySjt4Oa/nAbd6Gda5E+hHUguUSN4QGlYf43sIm1Y mmX//lRpE8gzlijV7QIYy+8IAgvYG/QQESoQLVrCLVzVBqMqo9M5t7KLXtac9aN9d8SV N84Bhmf3UIts2Kk+zQcoThbBNdZz3yNgZtrBiM8zsW3CrByM3pVSRY6oLhJpEwJrTnYb 3AtihJ6O3RpX9/UbUbCpKrfVv/Duvdoje0EWuI0Si5Q8BhVRdcKqhE9hu42dMB28sVZR gwEQ== 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:arc-authentication-results; bh=00/y1oDhWWZc/Oo/yNT90IdMDMc7qDkV6Dv/YCCPJlU=; b=QyVIIkHEeCtNH4CFmRti6EcIhByKVVH//RDklz/cHoMd3/gCA6va2nJOSVG6DKfSOw Ha7Gftig4/l7GlteIiH7TmO275P8WZiSb3qal3lfSOqRneZvHb1ugWsP3zsnult4SjYE dIDBNFcteSUC1DX+j6ADjtdAgTkyRCrT3/QWt8L6lgEdG3r36IPSPk1wN0JyXzgJlQcW 9Q+AIMFd46rEbrWhaCYCPVvHKNWH+2B+zrMNX+wP3KUTzMqUMZIYoNuRvKUCFbg0KSzJ pboYWLiCI2ohj8kgiliC09QcWiT+18pZ+eUnZKAF48/cYId0k7/IgYdpua++5E4nyA7V yCmg== 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 a6si1460544pgd.277.2018.04.16.09.11.25; Mon, 16 Apr 2018 09:11:42 -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 S1752736AbeDPQKU (ORCPT + 99 others); Mon, 16 Apr 2018 12:10:20 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:45871 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751135AbeDPQKS (ORCPT ); Mon, 16 Apr 2018 12:10:18 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id F199C80264; Mon, 16 Apr 2018 18:10:16 +0200 (CEST) Date: Mon, 16 Apr 2018 18:10:15 +0200 From: Pavel Machek To: Sasha Levin Cc: 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: <20180416161015.GB7071@amd> References: <20180409001936.162706-1-alexander.levin@microsoft.com> <20180409001936.162706-15-alexander.levin@microsoft.com> <20180409082246.34hgp3ymkfqke3a4@pathway.suse.cz> <20180415144248.GP2341@sasha-vm> <20180416093058.6edca0bb@gandalf.local.home> <20180416113629.2474ae74@gandalf.local.home> <20180416160200.GY2341@sasha-vm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rS8CxjVDS/+yyDmU" Content-Disposition: inline In-Reply-To: <20180416160200.GY2341@sasha-vm> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --rS8CxjVDS/+yyDmU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon 2018-04-16 16:02:03, Sasha Levin wrote: > On Mon, Apr 16, 2018 at 11:36:29AM -0400, Steven Rostedt wrote: > >On Mon, 16 Apr 2018 08:18:09 -0700 > >Linus Torvalds wrote: > > > >> On Mon, Apr 16, 2018 at 6:30 AM, Steven Rostedt = wrote: > >> > > >> > I wonder if the "AUTOSEL" patches should at least have an "ack-by" f= rom > >> > someone before they are pulled in. Otherwise there may be some subtle > >> > issues that can find their way into stable releases. > >> > >> I don't know about anybody else, but I get so many of the patch-bot > >> patches for stable etc that I will *not* reply to normal cases. Only > >> if there's some issue with a patch will I reply. > >> > >> I probably do get more than most, but still - requiring active > >> participation for the steady flow of normal stable patches is almost > >> pointless. > >> > >> Just look at the subject line of this thread. The numbers are so big > >> that you almost need exponential notation for them. > >> > > > >I'm worried about just backporting patches that nobody actually looked > >at. Is someone going through and vetting that these should definitely > >be added to stable. I would like to have some trusted human (doesn't > >even need to be the author or maintainer of the patch) to look at all > >the patches before they are applied. >=20 > I do go through every single commit sent this way and review it. > Sometimes things slip by, but it's not a fully automatic process. >=20 > Let's look at this patch as a concrete example: the only reason, > according to the stable rules, that it shouldn't go in -stable is that > it's longer than 100 lines. >=20 > Otherwise, it fixes a bug, it doesn't introduce any new features, it's > upstream, and so on. It had some fixes that went upstream as well? > Great, let's grab those as well. >=20 > >I would say anything more than a trivial patch would require author or > >sub maintainer ack. Look at this patch, I don't think it should go to > >stable, even though it does fix issues. But the fix is for systems > >already having issues, and this keeps printk from making things worse. > >The fix has side effects that other commits have addressed, and if this > >patch gets backported, those other ones must too. >=20 > Sure, let's get those patches in as well. >=20 > One of the things Greg is pushing strongly for is "bug compatibility": > we want the kernel to behave the same way between mainline and stable. > If the code is broken, it should be broken in the same way. Maybe Greg should be Cced on this conversation? Anyway, I don't think "bug compatibility" is a good goal. Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --rS8CxjVDS/+yyDmU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlrUyucACgkQMOfwapXb+vKsLgCgkBwiBshOxVG9qEz4hcJr4E+h RBIAniyDsb9f2LcoUr2MS3ZSknJRu5gK =WpRw -----END PGP SIGNATURE----- --rS8CxjVDS/+yyDmU--