igmp: fix ip_mc_sf_allow race

On Mon, Jan 04, 2010 at 02:07:03PM +0100, Eric Dumazet wrote:
> Le 04/01/2010 12:29, Flavio Leitner a écrit :
>  
> > Then, I tried using call_rcu() to avoid the problem you are saying,
> > but when you stop the reproducer, sk_free() will warn printing 
> > "optmem leakage.." because the rcu callback didn't run yet.
> > 
> > 
> 
> This is probably because your call_rcu() callback was trying to call sock_kfree_s() ?

yes, correct.

> 
>  		rtnl_unlock();
> 		call_rcu(&iml->lock, callback_func)
> 
> callback_func()
> {
> 	sock_kfree_s(sk, iml, sizeof(*iml));
> }
> 
> 
> 
> Take a look at sock_kfree_s() definition :
> 
> void sock_kfree_s(struct sock *sk, void *mem, int size)
> {
>         kfree(mem);
>         atomic_sub(size, &sk->sk_omem_alloc);
> }
> 
> 
> You can certainly try :
> 
> 	rtnl_unlock();
> 	atomic_sub(sizeof(*iml), sk->sk_omem_alloc);
> 	call_rcu(&iml->rcu, kfree);
> 
> (immediate sk_omem_alloc handling, but deferred kfree())

Ok, below is the new version using call_rcu(). I'm still running my
tests here, so I'm planning to resubmit it later if this version is
okay with you.

thanks!

Le 04/01/2010 19:51, Flavio Leitner a écrit :
> On Mon, Jan 04, 2010 at 02:07:03PM +0100, Eric Dumazet wrote:
>> Le 04/01/2010 12:29, Flavio Leitner a écrit :
>>  
>>> Then, I tried using call_rcu() to avoid the problem you are saying,
>>> but when you stop the reproducer, sk_free() will warn printing 
>>> "optmem leakage.." because the rcu callback didn't run yet.
>>>
>>>
>>
>> This is probably because your call_rcu() callback was trying to call sock_kfree_s() ?
> 
> yes, correct.
> 
>>
>>  		rtnl_unlock();
>> 		call_rcu(&iml->lock, callback_func)
>>
>> callback_func()
>> {
>> 	sock_kfree_s(sk, iml, sizeof(*iml));
>> }
>>
>>
>>
>> Take a look at sock_kfree_s() definition :
>>
>> void sock_kfree_s(struct sock *sk, void *mem, int size)
>> {
>>         kfree(mem);
>>         atomic_sub(size, &sk->sk_omem_alloc);
>> }
>>
>>
>> You can certainly try :
>>
>> 	rtnl_unlock();
>> 	atomic_sub(sizeof(*iml), sk->sk_omem_alloc);
>> 	call_rcu(&iml->rcu, kfree);
>>
>> (immediate sk_omem_alloc handling, but deferred kfree())
> 
> Ok, below is the new version using call_rcu(). I'm still running my
> tests here, so I'm planning to resubmit it later if this version is
> okay with you.

It seems fine, but please make ip_mc_socklist_reclaim() static :

> +
> +void ip_mc_socklist_reclaim(struct rcu_head *rp)
> +{
> +	struct ip_mc_socklist *iml;
> +
> +	iml = container_of(rp, struct ip_mc_socklist, rcu);
> +	/* sk_omem_alloc should have been decreased by the caller*/
> +	kfree(iml);
> +}
> +
> +

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

For readability, instead of:

        ret = X;
        if (condition)
                goto out;

I prefer:

        if (condition) {
                ret = X;
                goto out;
        }

which makes it clear that ret is for the return and not
some random state change unrelated to the condition.

Otherwise, looks ok to me.

                                        +-DLS

Acked-by: David L Stevens <dlstevens@us.ibm.com>

--
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 05/01/2010 01:06, David Stevens a écrit :
> For readability, instead of:
> 
>         ret = X;
>         if (condition)
>                 goto out;
> 
> I prefer:
> 
>         if (condition) {
>                 ret = X;
>                 goto out;
>         }
> 
> which makes it clear that ret is for the return and not
> some random state change unrelated to the condition.
> 

Linus argument for this common Linux coding style is that generated code is smaller

	mov	$-6,%eax
	cmp	condition
	je	out

versus
	cmp	condition
	jne	.ok
	mov	$-6,%eax
	jmp	out
.ok:

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