Hi all,
After a glibc update to 2.29, my 4.14 builds started failing like so:
$ make -j$(nproc) defconfig bzImage HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o SHIPPED scripts/kconfig/zconf.tab.c SHIPPED scripts/kconfig/zconf.lex.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf *** Default configuration is based on 'x86_64_defconfig' # # configuration written to .config # scripts/kconfig/conf --silentoldconfig Kconfig SYSTBL arch/x86/include/generated/asm/syscalls_32.h SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h SYSTBL arch/x86/include/generated/asm/syscalls_64.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h UPD include/generated/uapi/linux/version.h DESCEND objtool HOSTCC /home/nathan/cbl/linux-stable/tools/objtool/fixdep.o HOSTLD /home/nathan/cbl/linux-stable/tools/objtool/fixdep-in.o LINK /home/nathan/cbl/linux-stable/tools/objtool/fixdep CC /home/nathan/cbl/linux-stable/tools/objtool/builtin-check.o CC /home/nathan/cbl/linux-stable/tools/objtool/builtin-orc.o CC /home/nathan/cbl/linux-stable/tools/objtool/check.o CC /home/nathan/cbl/linux-stable/tools/objtool/orc_gen.o CC /home/nathan/cbl/linux-stable/tools/objtool/orc_dump.o CC /home/nathan/cbl/linux-stable/tools/objtool/elf.o CC /home/nathan/cbl/linux-stable/tools/objtool/special.o GEN /home/nathan/cbl/linux-stable/tools/objtool/arch/x86/lib/inat-tables.c CC /home/nathan/cbl/linux-stable/tools/objtool/objtool.o CC /home/nathan/cbl/linux-stable/tools/objtool/libstring.o CC /home/nathan/cbl/linux-stable/tools/objtool/str_error_r.o CC /home/nathan/cbl/linux-stable/tools/objtool/exec-cmd.o CC /home/nathan/cbl/linux-stable/tools/objtool/pager.o CC /home/nathan/cbl/linux-stable/tools/objtool/help.o CC /home/nathan/cbl/linux-stable/tools/objtool/parse-options.o CC /home/nathan/cbl/linux-stable/tools/objtool/run-command.o CC /home/nathan/cbl/linux-stable/tools/objtool/sigchain.o CC /home/nathan/cbl/linux-stable/tools/objtool/subcmd-config.o CC /home/nathan/cbl/linux-stable/tools/objtool/arch/x86/decode.o LD /home/nathan/cbl/linux-stable/tools/objtool/libsubcmd-in.o LD /home/nathan/cbl/linux-stable/tools/objtool/arch/x86/objtool-in.o LD /home/nathan/cbl/linux-stable/tools/objtool/objtool-in.o AR /home/nathan/cbl/linux-stable/tools/objtool/libsubcmd.a LINK /home/nathan/cbl/linux-stable/tools/objtool/objtool UPD include/config/kernel.release HOSTCC arch/x86/tools/relocs_32.o HOSTCC arch/x86/tools/relocs_common.o HOSTCC arch/x86/tools/relocs_64.o WRAP arch/x86/include/generated/asm/dma-contiguous.h WRAP arch/x86/include/generated/asm/mcs_spinlock.h WRAP arch/x86/include/generated/asm/clkdev.h WRAP arch/x86/include/generated/asm/mm-arch-hooks.h WRAP arch/x86/include/generated/asm/early_ioremap.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h HOSTCC scripts/kallsyms HOSTCC scripts/pnmtologo HOSTCC scripts/conmakehash HOSTCC scripts/sortextable CC scripts/mod/empty.o CC scripts/mod/devicetable-offsets.s HOSTCC scripts/mod/mk_elfconfig HOSTCC scripts/selinux/mdp/mdp HOSTCC scripts/selinux/genheaders/genheaders In file included from scripts/selinux/genheaders/genheaders.c:19: ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~ make[4]: *** [scripts/Makefile.host:102: scripts/selinux/genheaders/genheaders] Error 1 make[3]: *** [scripts/Makefile.build:585: scripts/selinux/genheaders] Error 2 make[3]: *** Waiting for unfinished jobs.... In file included from scripts/selinux/mdp/mdp.c:49: ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~ make[4]: *** [scripts/Makefile.host:102: scripts/selinux/mdp/mdp] Error 1 make[3]: *** [scripts/Makefile.build:585: scripts/selinux/mdp] Error 2 make[2]: *** [scripts/Makefile.build:585: scripts/selinux] Error 2 make[2]: *** Waiting for unfinished jobs.... HOSTLD arch/x86/tools/relocs CHK scripts/mod/devicetable-offsets.h UPD scripts/mod/devicetable-offsets.h MKELF scripts/mod/elfconfig.h HOSTCC scripts/mod/modpost.o HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/sumversion.o CHK include/generated/timeconst.h CC kernel/bounds.s UPD include/generated/timeconst.h CHK include/generated/bounds.h UPD include/generated/bounds.h CC arch/x86/kernel/asm-offsets.s HOSTLD scripts/mod/modpost make[1]: *** [Makefile:572: scripts] Error 2 make[1]: *** Waiting for unfinished jobs.... CHK include/generated/asm-offsets.h UPD include/generated/asm-offsets.h CALL scripts/checksyscalls.sh make: *** [Makefile:264: __build_one_by_one] Error 2
This is due to commit c017c71ce09f ("selinux: include sys/socket.h in host programs to have PF_MAX") [1] in the kernel interacting poorly with glibc's commit 38b0593e9a ("Add PF_XDP, AF_XDP and SOL_XDP from Linux 4.18 to bits/socket.h.") [2]
I am not really sure how this should be fixed or who is at fault but I didn't see it reported anywhere yet (I assume the kernel) and I feel more comfortable on the kernel mailing list than other bug trackers so here we are.
[1]: https://git.kernel.org/linus/c017c71ce09f4c7a5378fccbec6a3d7e96b0c5c2 [2]: https://sourceware.org/git/?p=glibc.git%3Ba=commit%3Bh=38b0593e9a862c3b35392...
Thanks, Nathan
On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor natechancellor@gmail.com wrote:
Hi all,
After a glibc update to 2.29, my 4.14 builds started failing like so:
...
HOSTCC scripts/selinux/genheaders/genheaders In file included from scripts/selinux/genheaders/genheaders.c:19: ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~
This is a known problem that has a fix in the selinux/next branch and will be going up to Linus during the next merge window. The fix is quite small and should be relatively easy for you to backport to your kernel build if you are interested; the patch can be found at the archive link below:
https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac
On Mon, Apr 22, 2019 at 09:59:47PM -0400, Paul Moore wrote:
On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor natechancellor@gmail.com wrote:
Hi all,
After a glibc update to 2.29, my 4.14 builds started failing like so:
...
HOSTCC scripts/selinux/genheaders/genheaders In file included from scripts/selinux/genheaders/genheaders.c:19: ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~
This is a known problem that has a fix in the selinux/next branch and will be going up to Linus during the next merge window. The fix is quite small and should be relatively easy for you to backport to your kernel build if you are interested; the patch can be found at the archive link below:
https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac
-- paul moore www.paul-moore.com
Awesome, thank you! I will apply that for now and wait for it to get backported to stable after the next merge window.
I appreciate the quick response, Nathan
On Mon, Apr 22, 2019 at 09:59:47PM -0400, Paul Moore wrote:
On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor natechancellor@gmail.com wrote:
Hi all,
After a glibc update to 2.29, my 4.14 builds started failing like so:
...
HOSTCC scripts/selinux/genheaders/genheaders In file included from scripts/selinux/genheaders/genheaders.c:19: ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~
This is a known problem that has a fix in the selinux/next branch and will be going up to Linus during the next merge window. The fix is quite small and should be relatively easy for you to backport to your kernel build if you are interested; the patch can be found at the archive link below:
https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac
Why is it waiting for the next merge window? It fixes a build bug that people hit.
-- Thanks, Sasha
On Tue, Apr 23, 2019 at 9:29 AM Sasha Levin sashal@kernel.org wrote:
On Mon, Apr 22, 2019 at 09:59:47PM -0400, Paul Moore wrote:
On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor natechancellor@gmail.com wrote:
Hi all,
After a glibc update to 2.29, my 4.14 builds started failing like so:
...
HOSTCC scripts/selinux/genheaders/genheaders In file included from scripts/selinux/genheaders/genheaders.c:19: ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~
This is a known problem that has a fix in the selinux/next branch and will be going up to Linus during the next merge window. The fix is quite small and should be relatively easy for you to backport to your kernel build if you are interested; the patch can be found at the archive link below:
https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac
Why is it waiting for the next merge window? It fixes a build bug that people hit.
I place a reasonably high bar on patches that I send up to Linus outside of the merge window and I didn't feel this patch met that criteria. Nathan is only the second person I've seen who has encountered this problem, the first being the original patch author. As far as I've seen, the problem is only seen by users building older kernels on very new userspaces (e.g. glibc v2.29 was released in February 2019, Linux v4.14 was released in 2017); this doesn't appear to be a large group of people and I didn't want to risk breaking the main kernel tree during the -rcX phase for such a small group.
On Tue, Apr 23, 2019 at 09:43:09AM -0400, Paul Moore wrote:
On Tue, Apr 23, 2019 at 9:29 AM Sasha Levin sashal@kernel.org wrote:
On Mon, Apr 22, 2019 at 09:59:47PM -0400, Paul Moore wrote:
On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor natechancellor@gmail.com wrote:
Hi all,
After a glibc update to 2.29, my 4.14 builds started failing like so:
...
HOSTCC scripts/selinux/genheaders/genheaders In file included from scripts/selinux/genheaders/genheaders.c:19: ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~
This is a known problem that has a fix in the selinux/next branch and will be going up to Linus during the next merge window. The fix is quite small and should be relatively easy for you to backport to your kernel build if you are interested; the patch can be found at the archive link below:
https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac
Why is it waiting for the next merge window? It fixes a build bug that people hit.
I place a reasonably high bar on patches that I send up to Linus outside of the merge window and I didn't feel this patch met that criteria. Nathan is only the second person I've seen who has encountered this problem, the first being the original patch author. As far as I've seen, the problem is only seen by users building older kernels on very new userspaces (e.g. glibc v2.29 was released in February 2019, Linux v4.14 was released in 2017); this doesn't appear to be a large group of people and I didn't want to risk breaking the main kernel tree during the -rcX phase for such a small group.
Ugh, this breaks my local builds, I would recommend getting it to Linus sooner please.
thanks,
greg k-h
On Mon, Apr 29, 2019 at 8:40 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Apr 23, 2019 at 09:43:09AM -0400, Paul Moore wrote:
On Tue, Apr 23, 2019 at 9:29 AM Sasha Levin sashal@kernel.org wrote:
On Mon, Apr 22, 2019 at 09:59:47PM -0400, Paul Moore wrote:
On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor natechancellor@gmail.com wrote:
Hi all,
After a glibc update to 2.29, my 4.14 builds started failing like so:
...
HOSTCC scripts/selinux/genheaders/genheaders In file included from scripts/selinux/genheaders/genheaders.c:19: ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~
This is a known problem that has a fix in the selinux/next branch and will be going up to Linus during the next merge window. The fix is quite small and should be relatively easy for you to backport to your kernel build if you are interested; the patch can be found at the archive link below:
https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac
Why is it waiting for the next merge window? It fixes a build bug that people hit.
I place a reasonably high bar on patches that I send up to Linus outside of the merge window and I didn't feel this patch met that criteria. Nathan is only the second person I've seen who has encountered this problem, the first being the original patch author. As far as I've seen, the problem is only seen by users building older kernels on very new userspaces (e.g. glibc v2.29 was released in February 2019, Linux v4.14 was released in 2017); this doesn't appear to be a large group of people and I didn't want to risk breaking the main kernel tree during the -rcX phase for such a small group.
Ugh, this breaks my local builds, I would recommend getting it to Linus sooner please.
Well, we are at -rc7 right now and it looks like an -rc8 is unlikely so the question really comes down to can/do you want to wait a week?
On Mon, Apr 29, 2019 at 10:02:29AM -0400, Paul Moore wrote:
On Mon, Apr 29, 2019 at 8:40 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Apr 23, 2019 at 09:43:09AM -0400, Paul Moore wrote:
On Tue, Apr 23, 2019 at 9:29 AM Sasha Levin sashal@kernel.org wrote:
On Mon, Apr 22, 2019 at 09:59:47PM -0400, Paul Moore wrote:
On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor natechancellor@gmail.com wrote:
Hi all,
After a glibc update to 2.29, my 4.14 builds started failing like so:
...
HOSTCC scripts/selinux/genheaders/genheaders In file included from scripts/selinux/genheaders/genheaders.c:19: ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. #error New address family defined, please update secclass_map. ^~~~~
This is a known problem that has a fix in the selinux/next branch and will be going up to Linus during the next merge window. The fix is quite small and should be relatively easy for you to backport to your kernel build if you are interested; the patch can be found at the archive link below:
https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac
Why is it waiting for the next merge window? It fixes a build bug that people hit.
I place a reasonably high bar on patches that I send up to Linus outside of the merge window and I didn't feel this patch met that criteria. Nathan is only the second person I've seen who has encountered this problem, the first being the original patch author. As far as I've seen, the problem is only seen by users building older kernels on very new userspaces (e.g. glibc v2.29 was released in February 2019, Linux v4.14 was released in 2017); this doesn't appear to be a large group of people and I didn't want to risk breaking the main kernel tree during the -rcX phase for such a small group.
Ugh, this breaks my local builds, I would recommend getting it to Linus sooner please.
Well, we are at -rc7 right now and it looks like an -rc8 is unlikely so the question really comes down to can/do you want to wait a week?
It's a regression in the 5.1-rc tree, that is hitting people now. Why do you want to have a 5.1-final that is known to be broken?
thanks,
greg k-h
On Mon, Apr 29, 2019 at 10:09 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Apr 29, 2019 at 10:02:29AM -0400, Paul Moore wrote:
On Mon, Apr 29, 2019 at 8:40 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Apr 23, 2019 at 09:43:09AM -0400, Paul Moore wrote:
On Tue, Apr 23, 2019 at 9:29 AM Sasha Levin sashal@kernel.org wrote:
On Mon, Apr 22, 2019 at 09:59:47PM -0400, Paul Moore wrote:
On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor natechancellor@gmail.com wrote: > Hi all, > > After a glibc update to 2.29, my 4.14 builds started failing like so:
...
> HOSTCC scripts/selinux/genheaders/genheaders > In file included from scripts/selinux/genheaders/genheaders.c:19: > ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. > #error New address family defined, please update secclass_map. > ^~~~~
This is a known problem that has a fix in the selinux/next branch and will be going up to Linus during the next merge window. The fix is quite small and should be relatively easy for you to backport to your kernel build if you are interested; the patch can be found at the archive link below:
https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac
Why is it waiting for the next merge window? It fixes a build bug that people hit.
I place a reasonably high bar on patches that I send up to Linus outside of the merge window and I didn't feel this patch met that criteria. Nathan is only the second person I've seen who has encountered this problem, the first being the original patch author. As far as I've seen, the problem is only seen by users building older kernels on very new userspaces (e.g. glibc v2.29 was released in February 2019, Linux v4.14 was released in 2017); this doesn't appear to be a large group of people and I didn't want to risk breaking the main kernel tree during the -rcX phase for such a small group.
Ugh, this breaks my local builds, I would recommend getting it to Linus sooner please.
Well, we are at -rc7 right now and it looks like an -rc8 is unlikely so the question really comes down to can/do you want to wait a week?
It's a regression in the 5.1-rc tree, that is hitting people now. Why do you want to have a 5.1-final that is known to be broken?
I believe I answered that in my reply to Sasha. Can you answer the question I asked of you above?
On Mon, Apr 29, 2019 at 10:47:00AM -0400, Paul Moore wrote:
On Mon, Apr 29, 2019 at 10:09 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Apr 29, 2019 at 10:02:29AM -0400, Paul Moore wrote:
On Mon, Apr 29, 2019 at 8:40 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Apr 23, 2019 at 09:43:09AM -0400, Paul Moore wrote:
On Tue, Apr 23, 2019 at 9:29 AM Sasha Levin sashal@kernel.org wrote:
On Mon, Apr 22, 2019 at 09:59:47PM -0400, Paul Moore wrote: >On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor >natechancellor@gmail.com wrote: >> Hi all, >> >> After a glibc update to 2.29, my 4.14 builds started failing like so: > >... > >> HOSTCC scripts/selinux/genheaders/genheaders >> In file included from scripts/selinux/genheaders/genheaders.c:19: >> ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. >> #error New address family defined, please update secclass_map. >> ^~~~~ > >This is a known problem that has a fix in the selinux/next branch and >will be going up to Linus during the next merge window. The fix is >quite small and should be relatively easy for you to backport to your >kernel build if you are interested; the patch can be found at the >archive link below: > >https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac
Why is it waiting for the next merge window? It fixes a build bug that people hit.
I place a reasonably high bar on patches that I send up to Linus outside of the merge window and I didn't feel this patch met that criteria. Nathan is only the second person I've seen who has encountered this problem, the first being the original patch author. As far as I've seen, the problem is only seen by users building older kernels on very new userspaces (e.g. glibc v2.29 was released in February 2019, Linux v4.14 was released in 2017); this doesn't appear to be a large group of people and I didn't want to risk breaking the main kernel tree during the -rcX phase for such a small group.
Ugh, this breaks my local builds, I would recommend getting it to Linus sooner please.
Well, we are at -rc7 right now and it looks like an -rc8 is unlikely so the question really comes down to can/do you want to wait a week?
It's a regression in the 5.1-rc tree, that is hitting people now. Why do you want to have a 5.1-final that is known to be broken?
I believe I answered that in my reply to Sasha. Can you answer the question I asked of you above?
If you don't submit it this week, I guess I can wait as I have no other choice.
But note, this did break my build systems, and my main development system this weekend. So yes, the number of people being affected might be "small", but that "small" number includes the people responsible for maintaining those stable kernels :(
Anyway, it's your call, just letting you know I'm really annoyed at the moment by this...
greg k-h
On Mon, Apr 29, 2019 at 10:52 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Apr 29, 2019 at 10:47:00AM -0400, Paul Moore wrote:
On Mon, Apr 29, 2019 at 10:09 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Apr 29, 2019 at 10:02:29AM -0400, Paul Moore wrote:
On Mon, Apr 29, 2019 at 8:40 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Apr 23, 2019 at 09:43:09AM -0400, Paul Moore wrote:
On Tue, Apr 23, 2019 at 9:29 AM Sasha Levin sashal@kernel.org wrote: > On Mon, Apr 22, 2019 at 09:59:47PM -0400, Paul Moore wrote: > >On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor > >natechancellor@gmail.com wrote: > >> Hi all, > >> > >> After a glibc update to 2.29, my 4.14 builds started failing like so: > > > >... > > > >> HOSTCC scripts/selinux/genheaders/genheaders > >> In file included from scripts/selinux/genheaders/genheaders.c:19: > >> ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. > >> #error New address family defined, please update secclass_map. > >> ^~~~~ > > > >This is a known problem that has a fix in the selinux/next branch and > >will be going up to Linus during the next merge window. The fix is > >quite small and should be relatively easy for you to backport to your > >kernel build if you are interested; the patch can be found at the > >archive link below: > > > >https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac > > Why is it waiting for the next merge window? It fixes a build bug that > people hit.
I place a reasonably high bar on patches that I send up to Linus outside of the merge window and I didn't feel this patch met that criteria. Nathan is only the second person I've seen who has encountered this problem, the first being the original patch author. As far as I've seen, the problem is only seen by users building older kernels on very new userspaces (e.g. glibc v2.29 was released in February 2019, Linux v4.14 was released in 2017); this doesn't appear to be a large group of people and I didn't want to risk breaking the main kernel tree during the -rcX phase for such a small group.
Ugh, this breaks my local builds, I would recommend getting it to Linus sooner please.
Well, we are at -rc7 right now and it looks like an -rc8 is unlikely so the question really comes down to can/do you want to wait a week?
It's a regression in the 5.1-rc tree, that is hitting people now. Why do you want to have a 5.1-final that is known to be broken?
I believe I answered that in my reply to Sasha. Can you answer the question I asked of you above?
If you don't submit it this week, I guess I can wait as I have no other choice.
But note, this did break my build systems, and my main development system this weekend. So yes, the number of people being affected might be "small", but that "small" number includes the people responsible for maintaining those stable kernels :(
Anyway, it's your call, just letting you know I'm really annoyed at the moment by this...
It's against my better judgement, but I'll send a PR up to Linus now.
On Mon, Apr 29, 2019 at 06:37:03PM -0400, Paul Moore wrote:
On Mon, Apr 29, 2019 at 10:52 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Apr 29, 2019 at 10:47:00AM -0400, Paul Moore wrote:
On Mon, Apr 29, 2019 at 10:09 AM Greg KH gregkh@linuxfoundation.org wrote:
On Mon, Apr 29, 2019 at 10:02:29AM -0400, Paul Moore wrote:
On Mon, Apr 29, 2019 at 8:40 AM Greg KH gregkh@linuxfoundation.org wrote:
On Tue, Apr 23, 2019 at 09:43:09AM -0400, Paul Moore wrote: > On Tue, Apr 23, 2019 at 9:29 AM Sasha Levin sashal@kernel.org wrote: > > On Mon, Apr 22, 2019 at 09:59:47PM -0400, Paul Moore wrote: > > >On Mon, Apr 22, 2019 at 5:00 PM Nathan Chancellor > > >natechancellor@gmail.com wrote: > > >> Hi all, > > >> > > >> After a glibc update to 2.29, my 4.14 builds started failing like so: > > > > > >... > > > > > >> HOSTCC scripts/selinux/genheaders/genheaders > > >> In file included from scripts/selinux/genheaders/genheaders.c:19: > > >> ./security/selinux/include/classmap.h:245:2: error: #error New address family defined, please update secclass_map. > > >> #error New address family defined, please update secclass_map. > > >> ^~~~~ > > > > > >This is a known problem that has a fix in the selinux/next branch and > > >will be going up to Linus during the next merge window. The fix is > > >quite small and should be relatively easy for you to backport to your > > >kernel build if you are interested; the patch can be found at the > > >archive link below: > > > > > >https://lore.kernel.org/selinux/20190225005528.28371-1-paulo@paulo.ac > > > > Why is it waiting for the next merge window? It fixes a build bug that > > people hit. > > I place a reasonably high bar on patches that I send up to Linus > outside of the merge window and I didn't feel this patch met that > criteria. Nathan is only the second person I've seen who has > encountered this problem, the first being the original patch author. > As far as I've seen, the problem is only seen by users building older > kernels on very new userspaces (e.g. glibc v2.29 was released in > February 2019, Linux v4.14 was released in 2017); this doesn't appear > to be a large group of people and I didn't want to risk breaking the > main kernel tree during the -rcX phase for such a small group.
Ugh, this breaks my local builds, I would recommend getting it to Linus sooner please.
Well, we are at -rc7 right now and it looks like an -rc8 is unlikely so the question really comes down to can/do you want to wait a week?
It's a regression in the 5.1-rc tree, that is hitting people now. Why do you want to have a 5.1-final that is known to be broken?
I believe I answered that in my reply to Sasha. Can you answer the question I asked of you above?
If you don't submit it this week, I guess I can wait as I have no other choice.
But note, this did break my build systems, and my main development system this weekend. So yes, the number of people being affected might be "small", but that "small" number includes the people responsible for maintaining those stable kernels :(
Anyway, it's your call, just letting you know I'm really annoyed at the moment by this...
It's against my better judgement, but I'll send a PR up to Linus now.
Thank you for doing so,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Nathan Chancellor -
Paul Moore -
Sasha Levin