From: John Fastabend <john.fastab...@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.fastab...@gmail.com> Acked-by: David S. Miller <da...@davemloft.net>
