[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080927000000.GB10489@x200.localdomain>
Date: Sat, 27 Sep 2008 04:00:00 +0400
From: Alexey Dobriyan <adobriyan@...il.com>
To: Patrick McHardy <kaber@...sh.net>
Cc: netdev@...r.kernel.org, netfilter-devel@...r.kernel.org,
containers@...ts.linux-foundation.org
Subject: Re: [PATCH 17/33] netns ct: final init_net tweaks
On Sat, Sep 13, 2008 at 02:45:15PM +0400, Alexey Dobriyan wrote:
> On Tue, Sep 09, 2008 at 09:51:56AM +0200, Patrick McHardy wrote:
> > Alexey Dobriyan wrote:
> >> On Tue, Sep 09, 2008 at 09:20:42AM +0200, Patrick McHardy wrote:
> >>> Having multiple of these net_eq checks per function (14 total) is
> >>> not a very nice way to do this.
> >>
> >> Yep, I was just afraid of some subtle ordering rules and to keep
> >> potential init_net breakage to minimum.
> >
> > Me too, but I still prefer to do it properly once.
> >
> >>> How about splitting the code into a netns and a global part instead?
> >>
> >> Prebably they aren't strict at all.
> >
> > Not particulary. For cleanup a three stage approach with
> >
> > 1. init_net deactivation (ip_ct_attach = NULL)
> > 2. generic netns cleanup
> > 3. init_net specific final cleanup (slab cache, nf_conntrack_cachep,
> > accounting, helpers, protocols, ...)
> >
> > should work fine.
> >
> > The initialization should be OK with just a init_net part
> > and a generic netns part.
>
> Ugh, I'm still finding the least ugly way to put init_net checks, and
> it's better to do it at the very end.
>
> So, slight reordering.
>
> See per-netns statistics, nf_conntrack_count, nf_conntrack_checksum,
> nf_conntrack_log_invalid and accounting.
>
> The rest (SIP, H323, GRE, PPTP, per-netns NAT) remains the same and can
> be applied independently of init_net checks.
Ping!
I've just sent patch which adds init_net checks in somewhat nicer way.
Please, review and apply the rest.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists