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

[Patrick McHardy <kaber@trash.net>]

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.