netdev - Re: [PATCH 0/3] net: time stamping fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1319031348.1286.4.camel@jlt3.sipsolutions.net>
Date:	Wed, 19 Oct 2011 15:35:48 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Richard Cochran <richardcochran@...il.com>,
	David Miller <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 0/3] net: time stamping fixes

On Wed, 2011-10-19 at 15:25 +0200, Eric Dumazet wrote:

> > Given the complexity of all this, I'm not sure we shouldn't do something
> > like this, but I have no idea what the cost would be:
> > 
> > --- wireless-testing.orig/include/net/sock.h	2011-10-18 22:28:41.000000000 +0200
> > +++ wireless-testing/include/net/sock.h	2011-10-19 15:08:45.000000000 +0200
> > @@ -434,7 +434,10 @@ static __inline__ int __sk_del_node_init
> >  
> >  static inline void sock_hold(struct sock *sk)
> >  {
> > -	atomic_inc(&sk->sk_refcnt);
> > +	if (atomic_inc_return(&sk->sk_refcnt) == 1) {
> > +		/* was zero -- we must've gotten an sk_wmem_alloc reference */
> > +		atomic_inc(&sk->sk_wmem_alloc);
> > +	}
> >  }
> >  
> 
> Hmm, it will be difficult to handle two atomics without adding races,

Where do you see a race? If you do sock_hold() while you have a 'proper
sk_refcnt reference', this does nothing but increase sk_refcnt. If you
do sock_hold() while you have an 'sk_wmem_alloc reference', this will
actually increase sk_wmem_alloc by 1; then when the original
'sk_wmem_alloc reference' you had when calling sock_hold() is released,
sk_wmem_alloc will still have 1 matching a non-zero sk_refcnt.


> and add quite expensive atomic_inc_return() on some arches.

Yes I was afraid of that.

> I would just change the skb tx cloning to take a normal reference on
> sk_wmem_alloc
> 
> 	atomic_add(skb->truesize, &sk->sk_wmem_alloc);
> instead of
> 	sock_hold(sk);

Even with that fixed I'm not really convinced of it all -- need to
really really really make sure that no skb->sk that was owned by a TX
skb is ever passed to sock_hold(). Can we really guarantee that?

johannes

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html