Re: [PATCH net v3] mptcp: pm: drop pending ADD_ADDR when removing id 0 endpoint

[Tao Cui <cui.tao@linux.dev>]

From: Tao Cui <cuitao@kylinos.cn>

Hi Kalpan,

First of all, thanks for this patch!

While playing with it on top of the current tree, I think I may have
bumped into a small detail, and I just wanted to mention it in case it
is useful — please do correct me if I got any of this wrong.

After the "mptcp: pm: uniform announced addresses helpers" refactor
(7d4dacc8ccca), the helper became mptcp_pm_announced_remove(), and its
lookup uses mptcp_addresses_equal(..., /* use_port = */ true). A pending
ADD_ADDR entry coming from a signal endpoint added without a port
(`ip mptcp endpoint add ADDR signal`) is keyed with port 1, while
msk_local carries the connection's local port. With a listener on port
5000, a temporary printk in the id 0 path shows:

    msk_local.port = 5000
    announced(port0_lookup) = 1

So, at least in this configuration, passing msk_local directly does not
match the entry: the stale entry survives, and the WARN still shows up
on the next reselection. It only goes away when the port is ignored
during the lookup.

If that matches what you see, the smallest change that keeps the v3
shape would be to clear the port before the lookup, something like:

        struct mptcp_addr_info anno_addr = msk_local;

        anno_addr.port = 0;
        announced = mptcp_pm_announced_remove(msk, &anno_addr);

(An address-only variant of the lookup might be a touch cleaner, since a
signal entry never carries the connection port — but the one-liner above
is enough to fix the case I reproduced.)

I have a small repro that triggers it deterministically if it would help
— happy to share.

Thanks again for looking into this, and sorry for the noise if I'm
missing something obvious here.

Cheers,
Tao