On Tue, 2017-08-01 at 12:14 -0500, Chien Tin Tung wrote: > On Tue, Aug 01, 2017 at 04:55:09PM +0000, Bart Van Assche wrote: > > Yes, I had read these e-mails but I do not agree with all of what was written > > in these e-mails. I'm not sure whether you are aware of the original design > > goal of the netlink mechanism? It was designed on purpose to be unreliable > > such that sending information from the kernel to user space would never block. > > Please show me a feference to Netlink design document/email on mailing list > that specifically disallowed this? As you probably know kernel developers do not write design documents. But there is plenty of evidence on the web that the netlink mechanism was designed to be unreliable. A quote from a Linux Journal article from 2005 (http://www.linuxjournal.com/article/7356): "Netlink is asynchronous because, as with any other socket API, it provides a socket queue to smooth the burst of messages." >From LWN.net article from 2005 (https://lwn.net/Articles/131802/): "netlink is an unreliable service". >From RFC 3549, co-authored by Alexey Kuznetsov, one of the netlink authors (https://tools.ietf.org/html/rfc3549): "By default, however, Netlink provides an unreliable communication." >From the netlink man page (http://man7.org/linux/man-pages/man7/netlink.7.html): "However, reliable transmissions from kernel to user are impossible in any case. 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." 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
