On Mon, Jan 18, 2021 at 10:20:35AM -0800, Edwin Peer wrote:
> On Mon, Jan 18, 2021 at 9:49 AM David Ahern wrote:
>
> > 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.
On Mon, Jan 18, 2021 at 9:49 AM David Ahern wrote:
> 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_T
On Sun, Jan 17, 2021 at 7:48 PM David Ahern wrote:
> IMHO this is a kernel bug that should be fixed. An easy fix to check the
> overflow in nla_nest_end and return an error. Sadly, nla_nest_end return
> code is ignored and backporting any change to fix that will be
> nightmare. A warning will ide
On 1/18/21 10:42 AM, Edwin Peer wrote:
> On Mon, Jan 18, 2021 at 9:36 AM David Ahern 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
On Mon, Jan 18, 2021 at 9:36 AM David Ahern 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 a
On 1/18/21 10:34 AM, Edwin Peer wrote:
> On Sun, Jan 17, 2021 at 7:48 PM David Ahern wrote:
>
>> IMHO this is a kernel bug that should be fixed. An easy fix to check the
>> overflow in nla_nest_end and return an error. Sadly, nla_nest_end return
>> code is ignored and backporting any change to fi
On Sat, Jan 16, 2021 at 1:12 PM Michal Kubecek wrote:
> My idea back then was to use a separate query which would allow getting
> VF information using a dump request (one VF per message); the reply for
> RTM_GETLINK request would either list all VFs as now if possible or only
> as many as fit in
On Sat, Jan 16, 2021 at 5:21 PM Jakub Kicinski wrote:
> I wonder. There is something inherently risky about making
> a precedent for user space depending on invalid kernel output.
In this instance, it's not depending on the invalid output at all.
Rather, the patch depends on a different and vali
On 1/16/21 6:21 PM, Jakub Kicinski wrote:
>
> I wonder. There is something inherently risky about making
> a precedent for user space depending on invalid kernel output.
>
> _If_ we want to fix the kernel, IMO we should only fix the kernel.
>
IMHO this is a kernel bug that should be fixed. An e
On Sat, 16 Jan 2021 22:12:23 +0100 Michal Kubecek wrote:
> On Fri, Jan 15, 2021 at 03:53:25PM -0800, Jakub Kicinski wrote:
> > On Fri, 15 Jan 2021 14:59:50 -0800 Edwin Peer wrote:
> > > The maximum possible length of an RTNL attribute is 64KB, but the
> > > nested VFINFO list exceeds this for mor
On Fri, Jan 15, 2021 at 03:53:25PM -0800, Jakub Kicinski wrote:
> On Fri, 15 Jan 2021 14:59:50 -0800 Edwin Peer wrote:
> > The maximum possible length of an RTNL attribute is 64KB, but the
> > nested VFINFO list exceeds this for more than about 220 VFs (each VF
> > consumes approximately 300 bytes,
The maximum possible length of an RTNL attribute is 64KB, but the
nested VFINFO list exceeds this for more than about 220 VFs (each VF
consumes approximately 300 bytes, depending on alignment and optional
fields). Exceeding the limit causes IFLA_VFINFO_LIST's length to wrap
modulo 16 bits in the ke
On Fri, 15 Jan 2021 14:59:50 -0800 Edwin Peer wrote:
> The maximum possible length of an RTNL attribute is 64KB, but the
> nested VFINFO list exceeds this for more than about 220 VFs (each VF
> consumes approximately 300 bytes, depending on alignment and optional
> fields). Exceeding the limit caus
13 matches
Mail list logo
