Thread (13 messages) 13 messages, 3 authors, 2021-09-27

Re: [PATCH net] nfc: avoid potential race condition

From: Krzysztof Kozlowski <hidden>
Date: 2021-09-27 14:58:55
Also in: kernel-janitors

On 27/09/2021 16:26, Jakub Kicinski wrote:
On Mon, 27 Sep 2021 09:44:08 +0200 Krzysztof Kozlowski wrote:
quoted
On 24/09/2021 22:14, Jakub Kicinski wrote:
quoted
On Fri, 24 Sep 2021 10:21:33 +0200 Krzysztof Kozlowski wrote:  
quoted
Indeed. The code looks reasonable, though, so even if race is not really
reproducible:

Reviewed-by: Krzysztof Kozlowski <redacted>  
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/ (local)

"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/ (local)

"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/ (local)

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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help