[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <155ba7e5-2344-f868-73cf-f43169b841a9@gmail.com>
Date: Mon, 18 Jan 2021 10:49:26 -0700
From: David Ahern <dsahern@...il.com>
To: Edwin Peer <edwin.peer@...adcom.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
Michal Kubecek <mkubecek@...e.cz>,
netdev <netdev@...r.kernel.org>,
Stephen Hemminger <stephen@...workplumber.org>,
Andrew Gospodarek <andrew.gospodarek@...adcom.com>,
Michael Chan <michael.chan@...adcom.com>
Subject: Re: [PATCH iproute2] iplink: work around rtattr length limits for
IFLA_VFINFO_LIST
On 1/18/21 10:42 AM, Edwin Peer wrote:
> On Mon, Jan 18, 2021 at 9:36 AM David Ahern <dsahern@...il.com> wrote:
>
>>> Assuming we fix nla_nest_end() and error in some way, how does that
>>> assist iproute2?
>>
>> I don't follow. The kernel is sending a malformed message; userspace
>> should not be guessing at how to interpret it.
>
> The user isn't going to care about this technicality. If the kernel
> errors out here, then the user sees zero VFs when adding one more VF.
> That's still a bug, even though the malformed message is fixed. An API
> bug is still a bug, except we seemingly can't fix it because it's
> deprecated.
>
Different bug, different solution required. The networking stack hits
these kind of scalability problems from time to time with original
uapis, so workarounds are needed. One example is rtmsg which only allows
255 routing tables, so RTA_TABLE attribute was added as a u32. Once a
solution is found for the VF problem, iproute2 can be enhanced to
accommodate.
Powered by blists - more mailing lists