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
signature.asc
Description: OpenPGP digital signature