On 5/27/26 4:45 PM, Reuven Plevinsky via dev wrote:
> The kernel datapath cannot hold ports whose names are IFNAMSIZ bytes
> or longer, so dpif_netlink_port_query_by_name() can never find them.
>
> During restart the ofproto construct path calls dpif_port_exists() for
> every configured interface. For ports with long names (for example
> patch ports) this reached the kernel, which returned an error that was
> logged as a spurious "failed to query port <long_port_name>: Invalid
> argument" warning.
>
> Return ENODEV early when the name is too long, avoiding the round-trip
> and the misleading log message.
>
> Fixes: c19e653509de ("datapath: Change userspace vport interface to use
> Netlink attributes.")
> Signed-off-by: Reuven Plevinsky <[email protected]>
> ---
> lib/dpif-netlink.c | 4 ++++
> tests/system-interface.at | 24 ++++++++++++++++++++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/lib/dpif-netlink.c b/lib/dpif-netlink.c
> index 2bf7e7cf27c1..5aa99dbe0efa 100644
> --- a/lib/dpif-netlink.c
> +++ b/lib/dpif-netlink.c
> @@ -1130,6 +1130,10 @@ dpif_netlink_port_query_by_name(const struct dpif
> *dpif_, const char *devname,
> {
> struct dpif_netlink *dpif = dpif_netlink_cast(dpif_);
>
> + if (strlen(devname) >= IFNAMSIZ) {
> + return ENODEV;
> + }
> +
Hi, Reuven. Thanks for the update. The test looks fine now.
I was thinking more abut the issue and the problem is not actually in
dpif-netlink. The problem is that patch port is being looked up in
dpif-netlink in the first place.
dpif-netlink doesn't actually have a limit for the interface name. The
limit is in the netdev-linux and the Linux kernel. dpif-netlink is not
tied to Linux kernel or a particular implementation of the openvswitch
kernel module. For example, until very recently we had Windows datapath
handled though the same dpif-netlink interface, and Windows driver had
255 as a limit.
Also, if the name is shorter but happens to collide with a name of some
existing interface in the kernel, the ofproto layer may be confused.
So, we need a fix there. One option might be to store the port type in
the iface_hints and skip dpif query for ports that ofproto-dpif
implements on its own, i.e. patch ports. With tunnel ports it's a bit
more complicated as dpif may implement them directly or through the
shared tunnel device, so we'd need to keep querying those for now.
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
