Re: [Xenomai] rtnet locking/socket SKBs

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Sun, Sep 27, 2015 at 11:32:36PM +0200, Gilles Chanteperdrix wrote:
> On Thu, Jun 04, 2015 at 12:41:47PM +0200, Marc Strämke wrote:
> > Am Mittwoch, 3. Juni 2015, 19:09:36 schrieb Marc Strämke:
> > > How is the reference count maintained for the rtdm devices, is that the
> > > refcount in the rtdm_fd structure (fd->refs). There is also a driver
> > > refcount, I am actually somewhat confused how this is maintained...
> > 
> > So I got mostly down to the issue but I need some input from someone more 
> > knowledged in rtnets design: 
> > The reference count of an open AF_PACKET socket is not dropping to zero 
> > because there are still skb in the sockets skb pool and 
> > rtskb_socket_pool_trylock increments the fds reference 
> > count. rt_socket_cleanup would release the skb pool but never gets called.
> > 
> > What I do not really understand at this moment is why the fd reference count 
> > gets incremented at all when the socket gets a skb in its pool? 
> > Is there any reason to not close a socket while it still has associated skbs 
> > in the pool? They will never get cleared if the application crashes If I am 
> > not mistaken.
> 
> Ok, so now I had a look at the issue. The counter is not dropping to
> zero probably because you have unqueued messages in the socket
> "incoming" queue, the pool is locked when a packet is out of the
> pool, not when a packet is in the pool.
> 
> Anyway, you are right, this is redundant, but not only for
> af_packet, also for udp and tcp: when the packet is outside any pool
> or queue, the file descriptor is locked, so, the module can not be
> removed and leak can not occur, so there is no reason to keep track
> of the fact that it is outside any queue, and we can probably remove
> the locking in the socket pools.
> 
> What may be missing is that creating sockets should lock the
> corresponding kernel module.

The issue should now be fixed in the xenomai-gch git, branch for-forge.

-- 
					    Gilles.
https://click-hack.org