On 27/02/2024 14:01, Greg KH wrote:
> On Tue, Feb 27, 2024 at 12:04:22PM +0100, Matthieu Baerts wrote:
>> Hi Greg,
>>
>> On 27/02/2024 11:22, Greg KH wrote:
>>> On Mon, Feb 26, 2024 at 10:56:21PM +0100, Matthieu Baerts (NGI0) wrote:
>>>> From: Geliang Tang <tanggeliang@xxxxxxxxxx>
>>>>
>>>> Just the same as userspace PM, a new parameter needs_id is added for
>>>> in-kernel PM mptcp_pm_nl_append_new_local_addr() too.
>>>>
>>>> Add a new helper mptcp_pm_has_addr_attr_id() to check whether an address
>>>> ID is set from PM or not.
>>>>
>>>> In mptcp_pm_nl_get_local_id(), needs_id is always true, but in
>>>> mptcp_pm_nl_add_addr_doit(), pass mptcp_pm_has_addr_attr_id() to
>>>> needs_it.
>>>>
>>>> Fixes: efd5a4c04e18 ("mptcp: add the address ID assignment bitmap")
>>>> Cc: stable@xxxxxxxxxxxxxxx
>>>> Signed-off-by: Geliang Tang <tanggeliang@xxxxxxxxxx>
>>>> Reviewed-by: Mat Martineau <martineau@xxxxxxxxxx>
>>>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@xxxxxxxxxx>
>>>> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
>>>> (cherry picked from commit 584f3894262634596532cf43a5e782e34a0ce374)
>>>> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@xxxxxxxxxx>
>>>> ---
>>>> Notes:
>>>> - conflicts in pm_netlink.c because the new helper function expected to
>>>> be on top of mptcp_pm_nl_add_addr_doit() which has been recently
>>>> renamed in commit 1e07938e29c5 ("net: mptcp: rename netlink handlers
>>>> to mptcp_pm_nl_<blah>_{doit,dumpit}").
>>>> - use mptcp_pm_addr_policy instead of mptcp_pm_address_nl_policy, the
>>>> new name after commit 1d0507f46843 ("net: mptcp: convert netlink from
>>>> small_ops to ops").
>>>> ---
>>>> net/mptcp/pm_netlink.c | 24 +++++++++++++++++++-----
>>>> 1 file changed, 19 insertions(+), 5 deletions(-)
>>>
>>> Don't we also need a 5.15.y version of this commit?
>>
>> Good point, yes, according to the 'Fixes' tag, we need it as well for
>> 5.15.y.
>>
>> It looks like no "FAILED: patch" notification has been sent for this
>> patch for the 5.15-stable tree. Is it normal?
>
> Hm, odd, I don't know why I didn't send that out, that's a fault on my
> side, sorry about that.
>
> So yes, we do need this, I've just now sent the email if you trigger off
> of that :)
All good, it happens! :)
I will check that one later. I'm currently tracking one (or two?)
regression(s) in v6.1. It looks like they were already present in the
last v6.1 tag (v6.1.79). Patches will follow.
>> I'm asking this because I rely on these notifications to know if I need
>> to help to fix conflicts. I don't regularly track if patches we sent
>> upstream with 'Cc: stable' & 'Fixes' tags have been backported. It is
>> just to know if we need to modify our way of working :)
>
> No, your way of working is WONDERFUL from my side at least, I have no
> complaints at all!
Great! We will then continue to track 'FAILED: patch' notifications, and
rely on your excellent work selecting all patches that need to be
backported.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
