On Sat, Mar 13, 2021 at 08:51:31PM +0200, Vladimir Oltean wrote:
On Sat, Mar 13, 2021 at 11:10:57AM -0500, Sasha Levin wrote:
But the question surprises me. I thought the M.O. is that somebody
should explain _why_ a commit should go to a stable tree, not why it
shouldn't. I notice now that most, if not all, of that series ended up in
linux-5.10.y, which I most definitely did not expect. It's not that it
will do any harm there, but more like I feel that we as maintainers
don't have any sort of control over what a stable kernel becomes over
time; we think we left it in a certain state and we see it change unexpectedly.
The thought process when sending a patch to David Miller's "net" tree vs
"net-next" is different - you know that what you send to "net-next" only
needs to work on the current tree, whereas for "net" you want to be as
compatible as possible with code that existed in past releases. The fact
that you need to watch your back for stuff sent to net-next is unpleasant.
Now I'll have to go give linux-5.10.y a run and see if everything is ok
there.
But in the end commits end up in the same spot in Linus's tree, so we
don't have a way to tell which tree they went through.
Either way, in this case the commit was picked as a dependency rather
than a fix on it's own.
This patch (and a few other dependencies) were queued up to get
9200f515c41f ("net: dsa: tag_mtk: fix 802.1ad VLAN egress") in 5.10.
Commit a3b0b6479700 ("net: dsa: implement a central TX reallocation
procedure") is not a logical dependency of commit 9200f515c41f ("net:
We try to avoid modifying patches that we backport, even if it means
bringing in depdendencies that aren't logical dependencies as long as
it's reasonable.
We resort to modifying patches only if the above means we'll bring in an
overly invasive change.
dsa: tag_mtk: fix 802.1ad VLAN egress"). If for some reason it did not
apply cleanly without any patch from the DSA central realloc series, I
think the correct approach would have been to send an email stating
clearly that the bugfix patch does not apply to linux-5.10.y, and if the
This mail: https://lore.kernel.org/stable/1615551841172192@xxxxxxxxx/
Sadly, though, most of Greg's mails regarding failed patches end up
being ignored so it falls back on us to try and do the backport. (note
I'm not saying that *you're* ignoring them, just in general that we've
had a low response rate to these so we end up doing backports
ourselved).
bugfix is important, whomever needs it (and can test it) can send an
explicit backport. At least that's what Greg does, and is a predictable
work flow that I can work with.
Why is this patch not appropriate for 5.10? Have I missed any other
dependency?
It's not _needed_, I don't mind having it per se, other than what I've
explained above.
I very much agree that we can avoid taking them by modifying
9200f515c41f ("net: dsa: tag_mtk: fix 802.1ad VLAN egress") to work
around not having this series, but in general we avoid doing so as it's
likely to introduce issues.
Stable trees try and stay as close as possible to upstream, we do that
by dealing with conflicts by taking missing upstream patches rather than
modifying them.
If there was any notice prior to this email that the patches from the
central DSA TX realloc series would get backported to linux-5.10.y, it
certainly passed me by, and if it turns out to be my fault, I'm sorry
for that.
Oh, so this is the notice. We're just discussing a patch that was
queued. It will still go out for a review as part of a release candidate
(at least one) before it goes in a released stable tree.
--
Thanks,
Sasha
