[openib-general] [PATCH fixed] was Re: [PATCH] ipoib_multicast/ipoib_mcast_send race

[Michael S. Tsirkin]

Quoting r. Krishna Kumar2 <krkumar2 at in.ibm.com>:
> Isn't all that managed by clearing/testing the bit ? Because holding the
> lock doesn't solve 
> it.
> To give an example : 
> 
> stop_thread() 
> { 
>         lock(); 
>         clear(); 
>         unlock(); 
>         ... 
>         wait_for_completion(mcast); 
> } 
> 
> mcast_send() 
> { 
>         lock(); 
>         test(); 
>         results_in_creation_of_entries_done_etc();; 
>         unlock(); 
> } 
> 
> In this case, if mcast_send() gets the lock first and proceeds while the
> stop_thread is spinning 
> on the lock, the entries are created and then the stop_thread() clears
> the bit and at this point 
> in time, no more entries can be ever created. Now if the lock were
> removed, the behavior 
> is identical - the mcast_send() would test the bit, and get the lock()
> while the stop_thread() 
> clears the bit (without a lock) and waits for completion, while *no
> more* mcast_sends() would 
> ever continue beyond this time. 

Now mcast_send can call init_completion *after* stop_thread does wait for
completion.
It could also call list_add while mcast_stop_thread walks the list.

Thats what I am trying to prevent.


-- 
MST