> On 03/28/14 06:50, [email protected] wrote: > > + while ((len = recv(sock, buffer, NL_MSG_BUF_SIZE, 0)) > 0) { > > + nlh = (struct nlmsghdr *)buffer; > > + while ((NLMSG_OK(nlh, len)) && (nlh->nlmsg_type != > NLMSG_DONE)) { > > + struct ifaddrmsg *ifa = (struct ifaddrmsg *) > NLMSG_DATA(nlh); > > + struct ifinfomsg *ifi = (struct ifinfomsg *) > NLMSG_DATA(nlh); > > + struct rtattr *rth = IFA_RTA(ifa); > > + int rtl = IFA_PAYLOAD(nlh); > > + > > + switch (nlh->nlmsg_type) { > > + [ ... ] > > + nlh = NLMSG_NEXT(nlh, len); > > + } > > + } > > Is there any reason why this code doesn't handle netlink buffer overflows > (ENOBUFS) ? From the netlink(7) man page:
No reason other than my inexperience with netlink. > > Netlink is not a reliable protocol. [ ... ] The kernel can't send a netlink > message if the socket buffer is full: the message will be dropped and the > kernel and the user-space process will no longer have the same view of > kernel state. It is up to the application to detect when this happens (via the > ENOBUFS error returned by recvmsg(2)) and resynchronize. Thanks, I'll rework the patch to account for this. Maybe by that time I will have Intel's email figured out... Thanks, Ira > > Bart. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
