All of lore.kernel.org
 help / color / mirror / Atom feed
* conntrack (nf_conn) locking question
@ 2011-09-08  8:12 Gidon Miller
  2011-09-12  8:45 ` Pablo Neira Ayuso
  0 siblings, 1 reply; 6+ messages in thread
From: Gidon Miller @ 2011-09-08  8:12 UTC (permalink / raw)
  To: netfilter-devel

Hi,
I hope I'm posting this question to the correct list. if not please
let me know where I should be posting.

I'm writing a kernel module (against 2.6.32) to add functionality to
conntrack to maintain extra state information for certain tcp
connections.
the way I'm doing this is by unregistering the l4proto handler for tcp
on module load and registering my own handler struct which is the same
except for the new(), destroy(), packet() and print_conntrack()
functions. my functions call the original tcp handler functions and
then perform some of their own logic - they change the ct->mark to
hold an id used to reference a table of "my" connection info (that
holds my state and other data). I also have xtables matcher and target
modules that reference this conntrack info and do some logic
accordingly.
therefore I'd like to protect my data and the nf_conn data while in my
handler functions.

this raises a few questions:
1. I see that xtables modules (such as xt_CONNMARK and xt_state) do
not take the ct->lock. what protects the ct entry in this case?
2. since I cant take the ct->lock in my functions (because they call
the tcp functions who take the lock) its not clear to me how to
protect my data. in general, is my approach the correct one?

thanks in advance,
Gidon Miller

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: conntrack (nf_conn) locking question
  2011-09-08  8:12 conntrack (nf_conn) locking question Gidon Miller
@ 2011-09-12  8:45 ` Pablo Neira Ayuso
  2011-09-12 10:11   ` Gidon Miller
  0 siblings, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2011-09-12  8:45 UTC (permalink / raw)
  To: Gidon Miller; +Cc: netfilter-devel

On Thu, Sep 08, 2011 at 11:12:53AM +0300, Gidon Miller wrote:
> Hi,
> I hope I'm posting this question to the correct list. if not please
> let me know where I should be posting.
> 
> I'm writing a kernel module (against 2.6.32) to add functionality to
> conntrack to maintain extra state information for certain tcp
> connections.

Better use one ct extension.

> the way I'm doing this is by unregistering the l4proto handler for tcp
> on module load and registering my own handler struct which is the same
> except for the new(), destroy(), packet() and print_conntrack()
> functions. my functions call the original tcp handler functions and
> then perform some of their own logic - they change the ct->mark to
> hold an id used to reference a table of "my" connection info (that
> holds my state and other data). I also have xtables matcher and target
> modules that reference this conntrack info and do some logic
> accordingly.
> therefore I'd like to protect my data and the nf_conn data while in my
> handler functions.
> 
> this raises a few questions:
> 1. I see that xtables modules (such as xt_CONNMARK and xt_state) do
> not take the ct->lock. what protects the ct entry in this case?
> 2. since I cant take the ct->lock in my functions (because they call
> the tcp functions who take the lock) its not clear to me how to
> protect my data. in general, is my approach the correct one?

The ct->lock is only used if you modify the internal TCP data for that
ct flow, like it happens in the nf_conntrack_tcp code.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: conntrack (nf_conn) locking question
  2011-09-12  8:45 ` Pablo Neira Ayuso
@ 2011-09-12 10:11   ` Gidon Miller
  2011-09-12 18:53     ` Pablo Neira Ayuso
  0 siblings, 1 reply; 6+ messages in thread
From: Gidon Miller @ 2011-09-12 10:11 UTC (permalink / raw)
  To: netfilter-devel

Hi Pablo,
thanks for your reply. can you please refer me to any documentation on
how to use ct extensions?
thanks,
Gidon

