[Ksummit-discuss] [MAINTAINERS SUMMIT] Bug-introducing patches

Laura Abbott labbott at redhat.com
Fri Sep 7 15:54:54 UTC 2018


On 09/07/2018 08:06 AM, Sasha Levin wrote:
> On Fri, Sep 07, 2018 at 07:37:06AM -0700, Laura Abbott wrote:
>> On 09/06/2018 07:52 PM, Guenter Roeck wrote:
>>> On 09/06/2018 06:49 PM, Sasha Levin via Ksummit-discuss wrote:
>>>>
>>>> This is a *huge* reason why we see regressions in Stable. Take a look at
>>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.linuxfoundation.org%2Fpipermail%2Fksummit-discuss%2F2018-September%2F005287.html&data=02%7C01%7CAlexander.Levin%40microsoft.com%7Cf206ee69bd71452d0d8d08d614cf64a5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636719278316194423&sdata=rYS7lCcdGMzo0kbFowVot790z8GV2Alr1ynEBd1X6qA%3D&reserved=0
>>>> for a list of recent user visible regressions the CoreOS folks have
>>>> observed this year. Do you want to know when they were merged? Let me
>>>> help you: all but one were merged in -rc5 or later.
>>>>
>>>
>>> My conclusion from that would be that patches are applied to stable
>>> before they had time to soak in mainline. Your argument against
>>> accepting patches into mainline might as well be applied to patches
>>> applied to stable.
>>>
>>> I think you are a bit hypocritical arguing that patches should be
>>> restricted from being accepted into mainline ... when at the same
>>> time patches are at least sometimes applied almost immediately to
>>> stable releases from there. Plus, some if not many of the patches
>>> applied to stable releases nowadays don't really fix critical or
>>> even severe bugs. If the patches mentioned above indeed caused
>>> regressions in mainline, those regressions should have been found
>>> and fixed _before_ the patches made it into stable releases.
>>> Blaming mainline for the problem is just shifting the blame.
>>>
>>> I would argue that, if anything, the rules for accepting patches into
>>> _stable_ releases should be much more strict than they are today.
>>> If anything, we need to look into that, not into restricting patch
>>> access to mainline.
>>
>> Part of my proposal for a longer -rc time for stable was for this
>> exact problem: patches that have been merged in mainline but
>> tagged for stable may not have had time to test to find all
>> bugs. The thought was a longer stable -rc cycle would help
>> in finding those. I think you've hit upon the real problem
>> though which is that the patches probably shouldn't have been
>> in stable in the first place.
> 
> Let me use the CoreOS example here again. Here are the 5 user visible
> stable regressions they had this year:
> 
> 8844618d8aa ("ext4: only look at the bg_flags field if it is valid")
> f46ecbd97f5 ("cifs: Fix slab-out-of-bounds in send_set_info() on SMB2
> ACE setting")
> a6f81fcb2c3 ("tcp: avoid integer overflows in tcp_rcv_space_adjust()")
> 7b2ee50c0cd ("hv_netvsc: common detach logic")
> f599c64fdf7 ("xen-netfront: Fix race between device setup and open")
> a93bf0ff449 ("vxlan: update skb dst pmtu on tx path")
> 
> Which of those patches would you not take in a stable tree in the first
> place?
Okay let me see if I can choose my wording better so I'm not going
around in circles.

I don't disagree that those patches look like they should go in stable.
My issue is that a stable release went out with those patches in them
when they were buggy. We're very good at finding patches for stable
which fix bugs. We're less good at finding buggy patches themselves
in stable. Can we make more of a distinction between patches that
are proposed for stable (all of those patches) and patches that
have had enough testing to be included in stable (probably not those
patches)? I'd like to answer the question of what more could be done
(testing?) to identify those patches which are tagged as fixing
bugs but are also still buggy.

Thanks,
Laura


More information about the Ksummit-discuss mailing list