Wed, Jun 09, 2010 at 03:26:44PM CEST, kaber@xxxxxxxxx wrote:
>Jiri Pirko wrote:
>> Wed, Jun 09, 2010 at 03:03:19PM CEST, kaber@xxxxxxxxx wrote:
>>
>>> Jiri Pirko wrote:
>>>
>>>> Wed, Jun 09, 2010 at 02:37:51PM CEST, jengelh@xxxxxxxxxx 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
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
