linux-kernel - Re: [PATCH 5.5 00/65] 5.5.11-rc1 review

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200322203458.GR4189@sasha-vm>
Date:   Sun, 22 Mar 2020 16:34:58 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Pavel Machek <pavel@...x.de>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        akpm@...ux-foundation.org, shuah@...nel.org, patches@...nelci.org,
        ben.hutchings@...ethink.co.uk, lkft-triage@...ts.linaro.org,
        stable@...r.kernel.org, Kevin Hao <haokexin@...il.com>
Subject: Re: [PATCH 5.5 00/65] 5.5.11-rc1 review

On Sun, Mar 22, 2020 at 08:51:34PM +0100, Pavel Machek wrote:
>Hi!
>
>> > > Thanks for letting me know, I've now dropped that patch (others
>> > > complained about it for other reasons) and will push out a -rc2 with
>> > > that fix.
>> > >
>> >
>> > I did wonder why the offending patch was included, but then I figured that
>> > I lost the "we apply too many patches to stable releases" battle, and I didn't
>> > want to re-litigate it.
>>
>> I usually much rather take prerequisite patches rather than do
>> backports, which is why that patch was selected.
>
>Unfortunately, that results in less useful -stable.

This is different than the usual "too many patches in -stable" argument
you keep bringing up; here we *know* that we need a certain patch, but
you claim that I should pick up a piece of code I'm unfamiliar with and
try to hammer it to work on an older kernel rather than take a
prerequisite patch to do that for me.

Not only that in my experience taking prerequisites was the safer
option, it's also the case that piling up modified backports causes the
stable tree to diverge from upstream, making older trees much more
difficult to maintain than what they are now.

Does it always work? Obviously not, but it's much easier for reviewers
to notice a mistake of bringing in a patch rather than a subtle issue
with a backport.

I'll happily look at hard data comparing (real) regression rates of
cases where prerequisites were taken vs a modified backport of a patch.
Please also remember to include cases where the prerequisite patch ended
up being a fix on it's own that we should have picked up.

Otherwise, I'm not sure how you think that you're contributing to the
discussion here.

-- 
Thanks,
Sasha