On Wed, Oct 29, 2008 at 05:09:53PM +0100, Eric Dumazet wrote:

Corey Minyard a écrit :

quoted

Eric Dumazet wrote:

quoted

Corey Minyard found a race added in commit 
271b72c7fa82c2c7a795bc16896149933110672d
(udp: RCU handling for Unicast packets.)

"If the socket is moved from one list to another list in-between the time 
 the hash is calculated and the next field is accessed, and the socket  
has moved to the end of the new list, the traversal will not complete  
properly on the list it should have, since the socket will be on the end  
of the new list and there's not a way to tell it's on a new list and  
restart the list traversal.  I think that this can be solved by  
pre-fetching the "next" field (with proper barriers) before checking the  
hash."

This patch corrects this problem, introducing a new 
sk_for_each_rcu_safenext()
macro.

You also need the appropriate smp_wmb() in udp_lib_get_port() after 
sk_hash is set, I think, so the next field is guaranteed to be changed 
after the hash value is changed.

Not sure about this one Corey.

If a reader catches previous value of item->sk_hash, two cases are to be 
taken into :

1) its udp_hashfn(net, sk->sk_hash) is != hash   -> goto begin : Reader 
will redo its scan

2) its udp_hashfn(net, sk->sk_hash) is == hash
 -> next pointer is good enough : it points to next item in same hash 
chain.
    No need to rescan the chain at this point.
    Yes we could miss the fact that a new port was bound and this UDP 
message could be lost.

3) its udp_hashfn(net, sk-sk_hash) is == hash, but only because it was
removed, freed, reallocated, and then readded with the same hash value,
possibly carrying the reader to a new position in the same list.

You might well cover this (will examine your code in detail on my plane
flight starting about 20 hours from now), but thought I should point it
out.  ;-)

						Thanx, Paul

If we force a smp_wmb(), reader would fetch pointer to begin of list.


1) its udp_hashfn(net, sk->sk_hash) is != hash   -> goto begin : Reader 
will redo its scan : next pointer value had no meaning

2) its udp_hashfn(net, sk->sk_hash) is == hash
 ->next pointer "force reader" to rescan the chain, but wont find new 
items.

In any case, we cannot lost an UDP message sent to a stable port 
(previously bound)


Thanks

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