diff options
author | Stefano Brivio <sbrivio@redhat.com> | 2023-03-08 03:43:25 +0100 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2023-03-09 03:44:21 +0100 |
commit | fde8004ab0b4c948cec5462b1c64ced824551cbe (patch) | |
tree | 8ad074dcea57483c1089a8b3be56e43441ed195c /tcp_splice.c | |
parent | a9c59dd91baa6315259328fc0e36ac63a61ab24b (diff) | |
download | passt-fde8004ab0b4c948cec5462b1c64ced824551cbe.tar passt-fde8004ab0b4c948cec5462b1c64ced824551cbe.tar.gz passt-fde8004ab0b4c948cec5462b1c64ced824551cbe.tar.bz2 passt-fde8004ab0b4c948cec5462b1c64ced824551cbe.tar.lz passt-fde8004ab0b4c948cec5462b1c64ced824551cbe.tar.xz passt-fde8004ab0b4c948cec5462b1c64ced824551cbe.tar.zst passt-fde8004ab0b4c948cec5462b1c64ced824551cbe.zip |
netlink: Use 8 KiB * netlink message header size as response buffer
...instead of BUFSIZ. On musl, BUFSIZ is 1024, so we'll typically
truncate the response to the request we send in nl_link(). It's
usually 8192 or more with glibc.
There doesn't seem to be any macro defining the rtnetlink maximum
message size, and iproute2 just hardcodes 1024 * 1024 for the receive
buffer, but the example in netlink(7) makes somewhat sense, looking
at the kernel implementation.
It's not very clean, but we're very unlikely to hit that limit,
and if we do, we'll find out painlessly, because NLA_OK() will tell
us right away.
Reported-by: Chris Kuhn <kuhnchris+passt@kuhnchris.eu>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Diffstat (limited to 'tcp_splice.c')
0 files changed, 0 insertions, 0 deletions