On Wed 14-07-21 11:30:46, Sasha Levin wrote:
On Wed, Jul 14, 2021 at 09:52:58AM +0200, Michal Hocko wrote:
On Tue 13-07-21 18:28:13, Andrew Morton wrote:
At present this -stable promiscuity is overriding the (sometime carefully) considered decisions of the MM developers, and that's a bit scary.
Not only scary, it is also a waste of precious time of those who carefuly evaluate stable tree backports.
I'm just as concerned with the other direction: we end up missing quite a lot of patches that are needed in practice, and no one is circling back to make sure that we have everything we need.
I took a peek at SUSE's tree to see how things work there, and looking at the very latest mm/ commit:
commit c8c7b321edcf7a7e8c22dc66e0366f72aa2390f0 Author: Michal Koutný mkoutny@suse.com Date: Tue May 4 11:12:10 2021 +0200
mm: memcontrol: fix cpuhotplug statistics flushing (bsc#1185606). suse-commit: 3bba386a33fac144abf2507554cb21552acb16afThis seems to be commit a3d4c05a4474 ("mm: memcontrol: fix cpuhotplug statistics flushing") upstream, and I assume that it was picked because it fixed a real bug someone cares about.
Nope. It has been identified as potentially useful/nice to have. There was no actual bug report requiring it. We do that a lot. In fact we do have a full infrastructure around git fixes and backport fixes proactively. Mostly because stable tree, which we used to track in the past, has turned out to be overwhelming with questionable/risky backports. The thing, though, is that those fixes are carefully reviewed by a domain expert before backporting.
I can maybe understand that at the time that the patch was written/committed it didn't seem like stable@ material and thus there was no cc to stable.
But once someone realized it needs to be backported, why weren't we told to take it into stable too?
We tend to do that for many real bug reports.