From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 5/8] [PATCH] deliver events for conntracks created via ctnetlink
Date: Sat, 11 Oct 2008 14:05:26 +0200 [thread overview]
Message-ID: <48F09686.5060201@netfilter.org> (raw)
In-Reply-To: <48EF593B.30208@trash.net>
Patrick McHardy wrote:
> Looks pretty good, some minor issues:
>
> - there are quite a lot of trailing whitespaces in this
> patch, please remove those.
I have added a tweak for vim to remove them automatically when I write
the file, so this should not happen anymore. BTW, does git complain on
this by default when I apply one patch or I have to tweak something?
>> +/* This structure is passed to event handler */
>> +struct nf_ct_event {
>> + struct nf_conn *ct;
>> + u32 pid;
>> + int report;
>> +};
>
> Just a suggestion: passing the nlmsghdr instead of the ECHO
> flag and doing the approriate handling in the event functions
> seems more logical to me. I think I know why you did it this
> way (no reporting on unload, no netlink context there), see
> below about that.
Indeed.
>> diff --git a/net/netfilter/nf_conntrack_core.c
>> b/net/netfilter/nf_conntrack_core.c
>> index f465090..aab2618 100644
>> --- a/net/netfilter/nf_conntrack_core.c
>> +++ b/net/netfilter/nf_conntrack_core.c
>> @@ -174,7 +174,8 @@ destroy_conntrack(struct nf_conntrack *nfct)
>> NF_CT_ASSERT(atomic_read(&nfct->use) == 0);
>> NF_CT_ASSERT(!timer_pending(&ct->timeout));
>>
>> - nf_conntrack_event(IPCT_DESTROY, ct);
>> + if (!test_bit(IPS_DYING_BIT, &ct->status))
>> + nf_conntrack_event(IPCT_DESTROY, ct);
>
> Whats the idea behind this change? Is it simply an optimization?
If we remove a conntrack entry via ctnetlink, we get the event report
twice, one from ctnetlink and another one from death_by_timeout, so we
set the dying bit in ctnetlink to avoid this double reporting in
death_by_timeout. This idea is actually yours :)
>> set_bit(IPS_DYING_BIT, &ct->status);
>>
>> /* To make sure we don't get any weird locking issues here:
>> @@ -963,8 +964,24 @@ void nf_ct_iterate_cleanup(struct net *net,
>> }
>> EXPORT_SYMBOL_GPL(nf_ct_iterate_cleanup);
>>
>> +struct __nf_ct_flush_report {
>> + u32 pid;
>> + int report;
>> +};
>> +
>> static int kill_all(struct nf_conn *i, void *data)
>> {
>> + struct __nf_ct_flush_report *fr = (struct __nf_ct_flush_report
>> *)data;
>> +
>> + if (!fr->report)
>> + return 1;
>
> Whats the reasoning behind not reporting destroy events on unload?
> I don't think there's anything special about module unload, so it
> seems inconsistent.
OK, I'll fix this. I'm going to prepare another patch round to cover
this issues.
--
"Los honestos son inadaptados sociales" -- Les Luthiers
next prev parent reply other threads:[~2008-10-11 12:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-09 8:33 [PATCH 1/8] [PATCH] get rid of module refcounting in ctnetlink Pablo Neira Ayuso
2008-10-09 8:34 ` [PATCH 2/8] [PATCH] connection tracking helper name persistent aliases Pablo Neira Ayuso
2008-10-09 13:27 ` Patrick McHardy
2008-10-09 8:34 ` [PATCH 3/8] [PATCH] Helper modules load-on-demand support for ctnetlink Pablo Neira Ayuso
2008-10-09 13:34 ` Patrick McHardy
2008-10-09 13:43 ` Patrick McHardy
2008-10-09 14:50 ` Pablo Neira Ayuso
2008-10-09 16:11 ` Patrick McHardy
2008-10-09 16:43 ` Pablo Neira Ayuso
2008-10-09 8:34 ` [PATCH 4/8] [PATCH] use EOPNOTSUPP instead of EINVAL if the conntrack has no helper Pablo Neira Ayuso
2008-10-10 13:03 ` Patrick McHardy
2008-10-09 8:35 ` [PATCH 5/8] [PATCH] deliver events for conntracks created via ctnetlink Pablo Neira Ayuso
2008-10-10 13:31 ` Patrick McHardy
2008-10-11 12:05 ` Pablo Neira Ayuso [this message]
2008-10-11 14:53 ` Patrick McHardy
2008-10-09 8:35 ` [PATCH 6/8] [PATCH] bump the expectation helper name Pablo Neira Ayuso
2008-10-09 8:35 ` [PATCH 7/8] [PATCH] dynamic calculation of event message size for ctnetlink Pablo Neira Ayuso
2008-10-09 16:45 ` Pablo Neira Ayuso
2008-10-09 8:36 ` [PATCH 8/8] [PATCH] remove module dependency between ctnetlink and nf_nat Pablo Neira Ayuso
2008-10-09 13:26 ` [PATCH 1/8] [PATCH] get rid of module refcounting in ctnetlink Patrick McHardy
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=48F09686.5060201@netfilter.org \
--to=pablo@netfilter.org \
--cc=kaber@trash.net \
--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 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).