Bug 1313404

Summary: Test suite failure: elf/tst-audit10 and elf/tst-audit4
Product: [Fedora] Fedora Reporter: Carlos O'Donell <codonell>
Component: glibcAssignee: Florian Weimer <fweimer>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: arjun.is, codonell, dj, fweimer, jakub, law, mfabian, pfrankli, siddhesh
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: glibc-2.22-15.fc23, glibc-2.23.1-7.fc24 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-15 04:58:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Carlos O'Donell 2016-03-01 14:38:31 UTC
On x86_64 we have two failures in tst-audit10 and tst-audit4.

version: 1
objopen: 0,
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/ld-linux-x86-64.so.2
activity: add
objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod10a.so, LA_SET_ORIG
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod10a.so
objsearch: libc.so.6, LA_SET_ORIG
objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6, LA_SER_LIBPATH
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6
activity: consistent
symbind64: symname=__libc_start_main, st_value=0x7f89ce53bfd0, ndx=2118, flags=0
pltenter: symname=__libc_start_main, st_value=0x7f89ce53bfd0, ndx=2118, flags=0
preinit
symbind64: symname=mallopt, st_value=0x7f89ce5a6a60, ndx=1784, flags=0
pltenter: symname=mallopt, st_value=0x7f89ce5a6a60, ndx=1784, flags=0
symbind64: symname=getopt_long, st_value=0x7f89ce60f900, ndx=1439, flags=0
pltenter: symname=getopt_long, st_value=0x7f89ce60f900, ndx=1439, flags=0
symbind64: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0
pltenter: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0
symbind64: symname=strtoul, st_value=0x7f89ce558e80, ndx=1172, flags=0
pltenter: symname=strtoul, st_value=0x7f89ce558e80, ndx=1172, flags=0
pltenter: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0
symbind64: symname=setvbuf, st_value=0x7f89ce591e00, ndx=1882, flags=0
pltenter: symname=setvbuf, st_value=0x7f89ce591e00, ndx=1882, flags=0
symbind64: symname=__cxa_atexit, st_value=0x7f89ce557d20, ndx=815, flags=0
pltenter: symname=__cxa_atexit, st_value=0x7f89ce557d20, ndx=815, flags=0
pltenter: symname=getenv, st_value=0x7f89ce557230, ndx=1310, flags=0
symbind64: symname=fork, st_value=0x7f89ce5f0250, ndx=411, flags=0
pltenter: symname=fork, st_value=0x7f89ce5f0250, ndx=411, flags=0
symbind64: symname=signal, st_value=0x7f89ce552f20, ndx=398, flags=0
pltenter: symname=signal, st_value=0x7f89ce552f20, ndx=398, flags=0
symbind64: symname=alarm, st_value=0x7f89ce5f0110, ndx=1347, flags=0
pltenter: symname=alarm, st_value=0x7f89ce5f0110, ndx=1347, flags=0
pltenter: symname=signal, st_value=0x7f89ce552f20, ndx=398, flags=0
symbind64: symname=waitpid, st_value=0x7f89ce5eff70, ndx=1674, flags=0
pltenter: symname=waitpid, st_value=0x7f89ce5eff70, ndx=1674, flags=0
symbind64: symname=strsignal, st_value=0x7f89ce5af0d0, ndx=176, flags=0
pltenter: symname=strsignal, st_value=0x7f89ce5af0d0, ndx=176, flags=0
symbind64: symname=printf, st_value=0x7f89ce576200, ndx=603, flags=0
pltenter: symname=printf, st_value=0x7f89ce576200, ndx=603, flags=0
Didn't expect signal from child: got `Illegal instruction'
symbind64: symname=exit, st_value=0x7f89ce557ad0, ndx=128, flags=0
pltenter: symname=exit, st_value=0x7f89ce557ad0, ndx=128, flags=0
objclose
objclose
objclose
objclose

Notice the: "Didn't expect signal from child: got `Illegal instruction'"

