Comment 30 for bug 1720126

On 20.10.2017 [07:09:00 -0000], Jan Gutter wrote:
> I concur with option 2), unnecessary deviation will just cause
> confusion.

Thank you for confirming that!

> Regarding the other buffer sizes, the last time I looked they were
> mostly OK. The issue reared its head in this particular case because the
> netlink message that previously had a pretty constant per-netdev
> response size suddenly had the ability to balloon with "no warning". A
> number of workarounds exist (i.e. you have to explicitly ask for the VF
> info), but, in this case we actually want the VF info and iproute2 was
> just unprepared for the size of it.

Ok, that's good to hear.

> I guess the core issue is that it's entirely possible for the kernel to
> add extra netlink attributes to any query response, iproute2 makes the
> assumption that the queries it's making is not necessarily going to
> explode with gigabytes of new annotations and 16k will easily fit any
> current real-world system. A pragmatic approach would probably be to
> handle the "Message Truncated" path with a dynamically sized buffer as
> an exceptional case.

Yep, I can see how iproute2 itself has to move in lockstep with the
kernel, which also means older iproute2 that can run on newer kernels
needs periodic updates like this one.

> Any fix in iproute2 that "properly" addresses this issue has to be
> carefully vetted. Who knows how many inherent races will get exposed if
> the ip command doubles in execution time.

Yep :) I'm fine with eventually doubling the buffer again statically if
that is the conclusion upstream reaches. My guess is that is the
simplest solution.