Re: [Question] netfilter, xt_target->target and xt_target->checkentry locks

[Jiri Pirko <jpirko@redhat.com>]

Wed, Jun 09, 2010 at 03:26:44PM CEST, kaber@trash.net wrote:
>Jiri Pirko wrote:
>> Wed, Jun 09, 2010 at 03:03:19PM CEST, kaber@trash.net wrote:
>>   
>>> Jiri Pirko wrote:
>>>     
>>>> Wed, Jun 09, 2010 at 02:37:51PM CEST, jengelh@medozas.de wrote:
>>>>   
>>>>       
>>>>> On Wednesday 2010-06-09 14:21, Jiri Pirko wrote:
>>>>>
>>>>>     
>>>>>         
>>>>>> Hi Patrick.
>>>>>>
>>>>>> Once module registers it's struct xt_target by xt_register_target and 
>>>>>> ->target and ->checkentry funtions are called later, is there any lock 
>>>>>> guaranteed to be held?
>>>>>>       
>>>>>>           
>>>>> >From what I see for ->target it looks like rcu_read_lock is held, but 
>>>>>     
>>>>>         
>>>>>> I'm not sure for all paths. There would be nice to put a comment into 
>>>>>> struct xt_target definition regarding locks.
>>>>>>       
>>>>>>           
>>>>> Though nf_hook_slow invokes rcu_read_lock, that should not be a formal
>>>>> guarantee that Xtables extensions run with RCU. See xt_TCPMSS for 
>>>>> example.
>>>>>     
>>>>>         
>>>> A was afraid of it. Thanks.
>>>>       
>>> We actually assume this in all conntrack helpers, so I don't see anything
>>> wrong with making the same assumption in xtables modules, as long as
>>> its documented.
>>>     
>>
>> Where this is documented please?
>>   
>
>In the spots relying on this ("/* rcu_read_lock()ed by nf_hook_slow */").
>Actually its not the helpers, but other parts of conntrack.

Ok, I'll add it to appropriate places. And in xt_TCPMSS, rcu_read_lock can be
removed too.

Thanks.

Jirka