3.14-1 Compile Problem for 2.6.39.4 Kernel

3.14-1 Compile Problem for 2.6.39.4 Kernel

[Aaron Hamilton]

In trying to compile backports-3.14-1 with a 2.6.39.4 kernel, I get
the following compilation errors:

backport-include/linux/compat.h:18: error: expected ';', ',' or ')'
before '*' token

If I comment out line 18 in compat.h which just reads "extern int
compat_put_timespec(const struct timespec*, void __user *)", then I
get past that error.

Next, things get stuck on compat/crypto-ccm.c on lines 250 and 255,
stating "too few arguments to function 'scatterwalk_map'" and "too few
arguments to function 'scatterwalk_unmap'".

My kernel headers indicate this function takes two parameters and I
can't find anything in backports that specify otherwise. Am I missing
something?

Re: 3.14-1 Compile Problem for 2.6.39.4 Kernel

[Luis R. Rodriguez]

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

On Tue, Apr 29, 2014 at 02:39:11AM -0700, Aaron Hamilton wrote:
> In trying to compile backports-3.14-1 with a 2.6.39.4 kernel, I get
> the following compilation errors:
> 
> backport-include/linux/compat.h:18: error: expected ';', ',' or ')'
> before '*' token
> 
> If I comment out line 18 in compat.h which just reads "extern int
> compat_put_timespec(const struct timespec*, void __user *)", then I
> get past that error.
> 
> Next, things get stuck on compat/crypto-ccm.c on lines 250 and 255,
> stating "too few arguments to function 'scatterwalk_map'" and "too few
> arguments to function 'scatterwalk_unmap'".
> 
> My kernel headers indicate this function takes two parameters and I
> can't find anything in backports that specify otherwise. Am I missing
> something?

Yeah odd, I see what you are seeing but then I looked at upstream
v3.14.2 code and see only one argument.

The commit that caused this change:

mcgrof@ergon ~/linux-stable (git::linux-3.14.y)$ git describe --contains f0dfc0b0
v3.4-rc1~174^2~50

So its been there for a while now, so surprised we haven't had to
resolve this earlier, we also don't have patches that modify this so
its a bit unclear how this has happened. The backports file versions
does have:

BACKPORTS_VERSION="v3.14-1-0-g369d49a"
BACKPORTED_KERNEL_VERSION="v3.14-0-g455c6fd"
BACKPORTED_KERNEL_NAME="Linux"

And v3.14-0-g455c6fd is == v3.14

The upstream code for v3.14 on crypto/ccm.c has scatterwalk_map() with
one argument. What we do is copy it over directly from the upstream
source the only patch we have to modify it is within the backports
git tree we use patches/backport-adjustments/crypto-ccm.patch, this
however does not touch scatterwalk_map() usage...

This *should* have triggered a compile failure when we had tested this..
Going to run another test now.

  Luis

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

Re: 3.14-1 Compile Problem for 2.6.39.4 Kernel

[Luis R. Rodriguez]

On Thu, May 1, 2014 at 6:39 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> This *should* have triggered a compile failure when we had tested this..
> Going to run another test now.

I reran the compile test with ckmake and a fresh pull of code and I
get the same results.

1   2.6.25              [  OK  ]
2   2.6.26              [  OK  ]
3   2.6.27              [  OK  ]
4   2.6.28              [  OK  ]
5   2.6.29              [  OK  ]
6   2.6.30              [  OK  ]
7   2.6.31              [  OK  ]
8   2.6.32              [  OK  ]
9   2.6.33              [  OK  ]
10  2.6.34              [  OK  ]
11  2.6.35              [  OK  ]
12  2.6.36              [  OK  ]
13  2.6.37              [  OK  ]
14  2.6.38              [  OK  ]
15  2.6.39              [  OK  ]
16  3.0.101             [  OK  ]
17  3.1.10              [  OK  ]
18  3.2.54              [  OK  ]
19  3.3.8               [  OK  ]
20  3.4.79              [  OK  ]
21  3.5.7               [  OK  ]
22  3.6.11              [  OK  ]
23  3.7.10              [  OK  ]
24  3.8.13              [  OK  ]
25  3.9.11              [  OK  ]
26  3.10.29             [  OK  ]
27  3.11.10             [  OK  ]
28  3.12.10             [  OK  ]
29  3.13.2              [  OK  ]
30  3.14-rc1            [  OK  ]

real    35m40.235s
user    990m33.700s
sys     115m19.584s

This time I checked the logs and I don't see crypto_ccm being
compiled, even though ckmake --allyesconfig was used, which should
enable *everything*. We can look at the Makefile to see what symbol
defines it:

mcgrof@drvbp1 ~/build/backports-3.14-test $ grep crypto-ccm compat/Makefile
compat-$(CPTCFG_BACKPORT_BUILD_CRYPTO_CCM) += crypto-ccm.o
compat-$(CPTCFG_BACKPORT_BUILD_CRYPTO_CCM) += crypto-ccm.o