version: 1
objopen: 0,
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/ld-linux-x86-64.so.2
activity: add
objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod4a.so, LA_SET_ORIG
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/elf/tst-auditmod4a.so
objsearch: libc.so.6, LA_SET_ORIG
objsearch: /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6, LA_SER_LIBPATH
objopen: 0, /builddir/build/BUILD/glibc-2.23-40-gde51ff8/build-x86_64-redhat-linux/libc.so.6
activity: consistent
symbind64: symname=__libc_start_main, st_value=0x7fba692eefd0, ndx=2118, flags=0
pltenter: symname=__libc_start_main, st_value=0x7fba692eefd0, ndx=2118, flags=0
preinit
symbind64: symname=mallopt, st_value=0x7fba69359a60, ndx=1784, flags=0
pltenter: symname=mallopt, st_value=0x7fba69359a60, ndx=1784, flags=0
symbind64: symname=getopt_long, st_value=0x7fba693c2900, ndx=1439, flags=0
pltenter: symname=getopt_long, st_value=0x7fba693c2900, ndx=1439, flags=0
symbind64: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0
pltenter: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0
symbind64: symname=strtoul, st_value=0x7fba6930be80, ndx=1172, flags=0
pltenter: symname=strtoul, st_value=0x7fba6930be80, ndx=1172, flags=0
pltenter: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0
symbind64: symname=setvbuf, st_value=0x7fba69344e00, ndx=1882, flags=0
pltenter: symname=setvbuf, st_value=0x7fba69344e00, ndx=1882, flags=0
symbind64: symname=__cxa_atexit, st_value=0x7fba6930ad20, ndx=815, flags=0
pltenter: symname=__cxa_atexit, st_value=0x7fba6930ad20, ndx=815, flags=0
pltenter: symname=getenv, st_value=0x7fba6930a230, ndx=1310, flags=0
symbind64: symname=fork, st_value=0x7fba693a3250, ndx=411, flags=0
pltenter: symname=fork, st_value=0x7fba693a3250, ndx=411, flags=0
symbind64: symname=signal, st_value=0x7fba69305f20, ndx=398, flags=0
pltenter: symname=signal, st_value=0x7fba69305f20, ndx=398, flags=0
symbind64: symname=alarm, st_value=0x7fba693a3110, ndx=1347, flags=0
pltenter: symname=alarm, st_value=0x7fba693a3110, ndx=1347, flags=0
pltenter: symname=signal, st_value=0x7fba69305f20, ndx=398, flags=0
symbind64: symname=waitpid, st_value=0x7fba693a2f70, ndx=1674, flags=0
pltenter: symname=waitpid, st_value=0x7fba693a2f70, ndx=1674, flags=0
symbind64: symname=strsignal, st_value=0x7fba693620d0, ndx=176, flags=0
pltenter: symname=strsignal, st_value=0x7fba693620d0, ndx=176, flags=0
symbind64: symname=printf, st_value=0x7fba69329200, ndx=603, flags=0
pltenter: symname=printf, st_value=0x7fba69329200, ndx=603, flags=0
Didn't expect signal from child: got `Illegal instruction'
symbind64: symname=exit, st_value=0x7fba6930aad0, ndx=128, flags=0
pltenter: symname=exit, st_value=0x7fba6930aad0, ndx=128, flags=0
objclose
objclose
objclose
objclose

Similarly for tst-audit4.

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           E5540  @ 2.53GHz
stepping        : 5
microcode       : 0x11
cpu MHz         : 1995.000
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm dtherm tpr_shadow vnmi flexpriority ept vpid
bugs            :
bogomips        : 5066.89
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management:

There are 16 processors.

Perhaps we have avx instruction leakage into the dynamic loader? This is a serious issue that needs review.

Comment 2 Florian Weimer 2016-03-01 14:58:43 UTC
As Joseph explained in the upstream bug, the tests is invalid.  We tell GCC to use instructions the host does not support:

AVX-CFLAGS=-mavx -mno-vzeroupper
CFLAGS-tst-audit4.c += $(AVX-CFLAGS)
CFLAGS-tst-auditmod4a.c += $(AVX-CFLAGS)
CFLAGS-tst-auditmod4b.c += $(AVX-CFLAGS)
CFLAGS-tst-auditmod6b.c += $(AVX-CFLAGS)
CFLAGS-tst-auditmod6c.c += $(AVX-CFLAGS)
CFLAGS-tst-auditmod7b.c += $(AVX-CFLAGS)
ifeq (yes,$(config-cflags-avx512))
AVX512-CFLAGS = -mavx512f
CFLAGS-tst-audit10.c += $(AVX512-CFLAGS)
CFLAGS-tst-auditmod10a.c += $(AVX512-CFLAGS)
CFLAGS-tst-auditmod10b.c += $(AVX512-CFLAGS)
endif
endif

And it turns out that sufficiently new GCC makes use of this permission.

I'm downgrading the urgency.  We need to fix this, but it is not a release blocker.

I'm going to ask for advice what we can do so that GCC can use the built-ins, but will not generate code for the new instructions.

