linux-kernel - Re: 5.13.2-rc and others have many not for stable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 15 Jul 2021 10:57:54 -0500
From:   Justin Forbes <jmforbes@...uxtx.org>
To:     Sasha Levin <sashal@...nel.org>
Cc:     Michal Hocko <mhocko@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Hugh Dickins <hughd@...gle.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Miaohe Lin <linmiaohe@...wei.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux-MM <linux-mm@...ck.org>, Stable <stable@...r.kernel.org>
Subject: Re: 5.13.2-rc and others have many not for stable

On Wed, Jul 14, 2021 at 10:30 AM Sasha Levin <sashal@...nel.org> 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.
>

It does work both ways. For those of us maintaining a kernel for a
community distro, without an army of engineers actually paying
attention, the current stable process has fixed more bugs than it has
introduced.  But it does occasionally introduce them as well. When it
does, it is typically pretty easy to see where, as stable releases
tend to be smaller than this set was, so only a few patches in any
given subsystem or driver.  If we go back to a case where only Cc:
stable patches are selected, I suppose the logical step would be for
maintainers like me to make sure that we send a message to stable
whenever we pull a patch from upstream that fixes an actual issue that
users are seeing.  I don't have a strong objection to this, but it is
more work.

Justin

> 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@...e.com>
> Date:   Tue May 4 11:12:10 2021 +0200
>
>      mm: memcontrol: fix cpuhotplug statistics flushing
>      (bsc#1185606).
>
>      suse-commit: 3bba386a33fac144abf2507554cb21552acb16af
>
> This 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.
>
> 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?
>
> --
> Thanks,
> Sasha