Re: [Xenomai] rtnet locking/socket SKBs

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

On Thu, Jun 04, 2015 at 02:35:18PM +0200, Marc Strämke wrote:
> Am Donnerstag, 4. Juni 2015, 13:31:00 schrieb Gilles Chanteperdrix:
> > On Thu, Jun 04, 2015 at 01:09:08PM +0200, Marc Strämke wrote:
> > > 
> > > Yes I do understand this. I am just trying to figure out what the right
> > > fix is. If I just disable incrementing the fd reference count (see
> > > attached patch) AF_PACKET works as it should.  From my current
> > > understanding of the code the reference counting for the SKB Pools
> > > attached to a socket is redundant, but I've only closely inspected
> > > AF_PACKET not the other sockets in the IP stack.
> > The locking of the pools is not redundant. The reason for this lock
> > is that when an skb is in between two pools, we do not want the pool
> > it comes from to be destroyed, as the skb would end-up leaking. So,
> Yes, that is obvious. But what these lock ops do is not locking for the 
> transient moment when the packet is moving between pools but for the time the 
> packet is in a pool. This locking ops insure that no whole skb pool is leaked.
> 
> If I look at rtskb_module_lock_ops this makes sense to me, one cannot unload 
> the module till all pools are empty. It left me wondering though if 
> try_module_get is safe to be called from a realtime context..

try_module_get is safe to be called from realtime context, starting
with the I-pipe patch for Linux 3.14.

-- 
					    Gilles.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: not available
URL: <http://xenomai.org/pipermail/xenomai/attachments/20150604/1416b9b0/attachment.sig>