* [Question] netfilter, xt_target->target and xt_target->checkentry locks @ 2010-06-09 12:21 Jiri Pirko 2010-06-09 12:37 ` Jan Engelhardt 0 siblings, 1 reply; 7+ messages in thread From: Jiri Pirko @ 2010-06-09 12:21 UTC (permalink / raw) To: kaber; +Cc: netfilter, bart.de.schuymer, davem, shemminger 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. Asking because I found several places where dev->br_port is referenced directly (without rcu_dereference). Thanks a lot. Jirka ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Question] netfilter, xt_target->target and xt_target->checkentry locks 2010-06-09 12:21 [Question] netfilter, xt_target->target and xt_target->checkentry locks Jiri Pirko @ 2010-06-09 12:37 ` Jan Engelhardt 2010-06-09 13:00 ` Jiri Pirko 0 siblings, 1 reply; 7+ messages in thread From: Jan Engelhardt @ 2010-06-09 12:37 UTC (permalink / raw) To: Jiri Pirko; +Cc: kaber, netfilter, bart.de.schuymer, davem, shemminger 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. >Asking because I found several places where dev->br_port is >referenced directly (without rcu_dereference). ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Question] netfilter, xt_target->target and xt_target->checkentry locks 2010-06-09 12:37 ` Jan Engelhardt @ 2010-06-09 13:00 ` Jiri Pirko 2010-06-09 13:03 ` Patrick McHardy 0 siblings, 1 reply; 7+ messages in thread From: Jiri Pirko @ 2010-06-09 13:00 UTC (permalink / raw) To: Jan Engelhardt; +Cc: kaber, netfilter, bart.de.schuymer, davem, shemminger 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. > >>Asking because I found several places where dev->br_port is >>referenced directly (without rcu_dereference). > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Question] netfilter, xt_target->target and xt_target->checkentry locks 2010-06-09 13:00 ` Jiri Pirko @ 2010-06-09 13:03 ` Patrick McHardy 2010-06-09 13:13 ` Jiri Pirko 0 siblings, 1 reply; 7+ messages in thread From: Patrick McHardy @ 2010-06-09 13:03 UTC (permalink / raw) To: Jiri Pirko; +Cc: Jan Engelhardt, netfilter, bart.de.schuymer, davem, shemminger 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Question] netfilter, xt_target->target and xt_target->checkentry locks 2010-06-09 13:03 ` Patrick McHardy @ 2010-06-09 13:13 ` Jiri Pirko 2010-06-09 13:26 ` Patrick McHardy 0 siblings, 1 reply; 7+ messages in thread From: Jiri Pirko @ 2010-06-09 13:13 UTC (permalink / raw) To: Patrick McHardy Cc: Jan Engelhardt, netfilter, bart.de.schuymer, davem, shemminger 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? ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Question] netfilter, xt_target->target and xt_target->checkentry locks 2010-06-09 13:13 ` Jiri Pirko @ 2010-06-09 13:26 ` Patrick McHardy 2010-06-09 14:06 ` Jiri Pirko 0 siblings, 1 reply; 7+ messages in thread From: Patrick McHardy @ 2010-06-09 13:26 UTC (permalink / raw) To: Jiri Pirko; +Cc: Jan Engelhardt, netfilter, bart.de.schuymer, davem, shemminger 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Question] netfilter, xt_target->target and xt_target->checkentry locks 2010-06-09 13:26 ` Patrick McHardy @ 2010-06-09 14:06 ` Jiri Pirko 0 siblings, 0 replies; 7+ messages in thread From: Jiri Pirko @ 2010-06-09 14:06 UTC (permalink / raw) To: Patrick McHardy Cc: Jan Engelhardt, netfilter, bart.de.schuymer, davem, shemminger 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-06-09 14:06 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-06-09 12:21 [Question] netfilter, xt_target->target and xt_target->checkentry locks Jiri Pirko 2010-06-09 12:37 ` Jan Engelhardt 2010-06-09 13:00 ` Jiri Pirko 2010-06-09 13:03 ` Patrick McHardy 2010-06-09 13:13 ` Jiri Pirko 2010-06-09 13:26 ` Patrick McHardy 2010-06-09 14:06 ` Jiri Pirko
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).