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@kylinos.cn
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@vger.kernel.org Signed-off-by: Geliang Tang tanggeliang@kylinos.cn Reviewed-by: Mat Martineau martineau@kernel.org Signed-off-by: Matthieu Baerts (NGI0) matttbe@kernel.org Signed-off-by: David S. Miller davem@davemloft.net (cherry picked from commit 584f3894262634596532cf43a5e782e34a0ce374) Signed-off-by: Matthieu Baerts (NGI0) matttbe@kernel.org
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