Re: Netlink messages without NLM_F_REQUEST flag

On Wed, Jun 07, 2017 at 11:07:02AM -0600, Jason Gunthorpe wrote:

On Wed, Jun 07, 2017 at 08:00:37PM +0300, Leon Romanovsky wrote:

quoted

On Wed, Jun 07, 2017 at 10:47:50AM -0600, Jason Gunthorpe wrote:

quoted

On Wed, Jun 07, 2017 at 07:43:44PM +0300, Leon Romanovsky wrote:

quoted

On Wed, Jun 7, 2017 at 7:37 PM, Jason Gunthorpe
[off-list ref] wrote:

quoted

On Wed, Jun 07, 2017 at 07:19:01PM +0300, Leon Romanovsky wrote:

quoted

It makes me wonder if it is expected behavior for
ibnl_rcv_reply_skb() to handle !NLM_F_REQUEST messages and do we
really need it? What are the scenarios?  In my use case, which is
for sure different from yours, I'm always setting NLM_F_REQUEST
while communicating with kernel.

If I recall the user space SA code issues REQUESTS from the kernel to
userspace, so userspace returns with the response format. This is
abnormal for netlink hence the special function.

In netlink semantics, kernel side is supposed to send netlink
notification message and userspace is supposed to send REQUEST.

That pattern is for async communications, the SA stuff needs a sync
protocol, unfortunately.

There is special flag NLM_F_ACK for it and userspace will set
NLM_F_REQUEST | NLM_F_ACK once synchronization is needed.

AFAIK, that is different, that is acking and retriggering a single shot
notification, not completing a kernel initiated handshake.

It is acking that message from user was received by kernel and now
processing. The message from kernel to user are anyway unreliable [1],
so I don't understand on which handshake you are talking.

[1] "reliable transmissions from kernel to user are impossible in any case"
https://linux.die.net/man/7/netlink

Jason