All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gidon Miller <gmiller@vasonanetworks.com>
To: netfilter-devel <netfilter-devel@vger.kernel.org>
Subject: conntrack (nf_conn) locking question
Date: Thu, 8 Sep 2011 11:12:53 +0300	[thread overview]
Message-ID: <CAOAcFN-fXwCrtDu1snSAH-O5ud92bcBS4Dh8fR2m38pc=5hbTA@mail.gmail.com> (raw)

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

             reply	other threads:[~2011-09-08  8:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-08  8:12 Gidon Miller [this message]
2011-09-12  8:45 ` conntrack (nf_conn) locking question 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOAcFN-fXwCrtDu1snSAH-O5ud92bcBS4Dh8fR2m38pc=5hbTA@mail.gmail.com' \
    --to=gmiller@vasonanetworks.com \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.