Re: [bpf-next PATCH 02/16] sockmap: convert refcnt to an atomic refcnt

[David Miller <davem@davemloft.net>]

From: John Fastabend <john.fastabend@gmail.com>
Date: Mon, 05 Mar 2018 11:51:06 -0800

> The sockmap refcnt up until now has been wrapped in the
> sk_callback_lock(). So its not actually needed any locking of its
> own. The counter itself tracks the lifetime of the psock object.
> Sockets in a sockmap have a lifetime that is independent of the
> map they are part of. This is possible because a single socket may
> be in multiple maps. When this happens we can only release the
> psock data associated with the socket when the refcnt reaches
> zero. There are three possible delete sock reference decrement
> paths first through the normal sockmap process, the user deletes
> the socket from the map. Second the map is removed and all sockets
> in the map are removed, delete path is similar to case 1. The third
> case is an asyncronous socket event such as a closing the socket. The
> last case handles removing sockets that are no longer available.
> For completeness, although inc does not pose any problems in this
> patch series, the inc case only happens when a psock is added to a
> map.
> 
> Next we plan to add another socket prog type to handle policy and
> monitoring on the TX path. When we do this however we will need to
> keep a reference count open across the sendmsg/sendpage call and
> holding the sk_callback_lock() here (on every send) seems less than
> ideal, also it may sleep in cases where we hit memory pressure.
> Instead of dealing with these issues in some clever way simply make
> the reference counting a refcnt_t type and do proper atomic ops.
> 
> Signed-off-by: John Fastabend <john.fastabend@gmail.com>

Acked-by: David S. Miller <davem@davemloft.net>