The vma05 test was producing false positive failures by flagging any "??" symbols in gdb backtraces as vDSO kernel bugs, including those from normal stripped system libraries.

This caused widespread false failures in production environments where system libraries like libc.so.6 are typically stripped of debug symbols.

The fix filters out "??" symbols that originate from system libraries (paths containing "/lib/" or "/usr/lib/") while still detecting genuine unresolved symbols in application code that could indicate real vDSO bugs.

Signed-off-by: Ben Copeland ben.copeland@linaro.org Reviewed-by: Petr Vorel pvorel@suse.cz --- testcases/kernel/mem/vma/vma05.sh | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/testcases/kernel/mem/vma/vma05.sh b/testcases/kernel/mem/vma/vma05.sh index c560eecbc..1546342a8 100755 --- a/testcases/kernel/mem/vma/vma05.sh +++ b/testcases/kernel/mem/vma/vma05.sh @@ -64,8 +64,10 @@ tst_test() TRACE=$(gdb -silent -ex="thread apply all backtrace" -ex="quit"\ vma05_vdso ./core* 2> /dev/null)

- if echo "$TRACE" | grep -qF "??"; then - tst_res TFAIL "[vdso] bug not patched" + # Only check for ?? symbols in application code, not system libraries + APP_UNKNOWN=$(echo "$TRACE" | grep -F "??" | grep -v -e "from /lib/" -e "from /usr/lib/") + if [ -n "$APP_UNKNOWN" ]; then + tst_res TFAIL "[vdso] bug not patched - unknown symbols in application code" else tst_res TPASS "[vdso] backtrace complete" fi