On Mon, Sep 12, 2011 at 11:45 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
>
> On Thu, Sep 08, 2011 at 11:12:53AM +0300, Gidon Miller wrote:
> > Hi,
> > I hope I'm posting this question to the correct list. if not please
> > let me know where I should be posting.
> >
> > I'm writing a kernel module (against 2.6.32) to add functionality to
> > conntrack to maintain extra state information for certain tcp
> > connections.
>
> Better use one ct extension.
>
> > the way I'm doing this is by unregistering the l4proto handler for tcp
> > on module load and registering my own handler struct which is the same
> > except for the new(), destroy(), packet() and print_conntrack()
> > functions. my functions call the original tcp handler functions and
> > then perform some of their own logic - they change the ct->mark to
> > hold an id used to reference a table of "my" connection info (that
> > holds my state and other data). I also have xtables matcher and target
> > modules that reference this conntrack info and do some logic
> > accordingly.
> > therefore I'd like to protect my data and the nf_conn data while in my
> > handler functions.
> >
> > this raises a few questions:
> > 1. I see that xtables modules (such as xt_CONNMARK and xt_state) do
> > not take the ct->lock. what protects the ct entry in this case?
> > 2. since I cant take the ct->lock in my functions (because they call
> > the tcp functions who take the lock) its not clear to me how to
> > protect my data. in general, is my approach the correct one?
>
> The ct->lock is only used if you modify the internal TCP data for that
> ct flow, like it happens in the nf_conntrack_tcp code.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: conntrack (nf_conn) locking question
  2011-09-12 10:11   ` Gidon Miller
@ 2011-09-12 18:53     ` Pablo Neira Ayuso
  2011-09-12 19:12       ` Krzysztof Olędzki
  0 siblings, 1 reply; 6+ messages in thread
From: Pablo Neira Ayuso @ 2011-09-12 18:53 UTC (permalink / raw)
  To: Gidon Miller; +Cc: netfilter-devel

On Mon, Sep 12, 2011 at 01:11:50PM +0300, Gidon Miller wrote:
> Hi Pablo,
> thanks for your reply. can you please refer me to any documentation on
> how to use ct extensions?

Only code, see net/netfilter/nf_conntrack_acct.c for instance.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: conntrack (nf_conn) locking question
  2011-09-12 18:53     ` Pablo Neira Ayuso
@ 2011-09-12 19:12       ` Krzysztof Olędzki
  2011-09-18  7:04         ` Gidon Miller
  0 siblings, 1 reply; 6+ messages in thread
From: Krzysztof Olędzki @ 2011-09-12 19:12 UTC (permalink / raw)
  To: Gidon Miller; +Cc: Pablo Neira Ayuso, netfilter-devel

On 2011-09-12 20:53, Pablo Neira Ayuso wrote:
> On Mon, Sep 12, 2011 at 01:11:50PM +0300, Gidon Miller wrote:
>> Hi Pablo,
>> thanks for your reply. can you please refer me to any documentation on
>> how to use ct extensions?
>
> Only code, see net/netfilter/nf_conntrack_acct.c for instance.

Plus:
  include/net/netfilter/nf_conntrack_acct.h
  include/net/netfilter/nf_conntrack_extend.h

BTW: if nothing changed, extensions can be only attached to a conntrack 
before it is confirmed.

Best regards,

				Krzysztof Olędzki
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: conntrack (nf_conn) locking question
  2011-09-12 19:12       ` Krzysztof Olędzki
@ 2011-09-18  7:04         ` Gidon Miller
  0 siblings, 0 replies; 6+ messages in thread
From: Gidon Miller @ 2011-09-18  7:04 UTC (permalink / raw)
  To: Krzysztof Olędzki; +Cc: Pablo Neira Ayuso, netfilter-devel

Hi Krzysztof, Pablo,
thanks for your advice. it took me a while to get around to have a
look at the code but I finally reviewed it a bit.
correct me if I'm wrong but it seems that the list of ct extensions is
closed. the extension id is defined in enum nf_ct_ext_id and
registered in ct->ext whos offset member is NF_CT_EXT_NUM sized. looks
like the extensions cannot be expanded if I'm writing my code in a
module.
have I missed something?
thanks,
Gidon

2011/9/12 Krzysztof Olędzki <ole@ans.pl>
>
> On 2011-09-12 20:53, Pablo Neira Ayuso wrote:
>>
>> On Mon, Sep 12, 2011 at 01:11:50PM +0300, Gidon Miller wrote:
>>>
>>> Hi Pablo,
>>> thanks for your reply. can you please refer me to any documentation on
>>> how to use ct extensions?
>>
>> Only code, see net/netfilter/nf_conntrack_acct.c for instance.
>
> Plus:
>  include/net/netfilter/nf_conntrack_acct.h
>  include/net/netfilter/nf_conntrack_extend.h
>
> BTW: if nothing changed, extensions can be only attached to a conntrack before it is confirmed.
>
> Best regards,
>
>                                Krzysztof Olędzki
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-09-18  7:04 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-08  8:12 conntrack (nf_conn) locking question Gidon Miller
2011-09-12  8:45 ` Pablo Neira Ayuso
2011-09-12 10:11   ` Gidon Miller
2011-09-12 18:53     ` Pablo Neira Ayuso
2011-09-12 19:12       ` Krzysztof Olędzki
2011-09-18  7:04         ` Gidon Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.