Re: [rdma-next 01/33] Revert "IB/core: Add flow control to the portmapper netlink calls"

[Bart Van Assche <Bart.VanAssche-Sjgp3cTcYWE@public.gmane.org>]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html