From: Greg KH <greg@kroah.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Sasha Levin <Alexander.Levin@microsoft.com>,
Pavel Machek <pavel@ucw.cz>,
Linus Torvalds <torvalds@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Petr Mladek <pmladek@suse.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Cong Wang <xiyou.wangcong@gmail.com>,
Dave Hansen <dave.hansen@intel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>,
Vlastimil Babka <vbabka@suse.cz>,
Peter Zijlstra <peterz@infradead.org>, Jan Kara <jack@suse.cz>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Byungchul Park <byungchul.park@lge.com>,
Tejun Heo <tj@kernel.org>
Subject: Re: [PATCH AUTOSEL for 4.14 015/161] printk: Add console owner and waiter logic to load balance console writes
Date: Tue, 17 Apr 2018 12:39:36 +0200 [thread overview]
Message-ID: <20180417103936.GC8445@kroah.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.1804162326210.28129@cbobk.fhfr.pm>
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
next prev parent reply other threads:[~2018-04-17 10:39 UTC|newest]
Thread overview: 113+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180409001936.162706-1-alexander.levin@microsoft.com>
2018-04-09 0:19 ` Sasha Levin
2018-04-09 8:22 ` Petr Mladek
2018-04-15 14:42 ` Sasha Levin
2018-04-16 13:30 ` Steven Rostedt
2018-04-16 15:18 ` Linus Torvalds
2018-04-16 15:30 ` Pavel Machek
2018-04-16 15:50 ` Sasha Levin
2018-04-16 16:06 ` Pavel Machek
2018-04-16 16:14 ` Sasha Levin
2018-04-16 16:22 ` Steven Rostedt
2018-04-16 16:31 ` Sasha Levin
2018-04-16 16:47 ` Steven Rostedt
2018-04-16 16:53 ` Sasha Levin
2018-04-16 17:00 ` Pavel Machek
2018-04-17 10:46 ` Greg KH
2018-04-17 12:24 ` Petr Mladek
2018-04-17 12:49 ` Michal Hocko
2018-04-17 13:39 ` Sasha Levin
2018-04-17 14:22 ` Michal Hocko
2018-04-17 14:36 ` Sasha Levin
2018-04-17 18:10 ` Michal Hocko
2018-04-17 13:45 ` Sasha Levin
2018-04-18 8:33 ` Petr Mladek
2018-04-16 16:28 ` Pavel Machek
2018-04-16 16:39 ` Sasha Levin
2018-04-16 16:42 ` Pavel Machek
2018-04-16 16:45 ` Sasha Levin
2018-04-16 16:54 ` Pavel Machek
2018-04-17 10:50 ` Greg KH
2018-04-16 17:05 ` Pavel Machek
2018-04-16 17:16 ` Sasha Levin
2018-04-16 17:44 ` Steven Rostedt
2018-04-16 18:17 ` Sasha Levin
2018-04-16 18:35 ` Steven Rostedt
2018-04-16 20:17 ` Jiri Kosina
2018-04-16 20:36 ` Sasha Levin
2018-04-16 20:43 ` Jiri Kosina
2018-04-16 21:18 ` Sasha Levin
2018-04-16 21:28 ` Jiri Kosina
2018-04-17 10:39 ` Greg KH [this message]
2018-04-17 11:07 ` Michal Hocko
2018-04-17 14:04 ` Sasha Levin
2018-04-17 14:15 ` Steven Rostedt
2018-04-17 14:36 ` Greg KH
2018-04-17 14:36 ` Michal Hocko
2018-04-17 14:55 ` Sasha Levin
2018-04-17 15:52 ` Jiri Kosina
2018-04-17 16:06 ` Sasha Levin
2018-05-03 10:04 ` Pavel Machek
2018-05-03 13:02 ` Sasha Levin
2018-04-17 16:25 ` Mike Galbraith
2018-04-17 11:21 ` Jiri Kosina
2018-05-03 9:47 ` Pavel Machek
2018-05-03 13:06 ` Sasha Levin
2018-04-16 16:20 ` Steven Rostedt
2018-04-16 16:28 ` Sasha Levin
2018-04-16 16:39 ` Pavel Machek
2018-04-16 16:43 ` Sasha Levin
2018-04-16 16:53 ` Steven Rostedt
2018-04-16 16:58 ` Pavel Machek
2018-04-16 17:09 ` Sasha Levin
2018-04-16 17:33 ` Steven Rostedt
2018-04-16 17:42 ` Sasha Levin
2018-04-16 18:26 ` Steven Rostedt
2018-04-16 18:30 ` Linus Torvalds
2018-04-16 18:41 ` Steven Rostedt
2018-04-16 18:52 ` Linus Torvalds
2018-04-16 19:00 ` Linus Torvalds
2018-04-16 19:30 ` Steven Rostedt
2018-04-16 19:19 ` Linus Torvalds
2018-04-16 19:24 ` Steven Rostedt
2018-04-16 19:28 ` Linus Torvalds
2018-04-16 19:31 ` Linus Torvalds
2018-04-16 19:58 ` Steven Rostedt
2018-04-16 19:38 ` Steven Rostedt
2018-04-16 19:55 ` Linus Torvalds
2018-04-16 20:02 ` Steven Rostedt
2018-04-16 20:17 ` Linus Torvalds
2018-04-16 20:33 ` Jiri Kosina
2018-04-16 21:27 ` Steven Rostedt
2018-04-16 18:35 ` Sasha Levin
2018-04-16 18:57 ` Steven Rostedt
2018-04-16 15:36 ` Steven Rostedt
2018-04-16 16:02 ` Sasha Levin
2018-04-16 16:10 ` Pavel Machek
2018-04-16 16:12 ` Steven Rostedt
2018-04-16 16:19 ` Sasha Levin
2018-04-16 16:30 ` Steven Rostedt
2018-04-16 16:37 ` Sasha Levin
2018-04-16 17:06 ` Pavel Machek
2018-04-16 17:23 ` Sasha Levin
2018-04-17 11:41 ` Jan Kara
2018-04-17 13:31 ` Sasha Levin
2018-04-17 15:55 ` Jan Kara
2018-04-17 16:19 ` Sasha Levin
2018-04-17 17:57 ` Jan Kara
2018-04-17 18:28 ` Sasha Levin
2018-05-03 9:36 ` Pavel Machek
2018-05-03 13:28 ` Sasha Levin
2018-05-03 9:32 ` Pavel Machek
2018-05-03 13:30 ` Sasha Levin
2018-04-19 11:41 ` Thomas Backlund
2018-04-19 13:59 ` Greg KH
2018-04-19 14:05 ` Jan Kara
2018-04-19 14:22 ` Greg KH
2018-04-19 15:16 ` Thomas Backlund
2018-04-19 15:57 ` Greg KH
2018-04-19 16:25 ` Thomas Backlund
2018-04-19 16:41 ` Greg KH
2018-04-19 15:04 ` Thomas Backlund
2018-04-19 15:09 ` Sasha Levin
2018-04-19 16:20 ` Thomas Backlund
2018-04-16 15:39 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180417103936.GC8445@kroah.com \
--to=greg@kroah.com \
--cc=Alexander.Levin@microsoft.com \
--cc=akpm@linux-foundation.org \
--cc=byungchul.park@lge.com \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=jikos@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=pavel@ucw.cz \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=xiyou.wangcong@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox