[HELP] netfilter Kconfig dependency nightmare

[HELP] netfilter Kconfig dependency nightmare

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 2529 bytes --]

On Fri, Sep 16, 2005 at 10:23:15PM -0300, Arnaldo Carvalho de Melo wrote:
> After applying this patch I still get a loop:
> 
> [acme@toy net-2.6]$ make O=OUTPUT/oops/ oldconfig | grep Warning
> Warning! Found recursive dependency: IP_NF_CONNTRACK_NETLINK NETFILTER_NETLINK IP_NF_CONNTRACK_NETLINK
> Warning! Found recursive dependency: NETFILTER_NETLINK IP_NF_CONNTRACK_NETLINK NETFILTER_NETLINK NETFILTER_NETLINK_QUEUE
> 
> This is using latest Dave tree, the one just before master.kernel.org
> was switched off for moving to Oregon, is there any other patch I should
> apply?

This f!*#$%!#$%ing kconfig dependency is killing me.   We have this
incredible inter-dependency between various options, and with every new
feature it's getting more complex.  The main reason being to avoid some
bits of dead code in case it's not really needed by some other module.

I'm starting to wonder whether it's really worth saving those few bytes
in some configurations at the expense of this complexity.

Maybe some Kconfig freak can help out. This is the intended dependency
rules:

ip_conntrack == CONFIG_IP_NF_CONNTRACK
nfnetlink == CONFIG_NETFILTER_NETLINK
ip_conntrack_netlink == CONFIG_IP_NF_CONNTRACK_NETLINK

If nfnetlink == N, ip_conntrack can be N or M or Y
If nfnetlink == M, ip_conntrack can be N or M
If nfnetlink == Y, ip_conntrack can be Y or M

If ip_conntrack == N && nfnetlink == N, ip_conntrack_netlink must be N
If ip_conntrack == N && nfnetlink == M, ip_conntrack_netlink must be N
If ip_conntrack == N && nfnetlink == Y, ip_conntrack_netlink must be N

If ip_conntrack == M && nfnetlink == N, ip_conntrack_netlink must be N 
If ip_conntrack == M && nfnetlink == M, ip_conntrack_netlink can N or M
If ip_conntrack == M && nfnetlink == Y, ip_conntrack_netlink can N or M

if ip_conntrack == Y && nfnetlink == N, ip_conntrack_netlink must be N
if ip_conntrack == Y && nfnetlink == M, ip_conntrack_netlink can N or M
if ip_conntrack == Y && nfnetlink == Y, ip_conntrack_netlink can N, M or Y

NETfILTER_NETLINK_QUEUE and NETFILTER_NETLINK_LOG only depend on
NETFILER_NETLINK and nothing else.

Cheers,

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [HELP] netfilter Kconfig dependency nightmare

[Roman Zippel]

Hi,

On Sat, 17 Sep 2005, Harald Welte wrote:

> ip_conntrack == CONFIG_IP_NF_CONNTRACK
> nfnetlink == CONFIG_NETFILTER_NETLINK
> ip_conntrack_netlink == CONFIG_IP_NF_CONNTRACK_NETLINK
> 
> If nfnetlink == N, ip_conntrack can be N or M or Y
> If nfnetlink == M, ip_conntrack can be N or M
> If nfnetlink == Y, ip_conntrack can be Y or M

Where is the requirement for the last one coming from?

> If ip_conntrack == N && nfnetlink == N, ip_conntrack_netlink must be N
> If ip_conntrack == N && nfnetlink == M, ip_conntrack_netlink must be N
> If ip_conntrack == N && nfnetlink == Y, ip_conntrack_netlink must be N
> 
> If ip_conntrack == M && nfnetlink == N, ip_conntrack_netlink must be N 
> If ip_conntrack == M && nfnetlink == M, ip_conntrack_netlink can N or M
> If ip_conntrack == M && nfnetlink == Y, ip_conntrack_netlink can N or M
> 
> if ip_conntrack == Y && nfnetlink == N, ip_conntrack_netlink must be N
> if ip_conntrack == Y && nfnetlink == M, ip_conntrack_netlink can N or M
> if ip_conntrack == Y && nfnetlink == Y, ip_conntrack_netlink can N, M or Y

That looks like a normal ip_conntrack && nfnetlink.

bye, Roman

Re: [HELP] netfilter Kconfig dependency nightmare

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

