On 04/03/2024 11:58, Greg KH wrote: > On Mon, Mar 04, 2024 at 11:40:49AM +0100, Matthieu Baerts wrote: >> On 04/03/2024 11:32, Greg KH wrote: >>> On Mon, Mar 04, 2024 at 11:07:01AM +0100, Matthieu Baerts wrote: >>>> On 04/03/2024 09:30, gregkh@xxxxxxxxxxxxxxxxxxx wrote: >> >> (...) >> >>>>> ------------------ original commit in Linus's tree ------------------ >>>>> >>>>> From 7092dbee23282b6fcf1313fc64e2b92649ee16e8 Mon Sep 17 00:00:00 2001 >>>>> From: Geliang Tang <tanggeliang@xxxxxxxxxx> >>>>> Date: Fri, 23 Feb 2024 17:14:12 +0100 >>>>> Subject: [PATCH] selftests: mptcp: rm subflow with v4/v4mapped addr >>>>> >>>>> Now both a v4 address and a v4-mapped address are supported when >>>>> destroying a userspace pm subflow, this patch adds a second subflow >>>>> to "userspace pm add & remove address" test, and two subflows could >>>>> be removed two different ways, one with the v4mapped and one with v4. >>>> I don't think it is worth having this patch backported to v6.1: there >>>> are a lot of conflicts because this patch depends on many others. Also, >>>> many CIs validating stable trees will use the selftests from the last >>>> stable version, I suppose. So this new test will be validated on older >>>> versions. >>>> >>>> For v6.6 and v6.7, I can help to fix conflicts. I will just wait for the >>>> "queue/6.6" and "queue/6.7" branches to be updated with the latest >>>> patches :) >>> >>> Should all now be up to date, >> >> Maybe we are not talking about the same thing: are the "queue/X.Y" >> branches from the "linux-stable-rc" repo [1] not updated automatically >> when patches are added to the "stable-queue" repo [2]? > > Ah, that, yeah, it somehow automagically works, I have no idea how it > does it or what controls it or who uses it, sorry :) Ah, OK! :) I have to admit it is quite handy, not to have to apply the patches successfully added in the queue manually. But that's OK, I guess it will magically work again in the future. For now, I can apply these other patches manually, no problem! Cheers, Matt -- Sponsored by the NGI0 Core fund.
