netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alexey Dobriyan <adobriyan@gmail.com>
To: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Cc: Patrick McHardy <kaber@trash.net>,
	netfilter-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] netfilter: add per-namespace logging to nfnetlink_log.c
Date: Mon, 18 Jul 2011 22:19:56 +0300	[thread overview]
Message-ID: <20110718191956.GA2489@p183.telecom.by> (raw)
In-Reply-To: <8739i3fp6s.fsf@sapphire.mobileactivedefense.com>

On Mon, Jul 18, 2011 at 06:56:11PM +0100, Rainer Weikusat wrote:
> Patrick McHardy <kaber@trash.net> writes:
> > On 01.07.2011 16:44, Rainer Weikusat wrote:
> >> From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
> >> 
> >> Presently, the nfnetlink_log.c file contains only very nominal support
> >> for network namespaces: While it is possible to create sockets which
> >> should theoretically receive NFLOG originated messages in arbitrary
> >> network namespaces, there is only one table of nfulnl_instance
> >> structures in the kernel and all log messages sent via __nfulnl_send
> >> are forced into the init_net namespace so that only sockets created
> >> in this namespace will ever actually receive log data.
> 
> [...]
> 
> >> +#define INSTANCE_BUCKETS	16
> >> +
> >> +struct nfulnl_instances {
> >> +	spinlock_t lock;
> >> +	atomic_t global_seq;
> >> +	struct hlist_head table[INSTANCE_BUCKETS];
> >> +	unsigned hash_init;
> >> +#ifdef NET_NS
> >> +	struct net *net;
> >> +#endif
> >> +};
> >> +
> >>  struct nfulnl_instance {
> >>  	struct hlist_node hlist;	/* global list of instances */
> >>  	spinlock_t lock;
> >> @@ -67,14 +85,92 @@ struct nfulnl_instance {
> >>  	u_int16_t flags;
> >>  	u_int8_t copy_mode;
> >>  	struct rcu_head rcu;
> >> +#ifdef NET_NS
> >> +	struct nfulnl_instances *instances;
> >> +#endif
> >
> > This seems odd, the usual way is to add the global data to the
> > net-ns structure.
> 
> Since a facility for having 'per subsystem' network namespace specific
> data exists, there seems to be little reason to not use it. The
> interface is defined in include/net/netns/generic.h and documented as
> 
>  * Generic net pointers are to be used by modules to put some private
>  * stuff on the struct net without explicit struct net modification
> 
> >> +#ifndef NET_NS
> >> +static struct nfulnl_instances instances;
> >>  
> >> -#define INSTANCE_BUCKETS	16
> >> -static struct hlist_head instance_table[INSTANCE_BUCKETS];
> >> -static unsigned int hash_init;
> >> +static inline struct nfulnl_instances *
> >> +instances_via_inst(struct nfulnl_instance *inst)
> >> +{
> >> +	(void)inst;
> >> +	return &instances;
> >> +}
> >
> > ... then you don't need all this because it will automatically
> > use the structures from init_net when CONFIG_NET_NS=n
> 
> But then, the more complicated access method via struct net will
> always be used while anything resembling network namespace support
> will be removed at compile-time if the kernel is configured without
> network namespace support for this code. Which happened to be the
> point of this exercise.
> 
> > Basically everything depending on CONFIG_NET_NS is wrong,
> > this is handled automatically if you're using the API the proper
> > way.
> 
> There is no such thing as 'an API which can be used in the proper way'
> here for the simple reason that not even functional documentation on
> this exists (AFAIK), let alone documentation about usage policies
> someone would like to mandate.

We did whole networking without sprinkling ifdefs and left them only at
few strategic places, now how did we manage to do it?
This functional doc argument, well, we aren't corporate IT shop
where it counts.

Briefly looking, there is no need for instances_via_skb(),
it's badly named and netns can be found at netlink control socket.

_instances struct is unnecessary.

  parent reply	other threads:[~2011-07-18 19:20 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-01 14:44 [PATCH] netfilter: add per-namespace logging to nfnetlink_log.c Rainer Weikusat
2011-07-18 16:21 ` Patrick McHardy
2011-07-18 17:56   ` Rainer Weikusat
2011-07-18 19:11     ` Rainer Weikusat
2011-07-18 19:19     ` Alexey Dobriyan [this message]
2011-07-18 19:43       ` Rainer Weikusat
2011-07-18 19:46         ` David Miller
2011-07-18 20:17           ` Rainer Weikusat
2011-07-18 20:19             ` David Miller
2011-07-18 20:32               ` Alexey Dobriyan
2011-07-19  9:42                 ` Patrick McHardy
2011-07-18 20:27             ` Eric Dumazet
2011-07-18 20:28             ` Jan Engelhardt
2011-07-19 21:38               ` Rainer Weikusat
2011-07-20 15:04                 ` [PATCH] netfilter: add per-namespace logging to nfnetlink_log.c (updated) Rainer Weikusat
2011-07-26 11:22                   ` Rainer Weikusat
2011-07-26 11:37                   ` [PATCH] netfilter: add per-namespace logging to nfnetlink_log.c (updated again) Rainer Weikusat
2011-07-28  7:00                     ` Patrick McHardy
2011-07-28 19:56                       ` Rainer Weikusat
2011-07-28 19:57                     ` [PATCH] netfilter: add per-namespace logging to nfnetlink_log.c (updated yet again) Rainer Weikusat

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=20110718191956.GA2489@p183.telecom.by \
    --to=adobriyan@gmail.com \
    --cc=kaber@trash.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=rweikusat@mobileactivedefense.com \
    /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).