From: Petr Mladek <pmladek@suse.com>
To: Greg KH <greg@kroah.com>
Cc: Pavel Machek <pavel@ucw.cz>,
Sasha Levin <Alexander.Levin@microsoft.com>,
Steven Rostedt <rostedt@goodmis.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"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 14:24:54 +0200 [thread overview]
Message-ID: <20180417122454.rwkwpsfvyhpzvvx3@pathway.suse.cz> (raw)
In-Reply-To: <20180417104637.GD8445@kroah.com>
On Tue 2018-04-17 12:46:37, Greg KH wrote:
> 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.
Yes, I am getting nervous because of this. The number of printk fixes
nominated for stable is increasing exponentially (just my feeling)
during last few months.
The problem is that I want to be responsible and think about possible
regressions. Sometimes it requires checking the state of the
particular kernel release. The older code base the more complicated
the decision is.
You might argue that backporting the fixes helps to get the same code
in all supported code bases. But it is not true. It never will be
the same.
Anyway, in the past the "automatically" nominated printk fixes
were trivial. They did not cause harm. But they also were not
worth it, IMHO. They fixed corner cases that were there for ages.
Most of these fixes were found by code review when working on
a feature. They were not backed by bug reports.
Last week, autosel nominated pretty non-trivial patch (started
this thread). It partly solved a problem we tried to fix last few
years.
On one side, this was an annoying problem that motivated several
people spend a lot of time on it. This might be a motivation
for a backport.
On the other hand, it took many years to come somewhere. The main
problem was the fear of regressions. We fixed/improved many things
in the mean time. It shows that the problem really is not trivial.
The same is true for the fix. We did our best to avoid regressions.
But it does not mean that there are none. Also it does not mean
that it will really give better results in all situations.
I really do not see a reason to hurry and backport this to
the older kernel releases. It means to spread the fix but also
eventual problems. It is easy to miss a dependant patch.
The less trivial fix, the more possible problems are there.
Back to the trend. Last week I got autosel mails even for
patches that were still being discussed, had issues, and
were far from upstream:
https://lkml.kernel.org/r/DM5PR2101MB1032AB19B489D46B717B50D4FBBB0@DM5PR2101MB1032.namprd21.prod.outlook.com
https://lkml.kernel.org/r/DM5PR2101MB10327FA0A7E0D2C901E33B79FBBB0@DM5PR2101MB1032.namprd21.prod.outlook.com
It might be a good idea if the mail asked to add Fixes: tag
or stable mailing list. But the mail suggested to add the
unfinished patch into stable branch directly (even before
upstreaming?).
Now, there are only hand full of printk patches in each
release, so it is still doable. I just do not understand
how other maintainers, from much more busy subsystems,
could cope with this trend.
By other words. If you want to automatize patch nomination,
you might need to automatize also patch review. Or you need
to keep the patch rate low. This might mean to nominate
only important and rather trivial fixes.
Best Regards,
Petr
next prev parent reply other threads:[~2018-04-17 12:25 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 [this message]
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
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=20180417122454.rwkwpsfvyhpzvvx3@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=Alexander.Levin@microsoft.com \
--cc=akpm@linux-foundation.org \
--cc=byungchul.park@lge.com \
--cc=dave.hansen@intel.com \
--cc=greg@kroah.com \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--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=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