On 09/25/2013 11:09 AM, Cyril Brulebois wrote:
>> --- ifmetric-0.3.orig/src/nlrequest.c
>> +++ ifmetric-0.3/src/nlrequest.c
>> @@ -44,7 +44,7 @@
>>
>> for (;;) {
>> int bytes;
>> - char replybuf[2048];
>> + char replybuf[4096];
>> struct nlmsghdr *p = (struct nlmsghdr *) replybuf;
>>
>> if ((bytes = recv(s, &replybuf, sizeof(replybuf), 0)) < 0) {
>
> Is it certain 4096 is enough, or will we hit this again in the future?
tl;dr - yes, and perhaps some day. :)
Changes to the netlink API certainly could happen in future kernel
versions, increasing the reply size, which may affect Jessie/Sid, but I
believe that 4096 should be sufficient for Wheezy, as well as
testing/unstable, until such time that it is not.
While I have not gone through bisecting the kernel itself to determine
specific netlink reply sizes since the last upload of ifmetric (17 Jan
2006), I did find some interesting details and a relevant example in
netlink(7). I believe that one of feature additions in the VERSIONS
section of netlink(7) bumped a typical reply beyond 2048 around the
Squeeze kernel version (which is when I started maintaining my own
patched ifmetric package for several large production clusters), for
example:
NETLINK_INET_DIAG, NETLINK_CONNECTOR and NETLINK_NETFILTER appeared in
Linux 2.6.14.
NETLINK_GENERIC and NETLINK_ISCSI appeared in Linux 2.6.15.
The last EXAMPLE in netlink(7) is spot on and is perhaps where the
initial patch submitter found the relevant 4096 value (which is the
current suggestion in the man-pages git repository [0]). This example
was added to netlink(7) in commit 8482c7 (Mar 7 2006):
And the last example is about reading netlink message.
int len;
char buf[4096];
struct iovec iov = { buf, sizeof(buf) };
struct sockaddr_nl sa;
struct msghdr msg;
struct nlmsghdr *nh;
msg = { &sa, sizeof(sa), &iov, 1, NULL, 0, 0 };
len = recvmsg(fd, &msg, 0);
for (nh = (struct nlmsghdr *) buf; NLMSG_OK (nh, len);
nh = NLMSG_NEXT (nh, len)) {
/* The end of multipart message. */
if (nh->nlmsg_type == NLMSG_DONE)
return;
if (nh->nlmsg_type == NLMSG_ERROR)
/* Do some error handling. */
...
/* Continue with parsing payload. */
...
}
The above example leads me to believe this buffer size should be
sufficient for the foreseeable future, and certainly for Wheezy kernels.
> Anyway, the stable diff looks sane enough (especially given the diff
> between 0.3-2 and 0.3-3 ;)).
I appreciate your time looking into this update!
[0] http://git.kernel.org/pub/scm/docs/man-pages/man-pages
--
Kind regards,
Michael Shuler
Attachment:
signature.asc
Description: OpenPGP digital signature