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