Comment 3 Carlos O'Donell 2016-03-01 15:03:01 UTC
(In reply to Florian Weimer from comment #2)
> I'm downgrading the urgency.  We need to fix this, but it is not a release
> blocker.

Agreed.

> I'm going to ask for advice what we can do so that GCC can use the
> built-ins, but will not generate code for the new instructions.

This test needs to be marked UNSUPPORTED if the host lacks the instructions to execute it, just like C++ tests etc.

Comment 4 Carlos O'Donell 2016-03-01 15:03:38 UTC
(In reply to Carlos O'Donell from comment #3)
> > I'm going to ask for advice what we can do so that GCC can use the
> > built-ins, but will not generate code for the new instructions.
> 
> This test needs to be marked UNSUPPORTED if the host lacks the instructions
> to execute it, just like C++ tests etc.

Not host, but target rather (clarification required for cross-compiling).

Comment 5 Florian Weimer 2016-03-01 15:08:19 UTC
(In reply to Carlos O'Donell from comment #3)
> (In reply to Florian Weimer from comment #2)
> > I'm downgrading the urgency.  We need to fix this, but it is not a release
> > blocker.
> 
> Agreed.
> 
> > I'm going to ask for advice what we can do so that GCC can use the
> > built-ins, but will not generate code for the new instructions.
> 
> This test needs to be marked UNSUPPORTED if the host lacks the instructions
> to execute it, just like C++ tests etc.

There already is a run-time CPU feature test which causes the actual testing to be skipped if the CPU lacks the required micro-architecture support.  This should be good enough.  It doesn't work because it runs too late.

Our test harness currently does not support marking tests as UNSUPPORTED at run time, unfortunately.  It's just not powerful enough.

Related gcc-help query: https://gcc.gnu.org/ml/gcc-help/2016-03/msg00003.html

Comment 6 Carlos O'Donell 2016-03-01 15:52:21 UTC
(In reply to Florian Weimer from comment #5)
> (In reply to Carlos O'Donell from comment #3)
> > (In reply to Florian Weimer from comment #2)
> > > I'm downgrading the urgency.  We need to fix this, but it is not a release
> > > blocker.
> > 
> > Agreed.
> > 
> > > I'm going to ask for advice what we can do so that GCC can use the
> > > built-ins, but will not generate code for the new instructions.
> > 
> > This test needs to be marked UNSUPPORTED if the host lacks the instructions
> > to execute it, just like C++ tests etc.
> 
> There already is a run-time CPU feature test which causes the actual testing
> to be skipped if the CPU lacks the required micro-architecture support. 
> This should be good enough.  It doesn't work because it runs too late.
> 
> Our test harness currently does not support marking tests as UNSUPPORTED at
> run time, unfortunately.  It's just not powerful enough.

It does support UNSUPPORTED at run time. You must exit with reserved code 77 and scripts/evaluate-test.sh will mark it UNSUPPORTED. The test can do whatever testing it needs to determine at runtime (on the target) if it's unsupported.

Comment 7 Florian Weimer 2016-03-07 14:59:29 UTC
Patch posted upstream:

https://sourceware.org/ml/libc-alpha/2016-03/msg00147.html

Comment 8 Fedora Update System 2016-05-07 17:18:56 UTC
glibc-2.22-15.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-68abc0be35

Comment 9 Fedora Update System 2016-05-08 16:25:08 UTC
glibc-2.22-15.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-68abc0be35

Comment 10 Florian Weimer 2016-05-09 09:57:50 UTC
New 2.23 backports:

commit 4cf055a2a331b7361622dc9ac8993b59c6f0ef59
Author: Florian Weimer <fweimer>
Date:   Fri Mar 25 11:11:42 2016 +0100

    tst-audit10: Fix compilation on compilers without bit_AVX512F [BZ #19860]
    
        [BZ# 19860]
        * sysdeps/x86_64/tst-audit10.c (avx512_enabled): Always return
        zero if the compiler does not provide the AVX512F bit.
    
    (cherry picked from commit f327f5b47be57bc05a4077344b381016c1bb2c11)

commit d603d94994a1d326ebc9e93c8be892acc834a114
Author: Roland McGrath <roland.com>
Date:   Tue Mar 8 12:31:13 2016 -0800

    Fix tst-audit10 build when -mavx512f is not supported.
    
    (cherry picked from commit 3bd80c0de2f8e7ca8020d37739339636d169957e)

commit 7fa9775594b1592dfcdad5bc32ea449882ca9d9a
Author: Florian Weimer <fweimer>
Date:   Mon Mar 7 16:00:25 2016 +0100

    tst-audit4, tst-audit10: Compile AVX/AVX-512 code separately [BZ #19269]
    
    This ensures that GCC will not use unsupported instructions before
    the run-time check to ensure support.
    
    (cherry picked from commit 3c0f7407eedb524c9114bb675cd55b903c71daaa)

Comment 11 Fedora Update System 2016-05-09 14:56:18 UTC
glibc-2.23.1-6.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74

Comment 12 Fedora Update System 2016-05-10 17:57:15 UTC
glibc-2.22-15.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2016-05-10 20:29:53 UTC
glibc-2.23.1-6.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74

Comment 14 Fedora Update System 2016-05-11 13:54:34 UTC
glibc-2.23.1-7.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74

Comment 15 Fedora Update System 2016-05-12 09:43:48 UTC
glibc-2.23.1-7.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b321728d74

Comment 16 Fedora Update System 2016-05-14 23:29:44 UTC
glibc-2.23.1-7.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.