For some reason there are two entries but it doesn't matter for this
case as that would not have presented an issue. Then we can look at
compat/Kconfig to see what options enable it:

config BACKPORT_BUILD_CRYPTO_CCM
        bool
        default n if CRYPTO_CCM
        default y if BACKPORT_CRYPTO_CCM
        #c-file crypto/ccm.c

The c-file line here is used by gentree.py to copy the upstream linux
crypto/ccm.c file over to compat/crypto-ccm.c. Next we look at who
enables this on the code then:

mcgrof@drvbp1 ~/build/backports-3.14-test $ grep -nHr BACKPORT_CRYPTO_CCM
.local-symbols:28:BACKPORT_CRYPTO_CCM=
net/mac80211/Kconfig:8: select BACKPORT_CRYPTO_CCM
compat/Kconfig:183:config BACKPORT_CRYPTO_CCM
compat/Kconfig:189:     default y if BACKPORT_CRYPTO_CCM

So only mac80211 would ever have enabled this. Here's the full entry:

config MAC80211
        tristate "Generic IEEE 802.11 Networking Stack (mac80211)"
        depends on m
        depends on CFG80211
        depends on CRYPTO
        depends on CRYPTO_ARC4
        depends on CRYPTO_AES
        select BACKPORT_CRYPTO_CCM
        depends on CRC32
        select BACKPORT_AVERAGE
        ---help---
          This option enables the hardware independent IEEE 802.11
          networking stack.

The logs show mac80211 being compiled but not crypto-ccm, something is
fishy here.

  Luis

Re: 3.14-1 Compile Problem for 2.6.39.4 Kernel

[Aaron Hamilton]

If I recall correctly, I was able to get this to compile by enabling
CONFIG_CRYPTO_CCM in my kernel. Without it, it won't compile.

On Thu, May 1, 2014 at 6:39 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> On Tue, Apr 29, 2014 at 02:39:11AM -0700, Aaron Hamilton wrote:
>> In trying to compile backports-3.14-1 with a 2.6.39.4 kernel, I get
>> the following compilation errors:
>>
>> backport-include/linux/compat.h:18: error: expected ';', ',' or ')'
>> before '*' token
>>
>> If I comment out line 18 in compat.h which just reads "extern int
>> compat_put_timespec(const struct timespec*, void __user *)", then I
>> get past that error.
>>
>> Next, things get stuck on compat/crypto-ccm.c on lines 250 and 255,
>> stating "too few arguments to function 'scatterwalk_map'" and "too few
>> arguments to function 'scatterwalk_unmap'".
>>
>> My kernel headers indicate this function takes two parameters and I
>> can't find anything in backports that specify otherwise. Am I missing
>> something?
>
> Yeah odd, I see what you are seeing but then I looked at upstream
> v3.14.2 code and see only one argument.
>
> The commit that caused this change:
>
> mcgrof@ergon ~/linux-stable (git::linux-3.14.y)$ git describe --contains f0dfc0b0
> v3.4-rc1~174^2~50
>
> So its been there for a while now, so surprised we haven't had to
> resolve this earlier, we also don't have patches that modify this so
> its a bit unclear how this has happened. The backports file versions
> does have:
>
> BACKPORTS_VERSION="v3.14-1-0-g369d49a"
> BACKPORTED_KERNEL_VERSION="v3.14-0-g455c6fd"
> BACKPORTED_KERNEL_NAME="Linux"
>
> And v3.14-0-g455c6fd is == v3.14
>
> The upstream code for v3.14 on crypto/ccm.c has scatterwalk_map() with
> one argument. What we do is copy it over directly from the upstream
> source the only patch we have to modify it is within the backports
> git tree we use patches/backport-adjustments/crypto-ccm.patch, this
> however does not touch scatterwalk_map() usage...
>
> This *should* have triggered a compile failure when we had tested this..
> Going to run another test now.
>
>   Luis

Re: 3.14-1 Compile Problem for 2.6.39.4 Kernel

[Luis R. Rodriguez]

On Fri, May 2, 2014 at 1:36 AM, Aaron Hamilton
<aaron@logicdatasystems.net> wrote:
> If I recall correctly, I was able to get this to compile by enabling
> CONFIG_CRYPTO_CCM in my kernel. Without it, it won't compile.

Yeah that would do it:

mcgrof@drvbp1 ~/ksrc-backports $ grep CRYPTO_CCM
lib/modules/2.6.39-02063904-generic/build/.config
CONFIG_CRYPTO_CCM=m

Unfortunately right now we don't compile tests against random configs
but as you can imagine doing so would take quite a bit of time. Even
so, we need a way to be able to nudge the config a bit to compile
everything we do expect to ship without compromising the config
enough. That might be tricky, best I can say for now is that we do
need a bit more review / help with alternative base configs.

  Luis