Message-ID: <1af270c3-8a4f-6c62-bb6c-b454a507f443@canonical.com>
Date:   Mon, 27 Sep 2021 16:58:45 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Dan Carpenter <dan.carpenter@...cle.com>,
        Samuel Ortiz <sameo@...ux.intel.com>,
        "David S. Miller" <davem@...emloft.net>,
        "John W. Linville" <linville@...driver.com>,
        netdev@...r.kernel.org, kernel-janitors@...r.kernel.org
Subject: Re: [PATCH net] nfc: avoid potential race condition

On 27/09/2021 16:26, Jakub Kicinski wrote:
> On Mon, 27 Sep 2021 09:44:08 +0200 Krzysztof Kozlowski wrote:
>> On 24/09/2021 22:14, Jakub Kicinski wrote:
>>> On Fri, 24 Sep 2021 10:21:33 +0200 Krzysztof Kozlowski wrote:  
>>>> Indeed. The code looks reasonable, though, so even if race is not really
>>>> reproducible:
>>>>
>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>  
>>>
>>> Would you mind making a call if this is net (which will mean stable) or
>>> net-next material (without the Fixes tags) and reposting? Thanks! :)  
>>
>> Hi Jakub,
>>
>> Material is net-next. However I don't understand why it should be
>> without "Fixes" in such case?
>>
>> The material going to current release (RC, so I understood: net), should
>> fix only issues introduced in current merge window. Linus made it clear
>> several times.
> 
> Oh, really? I've never heard about this rule, would you be able to dig
> up references?

Not that easy to go through thousands of emails, but I'll try:

"One thing that does bother him is developers who send him fixes in the
-rc2 or -rc3 time frame for things that never worked in the first place.
If something never worked, then the fact that it doesn't work now is not
a regression, so the fixes should just wait for the next merge window.
Those fixes are, after all, essentially development work."
https://lwn.net/Articles/705245/

"The rc stuff is for regressions, and for things that actually are
nasty problems (security, keeping people from getting work done)."
https://lore.kernel.org/lkml/CA+55aFyn1matXDTkeDA1d2+tHBSVkBvS5kP-7Ngh86=uut+yyg@mail.gmail.com/

"NONE of this seems really to be appropriate for this stage. It doesn't
fix regressions, it doesn't fix security stuff, it doesn't really fix
major oopses."
https://lore.kernel.org/lkml/CA+55aFyvW38WU93CqegHiKt-ReO8yNfAOUGZRFGY3-Aq0UsETw@mail.gmail.com/

"No, I definitely don't want anything now unless it's a major
regression or security issue. Other stuff can wait until the merge
window and perhaps be marked for stable if required. That way they'll
get testing."
https://lore.kernel.org/lkml/CA+55aFyWcdmy3ACAWmRq70kQDpJ3bkjv1nROd1Gvab1Aa-GHqA@mail.gmail.com/

Linux seems to be flexible around that as he also pulls several fixes
which were broken before.


> This strikes me as odd, most fixes we merge are for previous releases.
> In fact when I write -rc pull requests to Linus I break them down by
> current release vs previous - and he never complained.

True, I noticed it. Maybe the rule is much less stricter than I
understood it.

> 
>> The issue here was introduced long time ago, not in current merge
>> window, however it is still an issue to fix. It's still a bug which
>> should have a commit with "Fixes" for all the stable tress and
>> downstream distros relying on stable kernels. Also for some statistics
>> on LWN.
> 
> Stable will not pull the commit from net-next, tho. Stable is more
> restrictive than rc (or at least so I think) so "we want it in stable,
> please merge it to net-next" does not compute with the preconceptions 
> I have.

There is no single need for stable to pull the commit from net-next. The
net-next commits will reach the Linus' tree sometime in the future (next
merge window) and then it will go to stable. That's the process. No need
to push such fix earlier, in a rush, for something broken long time ago
and not being a significant regression or bug.


Best regards,
Krzysztof

Powered by blists - more mailing lists