On Sat, Sep 17, 2005 at 01:08:58PM +0200, Roman Zippel wrote:
> Hi,

Hi Roman, thanks for your reply.

> On Sat, 17 Sep 2005, Harald Welte wrote:
> 
> > ip_conntrack == CONFIG_IP_NF_CONNTRACK
> > nfnetlink == CONFIG_NETFILTER_NETLINK
> > ip_conntrack_netlink == CONFIG_IP_NF_CONNTRACK_NETLINK
> > 
> > If nfnetlink == N, ip_conntrack can be N or M or Y
> > If nfnetlink == M, ip_conntrack can be N or M
> > If nfnetlink == Y, ip_conntrack can be Y or M
> 
> Where is the requirement for the last one coming from?

sorry.  The last one should be N,M or Y.

The fundamental underlying problem is:

If CONFIG_IP_NF_CONNTRACK_NETLINK is selected (M or Y), then
CONFIG_IP_NF_CONNTRACK conditionally adds some code that references
symbols from nfnetlink.ko (CONFIG_NETFILTER_NETLINK)

So basically, enabling CONFIG_IP_NF_CONNTRACK_NETLINK creates a dependency
from CONFIG_IP_NF_CONNTRACK to CONFIG_NETFILTER_NETLINK.  AFAIK, the syntax
doesn't allow somthing like 

tristate IP_NF_CONNTRACK
	depends on NETFILTER_NETLINK if IP_NF_CONNTRACK_NETLINK!=n

So, if ip_conntrack_netlink == M (or Y), and ip_conntrack == Y, then
nfnetlink has to be set to Y (but cannot be a module).

Is there something that resembles 

And no, I do not see any chance to solve the problem in the code,
without either
1) adding yet another new module that only contains some 1kB of code and
   that requires additional EXPORT_SYMBOLS() on private data from
   ip_conntrack
or
2) adding dead code to ip_conntrack.ko that isn't used in many common
   configurations

:(

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [HELP] netfilter Kconfig dependency nightmare

[Roman Zippel]

Hi,

On Sat, 17 Sep 2005, Harald Welte wrote:

> If CONFIG_IP_NF_CONNTRACK_NETLINK is selected (M or Y), then
> CONFIG_IP_NF_CONNTRACK conditionally adds some code that references
> symbols from nfnetlink.ko (CONFIG_NETFILTER_NETLINK)
> 
> So basically, enabling CONFIG_IP_NF_CONNTRACK_NETLINK creates a dependency
> from CONFIG_IP_NF_CONNTRACK to CONFIG_NETFILTER_NETLINK.  AFAIK, the syntax
> doesn't allow somthing like 
> 
> tristate IP_NF_CONNTRACK
> 	depends on NETFILTER_NETLINK if IP_NF_CONNTRACK_NETLINK!=n

Since IP_NF_CONNTRACK_NETLINK is the one creating the dependency, 
something like this should work:

config IP_NF_CONNTRACK_NETLINK
	depends on IP_NF_CONNTRACK && NETFILTER_NETLINK
	depends on IP_NF_CONNTRACK!=y || NETFILTER_NETLINK!=m

IOW ct_nl depends on (ct && nl) unless (ct=y && nl=m).

bye, Roman

Re: [HELP] netfilter Kconfig dependency nightmare

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 742 bytes --]

On Sat, Sep 17, 2005 at 02:18:28PM +0200, Roman Zippel wrote:
> Since IP_NF_CONNTRACK_NETLINK is the one creating the dependency, 
> something like this should work:

yes, I agree.  Looking at the behaviour of "menuconfig", I think your
suggestion solves the problem.  I didn't try to compile all the
combinations, though.

I'll submit a patch via DaveM soon.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [HELP] netfilter Kconfig dependency nightmare

[Arnaldo Carvalho de Melo]

On 9/17/05, Harald Welte <laforge@netfilter.org> wrote:
> On Sat, Sep 17, 2005 at 02:18:28PM +0200, Roman Zippel wrote:
> > Since IP_NF_CONNTRACK_NETLINK is the one creating the dependency,
> > something like this should work:
> 
> yes, I agree.  Looking at the behaviour of "menuconfig", I think your
> suggestion solves the problem.  I didn't try to compile all the
> combinations, though.
> 
> I'll submit a patch via DaveM soon.

OK, I'll test it as soon as it appears here :-)

- Arnaldo