On Wed, 2017-08-02 at 10:45 -0600, Jason Gunthorpe wrote: > No, I disagree.. It is pretty clear how iwpm works, it it pushes > unsolicted messaged directly to the userspace daemon from the kernel > and expects the daemon to receive those messages. > > With such a scheme it is really important for the kernel to do > everything it can to minimize the risk of message loss, and using the > blocking sending for unsolicited messages is certainly part of it - > that is what audit does for instance. > > The discussion really got into the weeds when people brought up > O_NONBLOCK or ENOBUFS, or any other user space change as that has > nothing to do with pushing unsolicited messages from the kernel to > userspace. > > Arguing that is a 'protocol bug' doesn't make much sense, the protocol > is a uAPI, so it is up to the kernel to provide the best > implementation possible, which in this case means working to minimize > loss of the messages.. > > Noting again, that this is *ONLY* talking about the unsolicted > messages the iwpm sends toward userspace. IMHO, use of blocking send > in other contexts, such as dump callbacks, is an error. Hello Jason, Although I do not object against the "RDMA/core: Add wait/retry version of ibnl_unicast" patch, I hope that you realize that it is an ugly hack instead of a proper fix. Anything that makes user space wait longer than the socket timeout, e.g. heavy swapping activity or running the user space software under a debugger, will cause delivery of the netlink message from kernel to user to fail anyway. 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
