Subject: Re: [vserver] Kernel build failures with IPv6 as a module
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Sat, 3 Nov 2018 21:08:31 +0100

On Sat, Nov 03, 2018 at 06:53:10PM +0000, Chris Richardson wrote:
> On Sat, 3 Nov 2018 at 17:36, Herbert Poetzl <herbert@13thfloor.at> wrote:

>> On Sat, Nov 03, 2018 at 11:28:47AM +0000, Chris Richardson wrote:
>>> Hi Herbert, thanks for your response!

>> You're welcome!

>>> On Sat, 3 Nov 2018 at 11:14, Herbert Poetzl <herbert@13thfloor.at> wrote:

>>>> On Fri, Nov 02, 2018 at 11:29:01PM +0000, Chris Richardson wrote:
>>>>> Hi,

>>>> Hey Chris,

>>>>> I'm getting a build failure after applying any of the most
>>>>> recent vserver patches, for instance
>>>>> http://vserver.13thfloor.at/Experimental/patch-4.9.135-vs2.3.9.8.diff.

>>>>> I've tracked the cause down to the fact that I have IPv6 support
>>>>> configured as a module and the vserver code uses statements like

>>>>> #if CONFIG_IPV6
>>>>> rather than the kernel macro
>>>>> #if IS_ENABLED(CONFIG_IPV6)

>>>> It is definitely a bug somewhere in the config system as
>>>> Linux-VServer should force IPv6 to 'y' or 'n' and disallow
>>>> building it as a module.

>>>>> I'm wondering if this a bug, or if it perhaps not make
>>>>> sense to configure IPv6 as a module in the vserver context?

>>>> Building IPv6 as a module is currently not supported by
>>>> Linux-VServer, so it doesn't make sense to do that with
>>>> the Linux-VServer patches but as I implied, the build
>>>> system should take care of this and prevent you from
>>>> selecting 'm' in the first place.

>>>> I'd appreciate if you could upload (or attach) the .config
>>>> you are using so that we can figure out why the build
>>>> system doesn't prevent you from building IPv6 as a module.

>>> This makes me realise that I'm doing everything wrong - my
>>> approach has been to manually patch my kernel source and
>>> manually configure the kernel, ie. I'm not using the build
>>> system to which you refer - I guess I should be.

>> You might not be as wrong as you think, because I was referring
>> to the Kernel Build System, which you are very likely using
>> after all.

>> Note there is nothing wrong with manually patching and then
>> (manually or not) configuring the kernel according to your needs.

>> But just to make sure, maybe you could describe what you did
>> and as suggested, provide your .config file for us to reproduce
>> the issue.

> Ah, I see what you mean now. The way I might have been jinxing
> the system was by applying the vserver patch and then copying
> in a kernel config which I had previously created - with IPv6
> as a module.

This should also be fine, as the kernel should run at least
'make oldconfig' when presented with a .config file.

> My config is attached, now with IPv6 enabled. I'm not sure
> it'll be of great interest though, it's a pretty generic one.

Will check shortly.

> Following what you said above regarding disabling of the module
> option, I've tried configuring from scratch and can reproduce as
> follows:

> wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.135.tar.xz
> tar xf linux-4.9.135.tar.xz
> cd linux-4.9.135/
> wget http://vserver.13thfloor.at/Experimental/patch-4.9.135-vs2.3.9.8.diff
> patch -p1 < patch-4.9.135-vs2.3.9.8.diff
> make menuconfig  # <- allows selecting IPv6 as a module
> make xconfig  # <- also allows selecting IPv6 as a module

Those should not allow the selection or at least map the
'm' to a 'y' when selected. This is clearly a bug.

> make -j12 # fails if IPv6 is selected as a module with the following output

> Output:
> In file included from net/ipv6/inet6_hashtables.c:19:0:
> ./include/linux/vs_inet6.h:239:30: warning: ‘struct in_ifaddr’
> declared inside parameter list will not be visible outside of this
> definition or declaration
>  int v6_ifa_in_nx_info(struct in_ifaddr *a, struct nx_info *n)
>                               ^~~~~~~~~
> net/ipv6/inet6_hashtables.c: In function ‘ipv6_rcv_saddr_equal’:
> net/ipv6/inet6_hashtables.c:320:47: warning: passing argument 2 of
> ‘nx_v6_addr_conflict’ makes integer from pointer without a cast
> [-Wint-conversion]
>    return nx_v6_addr_conflict(sk1->sk_nx_info, sk2->sk_nx_info);
>                                                ^~~
> In file included from net/ipv6/inet6_hashtables.c:19:0:
> ./include/linux/vs_inet6.h:233:5: note: expected ‘uint32_t {aka
> unsigned int}’ but argument is of type ‘struct nx_info * const’
>  int nx_v6_addr_conflict(struct nx_info *n, uint32_t a, const struct sock *s)
>      ^~~~~~~~~~~~~~~~~~~
> net/ipv6/inet6_hashtables.c:320:10: error: too few arguments to
> function ‘nx_v6_addr_conflict’
>    return nx_v6_addr_conflict(sk1->sk_nx_info, sk2->sk_nx_info);
>           ^~~~~~~~~~~~~~~~~~~
> In file included from net/ipv6/inet6_hashtables.c:19:0:
> ./include/linux/vs_inet6.h:233:5: note: declared here
>  int nx_v6_addr_conflict(struct nx_info *n, uint32_t a, const struct sock *s)

> My interpretation of this is that the precompiler takes the
> wrong sections of code because it's expecting CONFIG_IPV6 to be
> set rather than CONFIG_IPV6_MODULE (as per my OP).

It won't work as module, even if the conditions are correct
because there are some network related parts which cannot
be moved out of the kernel but having IPv6 as module would
require those to be 'optional'.

Best,
Herbert

> HTH!
> Chris


>>> So actually the only problem is between my keyboard and chair.

>> Not convinced yet :)

>>> Thanks again for your help!

>> You're welcome!

>> Best,
>> Herbert

>>>>> Apologies if I'm asking a stupid question, I'm new to vserver!

>>>> There are no stupid questions, just stupid answers.

>>>> Welcome to Linux-VServer!

>>>> Best,
>>>> Herbert

>>>>> --

>>>>> Chris Richardson, System Architect
>>>>> cr@fourc.eu

>>>>> FourC AS, Vestre Rosten 81, Trekanten, NO-7075 Tiller, Norway
>>>>> www.fourc.eu

>>>>> Follow us on LinkedIn, Facebook, Google+ and Twitter!



>>> --

>>> Chris Richardson, System Architect
>>> cr@fourc.eu

>>> FourC AS, Vestre Rosten 81, Trekanten, NO-7075 Tiller, Norway
>>> www.fourc.eu

>>> Follow us on LinkedIn, Facebook, Google+ and Twitter!



> -- 

> Chris Richardson, System Architect
> cr@fourc.eu

> FourC AS, Vestre Rosten 81, Trekanten, NO-7075 Tiller, Norway
> www.fourc.eu

> Follow us on LinkedIn, Facebook, Google+ and Twitter!