SCTP: fix race between sctp_bind_addr_free() and sctp_bind_addr_conflict()

2011/5/18 Vladislav Yasevich <vladislav.yasevich@hp.com>:
> On 05/18/2011 05:02 AM, Wei Yongjun wrote:
>
>> fix the race between sctp_bind_addr_free() and sctp_bind_addr_conflict(), maybe you just
>> need to remove the socket from the port hash before empty the bind address list.
>> some thing like this, not test.
>>
>> diff --git a/net/sctp/endpointola.c b/net/sctp/endpointola.c
>> index c8cc24e..924d846 100644
>> --- a/net/sctp/endpointola.c
>> +++ b/net/sctp/endpointola.c
>> @@ -268,12 +268,13 @@ static void sctp_endpoint_destroy(struct sctp_endpoint *ep)
>>
>>       /* Cleanup. */
>>       sctp_inq_free(&ep->base.inqueue);
>> -     sctp_bind_addr_free(&ep->base.bind_addr);
>>
>>       /* Remove and free the port */
>>       if (sctp_sk(ep->base.sk)->bind_hash)
>>               sctp_put_port(ep->base.sk);
>>
>> +     sctp_bind_addr_free(&ep->base.bind_addr);
>> +
>>       /* Give up our hold on the sock. */
>>       if (ep->base.sk)
>>               sock_put(ep->base.sk);
>>
>>
>
> I am not sure that this will guarantee avoidance of this crash, even though it is the right
> thing to do in general.
>
> We simply make the race condition much smaller and much harder to hit.  Potentially, one
> cpu may be doing lookup of the socket while the other is doing the destroy.  If the lookup cpu
> finds the socket just as this code removes the socket from the hash, we still have this potential
> race condition.
>
> I agree with Eric, rcu_read_lock() is not strictly necessary, as what we are really after is call_rcu()
> based destruction.  We need to delay memory destruction for the rcu grace period.
>
> Thinking a little more about how bind_addr_clean() is used, it would probably benefit from getting
> converted to call_rcu().  That function is used as local clean-up in case of malloc failure; however,
> that doesn't preclude a potential race.  The fact that we do not have this race simply points out that
> we don't have any kind of parallel lookup that can hit it (and the code confirms it).  This doesn't
> mean that we wouldn't have it in the future.
>

OK then, at the end what Eric suggested is IMO valid:



I will test this. Should be safe, avoid race not only in that case and
it consistent.

-Jacek
--
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

Le mercredi 18 mai 2011 à 14:47 +0200, Jacek Luczak a écrit :

> OK then, at the end what Eric suggested is IMO valid:
> 
> diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c
> index faf71d1..0025d90 100644
> --- a/net/sctp/bind_addr.c
> +++ b/net/sctp/bind_addr.c
> @@ -144,10 +144,9 @@ static void sctp_bind_addr_clean(struct sctp_bind_addr *bp)
>         struct list_head *pos, *temp;
> 
>         /* Empty the bind address list. */
> -       list_for_each_safe(pos, temp, &bp->address_list) {
> -               addr = list_entry(pos, struct sctp_sockaddr_entry, list);
> -               list_del(pos);
> -               kfree(addr);
> +       list_for_each_entry(pos, &bp->address_list, list) {

a 'safe' version is needed here, since we remove items in iterator.

> +               list_del_rcu(&pos->list);
> +               call_rcu(&pos->rcu, sctp_local_addr_free);
>                 SCTP_DBG_OBJCNT_DEC(addr);
>         }
>  }
> 
> 
> I will test this. Should be safe, avoid race not only in that case and
> it consistent.
> 
> -Jacek


--
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