On Fri, Oct 06, 2023 at 12:40:36PM -0700, Maciej Żenczykowski wrote:
Was this rejected? Any resolution on this (ACK or NAK) would be useful. Thanks!
They are in our "to get to" queue, which is very long still due to multiple conferences and travel.
But I will note, you didn't put the git id of the patches in the patches themselves, so it will take me extra work to add them there when applying.
Also, why just 6.1? What about newer stable kernels? You can't update and have a regression, right?
Note, because of this, we can not take these patches now at all anyway :(
Because without any knowledge of whether these patches would even be accepted into stable, or whether they would need to go in via ACK, preparing them for more trees seemed like pointless busywork...
FWIW, the above just means that we get to do the busywork rather than the submitter...
We're certainly willing to do the work, but we're not entirely sure what you want, and whether you will indeed even accept these patches... We're just trying to be mindful of everyone's time...
For example as a reviewer myself I know that in many cases it is simply easier to do the clean (!) cherrypick yourself (you presumably have scripts that automate the entire thing), rather than try to verify that someone else's cherrypick is actually indeed clean.
These patches cleanly cherry pick, build, and pass our tests on current 6.5 and 6.1 LTS.
git checkout remotes/linux-stable/v6.5.6 && git cherry-pick 1671bcfd76fdc0b9e65153cf759153083755fe4c && git cherry-pick 5027d54a9c30bc7ec808360378e2b4753f053f25 && git cherry-pick 5cb249686e67dbef3ffe53887fa725eefc5a7144 && run_uml_ack_net_test
(and same thing with 6.1.56)
Do you simply want the upstream sha1s?
For things that cherry-pick cleanly, yes, that's easiest.
Or do you want us to follow up with patches?
For kernels that cherry-picking does not apply cleanly, yes.
thanks,
greg k-h