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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
