On Wed, 2020-11-25 at 21:48 +0000, Othman, Ossama wrote:
While debugging a netlink PM "get addr" issue I was having in mptcpd
I found that the address ID assigned by mptcpd was being overridden
by the kernel. Based on the code in pm_nl_ctl.c in the MPTCP self
tests, and the code in pm_netlink.c in the kernel, the
MPTCP_PM_CMD_ADD_ADDR command accepts an optional address ID
attribute. When that attribute is available the ID is stored in the
corresponding mptcp_pm_addr_entry instance by mptcp_pm_parse_addr():
entry->addr.id = nla_get_u8(tb[MPTCP_PM_ADDR_ATTR_ID]);
However, that value is later overridden in mptcp_pm_nl_append_new_local_addr():
entry->addr.id = pernet->next_id++;
That causes the userspace to lose track of an address it added with a
specific ID, at which point the only way to find out the new ID is to
dump the addrs to find the new ID corresponding to local address in
question. Is this the intended behavior?
This is indended. In the current status 'id' is used only for endpoint
selection while dumping (IIRC).
The 'id' override allows for very easy book-keeping on the kernel side,
otherwise we would need something more complex (alike IDR) to keep
track of IDs usage.
It seems like userspace- and kernel-based address ID assignment
should be mutually exclusive. Otherwise we run into this sort of
scenario. Is there a need for the kernel to assign IDs in the
netlink PM case?
Not really, it was just to keep the kernel-side implementation easy.
Since need arise, we can as well swap to a more complete/complex
I just filed:
for that. Any volonteer willing to pick the task more than welcome!