From: Patrick McHardy <kaber@trash.net>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: [PATCH 5/8] [PATCH] deliver events for conntracks created via ctnetlink
Date: Fri, 10 Oct 2008 15:31:39 +0200 [thread overview]
Message-ID: <48EF593B.30208@trash.net> (raw)
In-Reply-To: <20081009083506.9824.48734.stgit@Decadence>
Pablo Neira Ayuso wrote:
> As for now, the creation and update of conntracks via ctnetlink do not
> propagate an event to userspace. This can result in inconsistent situations
> if several userspace processes modify the connection tracking table by means
> of ctnetlink at the same time. Specifically, using the conntrack command
> line tool and conntrackd at the same time can trigger unconsistencies.
>
> This patch also modifies the event cache infrastructure to pass the
> process PID and the ECHO flag to nfnetlink_send() to report back
> to userspace if the process that triggered the change needs so.
> Based on a suggestion from Patrick McHardy.
Looks pretty good, some minor issues:
- there are quite a lot of trailing whitespaces in this
patch, please remove those.
> +/* 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.
> 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?
> 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.
next prev parent reply other threads:[~2008-10-10 13:31 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 [this message]
2008-10-11 12:05 ` Pablo Neira Ayuso
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=48EF593B.30208@trash.net \
--to=kaber@trash.net \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.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.