Re: 3.14-1 Compile Problem for 2.6.39.4 Kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 1, 2014 at 6:39 PM, Luis R. Rodriguez
<mcgrof@xxxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe backports" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux