On 23-06-17 11:26, Luca Coelho wrote:

From: Andrei Otcheretianski <redacted>

If NAN interface is created with NL80211_ATTR_SOCKET_OWNER, the socket
that is used to create the interface is used for all NAN operations and
reporting NAN events.
However, it turns out that sending commands and receiving events on
the same socket is not possible in a completely race-free way:
If the socket buffer is overflowed by the events, the command response
will not be sent. In that case the caller will block forever on recv.
Using non-blocking socket for commands is more complicated and still
the command response or ack may not be received.
So, keep unicasting NAN events to the interface creator, but allow
using a different socket for commands.

Sounds like this patch is missing significant changes in the
documentation of nl80211 API:

 * @NL80211_CMD_ADD_NAN_FUNCTION: Add a NAN function. The function is
defined
 *      with %NL80211_ATTR_NAN_FUNC nested attribute. When called, this
 *      operation returns the strictly positive and unique instance id
 *      (%NL80211_ATTR_NAN_FUNC_INST_ID) and a cookie (%NL80211_ATTR_COOKIE)
 *      of the function upon success.
 *      Since instance ID's can be re-used, this cookie is the right
 *      way to identify the function. This will avoid races when a
termination
 *      event is handled by the user space after it has already added a new
 *      function that got the same instance id from the kernel as the one
 *      which just terminated.
 *      This cookie may be used in NAN events even before the command
 *      returns, so userspace shouldn't process NAN events until it
processes
 *      the response to this command.
 *      Look at %NL80211_ATTR_SOCKET_OWNER as well.

/and/

 * @NL80211_ATTR_SOCKET_OWNER: Flag attribute, if set during interface

[...]

 *      If set during NAN interface creation, the interface will be
destroyed
 *      if the socket is closed just like any other interface. Moreover,
only
 *      the netlink socket that created the interface will be allowed to add
 *      and remove functions. NAN notifications will be sent in unicast
to that
 *      socket. Without this attribute, any socket can add functions and the
 *      notifications will be sent to the %NL80211_MCGRP_NAN multicast
group.

Also is this not a more fundamental flaw in netlink socket behavior.
Should there be some priority imposed on command responses over event
messages. Just seems like this patch is a workaround.

Regards,
Arend