> On 03/28/14 06:50, sean.hefty@xxxxxxxxx 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
