diff mbox series

[v2] selftests: fix relative rpath usage

Message ID 20240812165650.GA5102@asgard.redhat.com (mailing list archive)
State Changes Requested
Delegated to: BPF
Headers show
Series [v2] selftests: fix relative rpath usage | expand

Checks

Context Check Description
netdev/tree_selection success Not a local patch
bpf/vmtest-bpf-next-VM_Test-42 success Logs for x86_64-llvm-18 / veristat
bpf/vmtest-bpf-next-PR success PR summary
bpf/vmtest-bpf-next-VM_Test-4 success Logs for aarch64-gcc / build / build for aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-12 success Logs for s390x-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-11 success Logs for s390x-gcc / build / build for s390x with gcc
bpf/vmtest-bpf-next-VM_Test-9 success Logs for aarch64-gcc / test (test_verifier, false, 360) / test_verifier on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-17 success Logs for set-matrix
bpf/vmtest-bpf-next-VM_Test-16 success Logs for s390x-gcc / veristat
bpf/vmtest-bpf-next-VM_Test-18 success Logs for x86_64-gcc / build / build for x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-19 success Logs for x86_64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-27 success Logs for x86_64-llvm-17 / build / build for x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-33 success Logs for x86_64-llvm-17 / veristat
bpf/vmtest-bpf-next-VM_Test-28 success Logs for x86_64-llvm-17 / build-release / build for x86_64 with llvm-17-O2
bpf/vmtest-bpf-next-VM_Test-34 success Logs for x86_64-llvm-18 / build / build for x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-35 success Logs for x86_64-llvm-18 / build-release / build for x86_64 with llvm-18-O2
bpf/vmtest-bpf-next-VM_Test-41 success Logs for x86_64-llvm-18 / veristat
bpf/vmtest-bpf-next-VM_Test-6 success Logs for aarch64-gcc / test (test_maps, false, 360) / test_maps on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-15 success Logs for s390x-gcc / test (test_verifier, false, 360) / test_verifier on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-13 success Logs for s390x-gcc / test (test_progs, false, 360) / test_progs on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-14 success Logs for s390x-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-20 success Logs for x86_64-gcc / test (test_maps, false, 360) / test_maps on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-25 success Logs for x86_64-gcc / test (test_verifier, false, 360) / test_verifier on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-29 success Logs for x86_64-llvm-17 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-32 success Logs for x86_64-llvm-17 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-36 success Logs for x86_64-llvm-18 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-40 success Logs for x86_64-llvm-18 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-21 success Logs for x86_64-gcc / test (test_progs, false, 360) / test_progs on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-22 success Logs for x86_64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-23 success Logs for x86_64-gcc / test (test_progs_no_alu32_parallel, true, 30) / test_progs_no_alu32_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-24 success Logs for x86_64-gcc / test (test_progs_parallel, true, 30) / test_progs_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-26 success Logs for x86_64-gcc / veristat / veristat on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-30 success Logs for x86_64-llvm-17 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-31 success Logs for x86_64-llvm-17 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-37 success Logs for x86_64-llvm-18 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-38 success Logs for x86_64-llvm-18 / test (test_progs_cpuv4, false, 360) / test_progs_cpuv4 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-39 success Logs for x86_64-llvm-18 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-1 success Logs for ShellCheck
bpf/vmtest-bpf-next-VM_Test-2 success Logs for Unittests
bpf/vmtest-bpf-next-VM_Test-0 success Logs for Lint
bpf/vmtest-bpf-next-VM_Test-3 success Logs for Validate matrix.py
bpf/vmtest-bpf-next-VM_Test-5 success Logs for aarch64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-8 success Logs for set-matrix
bpf/vmtest-bpf-next-VM_Test-7 success Logs for s390x-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-10 success Logs for x86_64-gcc / build-release

Commit Message

Eugene Syromiatnikov Aug. 12, 2024, 4:56 p.m. UTC
The relative RPATH ("./") supplied to linker options in CFLAGS is resolved
relative to current working directory and not the executable directory,
which will lead in incorrect resolution when the test executables are run
from elsewhere.  Changing it to $ORIGIN makes it resolve relative
to the directory in which the executables reside, which is supposedly
the desired behaviour.  This patch also moves these CFLAGS to lib.mk,
so the RPATH is provided for all selftest binaries, which is arguably
a useful default.

Comparison of

    find -type f -perm /111 -print0 | sort -z | xargs -0 ldd 2>&1 | sed 's/([^)]*)//'

output before and after the change shows that only the binaries that
previously used RPATH of "," are affected and that the linker now able
to find the used dynamic libraries when the executable invoked outside
directory it resides in:

    $ diff -U 0 old_ldd new_ldd
    --- old_ldd     2024-08-12 08:00:16.093535910 -0400
    +++ new_ldd     2024-08-09 09:58:22.657883491 -0400
    @@ -10 +10 @@
    -       libatest.so => not found
    +       libatest.so => /home/build/linux/tools/testing/selftests/./alsa/libatest.so
    @@ -17 +17 @@
    -       libatest.so => not found
    +       libatest.so => /home/build/linux/tools/testing/selftests/./alsa/libatest.so
    @@ -24 +24 @@
    -       libatest.so => not found
    +       libatest.so => /home/build/linux/tools/testing/selftests/./alsa/libatest.so
    @@ -119 +119 @@
    -       liburandom_read.so => not found
    +       liburandom_read.so => /home/build/linux/tools/testing/selftests/./bpf/no_alu32/liburandom_read.so
    @@ -445 +445 @@
    -       liburandom_read.so => not found
    +       liburandom_read.so => /home/build/linux/tools/testing/selftests/./bpf/liburandom_read.so
    @@ -3321 +3321 @@
    -       librseq.so => not found
    +       librseq.so => /home/build/linux/tools/testing/selftests/./rseq/librseq.so
    @@ -3326 +3326 @@
    -       librseq.so => not found
    +       librseq.so => /home/build/linux/tools/testing/selftests/./rseq/librseq.so
    @@ -3331 +3331 @@
    -       librseq.so => not found
    +       librseq.so => /home/build/linux/tools/testing/selftests/./rseq/librseq.so
    @@ -3340 +3340 @@
    -       librseq.so => not found
    +       librseq.so => /home/build/linux/tools/testing/selftests/./rseq/librseq.so
    @@ -3345 +3345 @@
    -       librseq.so => not found
    +       librseq.so => /home/build/linux/tools/testing/selftests/./rseq/librseq.so
    @@ -3350 +3350 @@
    -       librseq.so => not found
    +       librseq.so => /home/build/linux/tools/testing/selftests/./rseq/librseq.so
    @@ -3355 +3355 @@
    -       librseq.so => not found
    +       librseq.so => /home/build/linux/tools/testing/selftests/./rseq/librseq.so
    @@ -3360 +3360 @@
    -       librseq.so => not found
    +       librseq.so => /home/build/linux/tools/testing/selftests/./rseq/librseq.so
    @@ -3365 +3365 @@
    -       librseq.so => not found
    +       librseq.so => /home/build/linux/tools/testing/selftests/./rseq/librseq.so

Some minimal testing is done to verify that it does not affect the
tests: alsa, rseq, and sched (which also had the RPATH tag but didn't
actually link against any locally built libraries) selftests are run
successfully before and after the change;  for the rest
of the selftests, there was no regression observed as well.

Discovered by the check-rpaths script[1][2] that checks for insecure
RPATH/RUNPATH[3], such as relative directories, during an attempt
to package BPF selftests for later use in CI:

    ERROR   0004: file '/usr/libexec/kselftests/bpf/urandom_read' contains an insecure runpath '.' in [.]

[1] https://github.com/rpm-software-management/rpm/blob/master/scripts/check-rpaths
[2] https://github.com/rpm-software-management/rpm/blob/master/scripts/check-rpaths-worker
[3] https://cwe.mitre.org/data/definitions/426.html

Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
---
v2:
  - Consolidated the updated -L/-Wl,-rpath setting into lib.mk
  - Described the testing done in the commit message
v1: https://lore.kernel.org/lkml/20240808145639.GA20510@asgard.redhat.com/
    https://lore.kernel.org/lkml/20240808151335.GA5495@asgard.redhat.com/
    https://lore.kernel.org/lkml/20240808151621.GA10025@asgard.redhat.com/
    https://lore.kernel.org/lkml/20240808151621.GA10025@asgard.redhat.com/
---
 tools/testing/selftests/alsa/Makefile  | 1 -
 tools/testing/selftests/bpf/Makefile   | 5 ++---
 tools/testing/selftests/lib.mk         | 3 +++
 tools/testing/selftests/rseq/Makefile  | 2 +-
 tools/testing/selftests/sched/Makefile | 3 +--
 5 files changed, 7 insertions(+), 7 deletions(-)

Comments

Shuah Khan Aug. 12, 2024, 11:03 p.m. UTC | #1
On 8/12/24 10:56, Eugene Syromiatnikov wrote:
> The relative RPATH ("./") supplied to linker options in CFLAGS is resolved
> relative to current working directory and not the executable directory,
> which will lead in incorrect resolution when the test executables are run
> from elsewhere.  Changing it to $ORIGIN makes it resolve relative
> to the directory in which the executables reside, which is supposedly
> the desired behaviour.  This patch also moves these CFLAGS to lib.mk,
> so the RPATH is provided for all selftest binaries, which is arguably
> a useful default.

Can you elaborate on the erros you would see if this isn't fixed? I understand
that check-rpaths tool - howebver I would like to know how it manifests and
how would you reproduce this problem while running selftests?


> Discovered by the check-rpaths script[1][2] that checks for insecure
> RPATH/RUNPATH[3], such as relative directories, during an attempt
> to package BPF selftests for later use in CI:
> 
>      ERROR   0004: file '/usr/libexec/kselftests/bpf/urandom_read' contains an insecure runpath '.' in [.]
> 
> [1] https://github.com/rpm-software-management/rpm/blob/master/scripts/check-rpaths
> [2] https://github.com/rpm-software-management/rpm/blob/master/scripts/check-rpaths-worker
> [3] https://cwe.mitre.org/data/definitions/426.html
> 
> Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
> ---
> v2:
>    - Consolidated the updated -L/-Wl,-rpath setting into lib.mk
>    - Described the testing done in the commit message
> v1: https://lore.kernel.org/lkml/20240808145639.GA20510@asgard.redhat.com/
>      https://lore.kernel.org/lkml/20240808151335.GA5495@asgard.redhat.com/
>      https://lore.kernel.org/lkml/20240808151621.GA10025@asgard.redhat.com/
>      https://lore.kernel.org/lkml/20240808151621.GA10025@asgard.redhat.com/
> ---
>   tools/testing/selftests/alsa/Makefile  | 1 -
>   tools/testing/selftests/bpf/Makefile   | 5 ++---
>   tools/testing/selftests/lib.mk         | 3 +++
>   tools/testing/selftests/rseq/Makefile  | 2 +-
>   tools/testing/selftests/sched/Makefile | 3 +--
>   5 files changed, 7 insertions(+), 7 deletions(-)

thanks,
-- Shuah
Eugene Syromiatnikov Aug. 13, 2024, 4:33 p.m. UTC | #2
On Mon, Aug 12, 2024 at 05:03:45PM -0600, Shuah Khan wrote:
> On 8/12/24 10:56, Eugene Syromiatnikov wrote:
> >The relative RPATH ("./") supplied to linker options in CFLAGS is resolved
> >relative to current working directory and not the executable directory,
> >which will lead in incorrect resolution when the test executables are run
> >from elsewhere.  Changing it to $ORIGIN makes it resolve relative
> >to the directory in which the executables reside, which is supposedly
> >the desired behaviour.  This patch also moves these CFLAGS to lib.mk,
> >so the RPATH is provided for all selftest binaries, which is arguably
> >a useful default.
> 
> Can you elaborate on the erros you would see if this isn't fixed? I understand
> that check-rpaths tool - howebver I would like to know how it manifests and

One would be unable to execute the test binaries that require additional
locally built dynamic libraries outside the directories in which they reside:

    [build@builder selftests]$ alsa/mixer-test
    alsa/mixer-test: error while loading shared libraries: libatest.so: cannot open shared object file: No such file or directory

> how would you reproduce this problem while running selftests?

This usually doesn't come up in a regular selftests usage so far, as they
are usually run via make, and make descends into specific test directories
to execute make the respective make targets there, triggering the execution
of the specific test bineries.
Shuah Khan Aug. 14, 2024, 11:14 a.m. UTC | #3
On 8/13/24 10:33, Eugene Syromiatnikov wrote:
> On Mon, Aug 12, 2024 at 05:03:45PM -0600, Shuah Khan wrote:
>> On 8/12/24 10:56, Eugene Syromiatnikov wrote:
>>> The relative RPATH ("./") supplied to linker options in CFLAGS is resolved
>>> relative to current working directory and not the executable directory,
>>> which will lead in incorrect resolution when the test executables are run
>> >from elsewhere.  Changing it to $ORIGIN makes it resolve relative
>>> to the directory in which the executables reside, which is supposedly
>>> the desired behaviour.  This patch also moves these CFLAGS to lib.mk,
>>> so the RPATH is provided for all selftest binaries, which is arguably
>>> a useful default.
>>
>> Can you elaborate on the erros you would see if this isn't fixed? I understand
>> that check-rpaths tool - howebver I would like to know how it manifests and
> 
> One would be unable to execute the test binaries that require additional
> locally built dynamic libraries outside the directories in which they reside:
> 
>      [build@builder selftests]$ alsa/mixer-test
>      alsa/mixer-test: error while loading shared libraries: libatest.so: cannot open shared object file: No such file or directory
> 
>> how would you reproduce this problem while running selftests?
> 
> This usually doesn't come up in a regular selftests usage so far, as they
> are usually run via make, and make descends into specific test directories
> to execute make the respective make targets there, triggering the execution
> of the specific test bineries.
> 

Right. selftests are run usually via make and when they are installed run through
a script which descends into specific test directories where the tests are installed.

Unless we see the problem using kselftest use-case, there is no reason the make changes.
Sorry I am not going be taking these patches.

thanks,
-- Shuah
Eugene Syromiatnikov Aug. 14, 2024, 12:25 p.m. UTC | #4
On Wed, Aug 14, 2024 at 05:14:08AM -0600, Shuah Khan wrote:
> On 8/13/24 10:33, Eugene Syromiatnikov wrote:
> >On Mon, Aug 12, 2024 at 05:03:45PM -0600, Shuah Khan wrote:
> >>On 8/12/24 10:56, Eugene Syromiatnikov wrote:
> >>>The relative RPATH ("./") supplied to linker options in CFLAGS is resolved
> >>>relative to current working directory and not the executable directory,
> >>>which will lead in incorrect resolution when the test executables are run
> >>>from elsewhere.  Changing it to $ORIGIN makes it resolve relative
> >>>to the directory in which the executables reside, which is supposedly
> >>>the desired behaviour.  This patch also moves these CFLAGS to lib.mk,
> >>>so the RPATH is provided for all selftest binaries, which is arguably
> >>>a useful default.
> >>
> >>Can you elaborate on the erros you would see if this isn't fixed? I understand
> >>that check-rpaths tool - howebver I would like to know how it manifests and
> >
> >One would be unable to execute the test binaries that require additional
> >locally built dynamic libraries outside the directories in which they reside:
> >
> >     [build@builder selftests]$ alsa/mixer-test
> >     alsa/mixer-test: error while loading shared libraries: libatest.so: cannot open shared object file: No such file or directory
> >
> >>how would you reproduce this problem while running selftests?
> >
> >This usually doesn't come up in a regular selftests usage so far, as they
> >are usually run via make, and make descends into specific test directories
> >to execute make the respective make targets there, triggering the execution
> >of the specific test bineries.
> >
> 
> Right. selftests are run usually via make and when they are installed run through
> a script which descends into specific test directories where the tests are installed.
> 
> Unless we see the problem using kselftest use-case, there is no reason the make changes.

The reason has been outlined in the commit message: relative paths in
RPATH/RUNPATH are incorrect and ought to be fixed.

> Sorry I am not going be taking these patches.

I see, by the same token, kernel maintainers reject any patches that fix
compilation/build warnings, I guess.

> thanks,
> -- Shuah
Shuah Khan Aug. 19, 2024, 9:33 a.m. UTC | #5
On 8/14/24 06:25, Eugene Syromiatnikov wrote:
> On Wed, Aug 14, 2024 at 05:14:08AM -0600, Shuah Khan wrote:
>> On 8/13/24 10:33, Eugene Syromiatnikov wrote:
>>> On Mon, Aug 12, 2024 at 05:03:45PM -0600, Shuah Khan wrote:
>>>> On 8/12/24 10:56, Eugene Syromiatnikov wrote:
>>>>> The relative RPATH ("./") supplied to linker options in CFLAGS is resolved
>>>>> relative to current working directory and not the executable directory,
>>>>> which will lead in incorrect resolution when the test executables are run
>>>> >from elsewhere.  Changing it to $ORIGIN makes it resolve relative
>>>>> to the directory in which the executables reside, which is supposedly
>>>>> the desired behaviour.  This patch also moves these CFLAGS to lib.mk,
>>>>> so the RPATH is provided for all selftest binaries, which is arguably
>>>>> a useful default.
>>>>
>>>> Can you elaborate on the erros you would see if this isn't fixed? I understand
>>>> that check-rpaths tool - howebver I would like to know how it manifests and
>>>
>>> One would be unable to execute the test binaries that require additional
>>> locally built dynamic libraries outside the directories in which they reside:
>>>
>>>      [build@builder selftests]$ alsa/mixer-test
>>>      alsa/mixer-test: error while loading shared libraries: libatest.so: cannot open shared object file: No such file or directory
>>>
>>>> how would you reproduce this problem while running selftests?
>>>
>>> This usually doesn't come up in a regular selftests usage so far, as they
>>> are usually run via make, and make descends into specific test directories
>>> to execute make the respective make targets there, triggering the execution
>>> of the specific test bineries.
>>>
>>
>> Right. selftests are run usually via make and when they are installed run through
>> a script which descends into specific test directories where the tests are installed.
>>
>> Unless we see the problem using kselftest use-case, there is no reason the make changes.
> 
> The reason has been outlined in the commit message: relative paths in
> RPATH/RUNPATH are incorrect and ought to be fixed.
> 
>> Sorry I am not going be taking these patches.
> 
> I see, by the same token, kernel maintainers reject any patches that fix
> compilation/build warnings, I guess.
> 

No - compilation and build warnings are accepted. This doesn't fall into that
case. As you mentioned you can't reproduce this using the kselftest use-cases.

Hence the reason to reject.

thanks,
-- Shuah
kernel test robot Aug. 23, 2024, 4:04 a.m. UTC | #6
Hi Eugene,

kernel test robot noticed the following build warnings:

[auto build test WARNING on shuah-kselftest/next]
[also build test WARNING on shuah-kselftest/fixes tiwai-sound/for-next tiwai-sound/for-linus bpf-next/master bpf/master linus/master v6.11-rc3 next-20240816]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Eugene-Syromiatnikov/selftests-fix-relative-rpath-usage/20240814-091042
base:   https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git next
patch link:    https://lore.kernel.org/r/20240812165650.GA5102%40asgard.redhat.com
patch subject: [PATCH v2] selftests: fix relative rpath usage
:::::: branch date: 5 days ago
:::::: commit date: 5 days ago
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240819/202408190453.wsHNZQQj-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/r/202408190453.wsHNZQQj-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> clang: warning: -Wl,-rpath=$ORIGIN/: 'linker' input unused [-Wunused-command-line-argument]
>> clang: warning: argument unused during compilation: '-Lkselftest/kvm' [-Wunused-command-line-argument]
--
>> clang: warning: -Wl,-rpath=$ORIGIN/: 'linker' input unused [-Wunused-command-line-argument]
>> clang: warning: argument unused during compilation: '-Lkselftest/net/tcp_ao' [-Wunused-command-line-argument]
kernel test robot Aug. 25, 2024, 9:40 a.m. UTC | #7
Hello,

kernel test robot noticed "segfault_at_ip_sp_error" on:

commit: 782e28421b3410522d5b50feb30e8fa10da44492 ("[PATCH v2] selftests: fix relative rpath usage")
url: https://github.com/intel-lab-lkp/linux/commits/Eugene-Syromiatnikov/selftests-fix-relative-rpath-usage/20240814-091042
base: https://git.kernel.org/cgit/linux/kernel/git/shuah/linux-kselftest.git next
patch link: https://lore.kernel.org/all/20240812165650.GA5102@asgard.redhat.com/
patch subject: [PATCH v2] selftests: fix relative rpath usage

in testcase: kernel-selftests
version: kernel-selftests-x86_64-977d51cf-1_20240508
with following parameters:

	group: group-01



compiler: gcc-12
test machine: 36 threads 1 sockets Intel(R) Core(TM) i9-10980XE CPU @ 3.00GHz (Cascade Lake) with 32G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)


besides, we also noticed some tests failed on this change:

8afc0816f5f6213c 782e28421b3410522d5b50feb30
---------------- ---------------------------
       fail:runs  %reproduction    fail:runs
           |             |             |
           :4          100%           4:4     dmesg.segfault_at_ip_sp_error
           :4          100%           4:4     kernel-selftests.exec.load_address.static.0x1000.fail
           :4          100%           4:4     kernel-selftests.exec.load_address.static.0x1000000.fail
           :4          100%           4:4     kernel-selftests.exec.load_address.static.0x200000.fail



If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202408251749.7e390194-oliver.sang@intel.com



user  :notice: [  458.511077] 2024-08-23 12:25:42 make -j36 -C dt

user  :notice: [  458.527252] make: Entering directory '/usr/src/perf_selftests-x86_64-rhel-8.3-kselftests-782e28421b3410522d5b50feb30e8fa10da44492/tools/testing/selftests/dt'

kern  :info  : [  460.458153] load_address.st[7491]: segfault at 28 ip 00007f1137a2b5e6 sp 00007ffddc0fd6d0 error 4 in load_address.static.0x1000[d5e6,7f1137a27000+7a000] likely on CPU 2 (core 2, socket 0)
kern :info : [ 460.459808] Code: 53 48 81 ec d8 00 00 00 48 89 b5 68 ff ff ff 48 89 95 38 ff ff ff 89 8d 54 ff ff ff 4c 89 85 48 ff ff ff 44 89 8d 50 ff ff ff <64> 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 48 c7 85 70 ff ff ff
All code
========
   0:	53                   	push   %rbx
   1:	48 81 ec d8 00 00 00 	sub    $0xd8,%rsp
   8:	48 89 b5 68 ff ff ff 	mov    %rsi,-0x98(%rbp)
   f:	48 89 95 38 ff ff ff 	mov    %rdx,-0xc8(%rbp)
  16:	89 8d 54 ff ff ff    	mov    %ecx,-0xac(%rbp)
  1c:	4c 89 85 48 ff ff ff 	mov    %r8,-0xb8(%rbp)
  23:	44 89 8d 50 ff ff ff 	mov    %r9d,-0xb0(%rbp)
  2a:*	64 48 8b 04 25 28 00 	mov    %fs:0x28,%rax		<-- trapping instruction
  31:	00 00 
  33:	48 89 45 c8          	mov    %rax,-0x38(%rbp)
  37:	31 c0                	xor    %eax,%eax
  39:	48                   	rex.W
  3a:	c7                   	.byte 0xc7
  3b:	85 70 ff             	test   %esi,-0x1(%rax)
  3e:	ff                   	(bad)  
  3f:	ff                   	.byte 0xff

Code starting with the faulting instruction
===========================================
   0:	64 48 8b 04 25 28 00 	mov    %fs:0x28,%rax
   7:	00 00 
   9:	48 89 45 c8          	mov    %rax,-0x38(%rbp)
   d:	31 c0                	xor    %eax,%eax
   f:	48                   	rex.W
  10:	c7                   	.byte 0xc7
  11:	85 70 ff             	test   %esi,-0x1(%rax)
  14:	ff                   	(bad)  
  15:	ff                   	.byte 0xff
kern  :info  : [  460.571500] load_address.st[7510]: segfault at 28 ip 00007fa9ec0045e6 sp 00007ffd3ba861b0 error 4 in load_address.static.0x200000[2045e6,7fa9ec000000+7a000] likely on CPU 2 (core 2, socket 0)
kern :info : [ 460.573155] Code: 53 48 81 ec d8 00 00 00 48 89 b5 68 ff ff ff 48 89 95 38 ff ff ff 89 8d 54 ff ff ff 4c 89 85 48 ff ff ff 44 89 8d 50 ff ff ff <64> 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 48 c7 85 70 ff ff ff
All code
========
   0:	53                   	push   %rbx
   1:	48 81 ec d8 00 00 00 	sub    $0xd8,%rsp
   8:	48 89 b5 68 ff ff ff 	mov    %rsi,-0x98(%rbp)
   f:	48 89 95 38 ff ff ff 	mov    %rdx,-0xc8(%rbp)
  16:	89 8d 54 ff ff ff    	mov    %ecx,-0xac(%rbp)
  1c:	4c 89 85 48 ff ff ff 	mov    %r8,-0xb8(%rbp)
  23:	44 89 8d 50 ff ff ff 	mov    %r9d,-0xb0(%rbp)
  2a:*	64 48 8b 04 25 28 00 	mov    %fs:0x28,%rax		<-- trapping instruction
  31:	00 00 
  33:	48 89 45 c8          	mov    %rax,-0x38(%rbp)
  37:	31 c0                	xor    %eax,%eax
  39:	48                   	rex.W
  3a:	c7                   	.byte 0xc7
  3b:	85 70 ff             	test   %esi,-0x1(%rax)
  3e:	ff                   	(bad)  
  3f:	ff                   	.byte 0xff

Code starting with the faulting instruction
===========================================
   0:	64 48 8b 04 25 28 00 	mov    %fs:0x28,%rax
   7:	00 00 
   9:	48 89 45 c8          	mov    %rax,-0x38(%rbp)
   d:	31 c0                	xor    %eax,%eax
   f:	48                   	rex.W
  10:	c7                   	.byte 0xc7
  11:	85 70 ff             	test   %esi,-0x1(%rax)
  14:	ff                   	(bad)  
  15:	ff                   	.byte 0xff
kern  :info  : [  460.677410] load_address.st[7529]: segfault at 28 ip 00007f9a020045e6 sp 00007ffe4bb51e10 error 4 in load_address.static.0x1000000[10045e6,7f9a02000000+7a000] likely on CPU 2 (core 2, socket 0)
kern :info : [ 460.679071] Code: 53 48 81 ec d8 00 00 00 48 89 b5 68 ff ff ff 48 89 95 38 ff ff ff 89 8d 54 ff ff ff 4c 89 85 48 ff ff ff 44 89 8d 50 ff ff ff <64> 48 8b 04 25 28 00 00 00 48 89 45 c8 31 c0 48 c7 85 70 ff ff ff
All code
========
   0:	53                   	push   %rbx
   1:	48 81 ec d8 00 00 00 	sub    $0xd8,%rsp
   8:	48 89 b5 68 ff ff ff 	mov    %rsi,-0x98(%rbp)
   f:	48 89 95 38 ff ff ff 	mov    %rdx,-0xc8(%rbp)
  16:	89 8d 54 ff ff ff    	mov    %ecx,-0xac(%rbp)
  1c:	4c 89 85 48 ff ff ff 	mov    %r8,-0xb8(%rbp)
  23:	44 89 8d 50 ff ff ff 	mov    %r9d,-0xb0(%rbp)
  2a:*	64 48 8b 04 25 28 00 	mov    %fs:0x28,%rax		<-- trapping instruction
  31:	00 00 
  33:	48 89 45 c8          	mov    %rax,-0x38(%rbp)
  37:	31 c0                	xor    %eax,%eax
  39:	48                   	rex.W
  3a:	c7                   	.byte 0xc7
  3b:	85 70 ff             	test   %esi,-0x1(%rax)
  3e:	ff                   	(bad)  
  3f:	ff                   	.byte 0xff

Code starting with the faulting instruction
===========================================
   0:	64 48 8b 04 25 28 00 	mov    %fs:0x28,%rax
   7:	00 00 
   9:	48 89 45 c8          	mov    %rax,-0x38(%rbp)
   d:	31 c0                	xor    %eax,%eax
   f:	48                   	rex.W
  10:	c7                   	.byte 0xc7
  11:	85 70 ff             	test   %esi,-0x1(%rax)
  14:	ff                   	(bad)  
  15:	ff                   	.byte 0xff
kern  :warn  : [  460.793864] process 'recursion-depth' launched '/tmp/1' with NULL argv: empty string added
user  :err   : [  461.202285] fixup_efivarfs failed

user  :err   : [  462.541150]   /lkp/lkp/src/lib/debug.sh:12: die



The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240825/202408251749.7e390194-oliver.sang@intel.com
diff mbox series

Patch

diff --git a/tools/testing/selftests/alsa/Makefile b/tools/testing/selftests/alsa/Makefile
index c1ce39874e2b..68a1651360e5 100644
--- a/tools/testing/selftests/alsa/Makefile
+++ b/tools/testing/selftests/alsa/Makefile
@@ -6,7 +6,6 @@  LDLIBS += $(shell pkg-config --libs alsa)
 ifeq ($(LDLIBS),)
 LDLIBS += -lasound
 endif
-CFLAGS += -L$(OUTPUT) -Wl,-rpath=./
 
 LDLIBS+=-lpthread
 
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index 81d4757ecd4c..a152c12b8a3b 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -239,9 +239,8 @@  $(OUTPUT)/urandom_read: urandom_read.c urandom_read_aux.c $(OUTPUT)/liburandom_r
 	$(call msg,BINARY,,$@)
 	$(Q)$(CLANG) $(CLANG_TARGET_ARCH) \
 		     $(filter-out -static,$(CFLAGS) $(LDFLAGS)) $(filter %.c,$^) \
-		     -lurandom_read $(filter-out -static,$(LDLIBS)) -L$(OUTPUT) \
-		     -fuse-ld=$(LLD) -Wl,-znoseparate-code -Wl,--build-id=sha1 \
-		     -Wl,-rpath=. -o $@
+		     -lurandom_read $(filter-out -static,$(LDLIBS)) \
+		     -fuse-ld=$(LLD) -Wl,-znoseparate-code -Wl,--build-id=sha1 -o $@
 
 $(OUTPUT)/sign-file: ../../../../scripts/sign-file.c
 	$(call msg,SIGN-FILE,,$@)
diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index d6edcfcb5be8..d75a20bb569c 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -199,6 +199,9 @@  clean: $(if $(TEST_GEN_MODS_DIR),clean_mods_dir)
 # Build with _GNU_SOURCE by default
 CFLAGS += -D_GNU_SOURCE=
 
+# Simplify usage of libraries built alongside the test executables
+CFLAGS += -L$(OUTPUT) -Wl,-rpath=\$$ORIGIN/
+
 # Enables to extend CFLAGS and LDFLAGS from command line, e.g.
 # make USERCFLAGS=-Werror USERLDFLAGS=-static
 CFLAGS += $(USERCFLAGS)
diff --git a/tools/testing/selftests/rseq/Makefile b/tools/testing/selftests/rseq/Makefile
index 5a3432fceb58..887b45d4a675 100644
--- a/tools/testing/selftests/rseq/Makefile
+++ b/tools/testing/selftests/rseq/Makefile
@@ -6,7 +6,7 @@  endif
 
 top_srcdir = ../../../..
 
-CFLAGS += -O2 -Wall -g -I./ $(KHDR_INCLUDES) -L$(OUTPUT) -Wl,-rpath=./ \
+CFLAGS += -O2 -Wall -g -I./ $(KHDR_INCLUDES) \
 	  $(CLANG_FLAGS) -I$(top_srcdir)/tools/include
 LDLIBS += -lpthread -ldl
 
diff --git a/tools/testing/selftests/sched/Makefile b/tools/testing/selftests/sched/Makefile
index 099ee9213557..0e4581ded9d6 100644
--- a/tools/testing/selftests/sched/Makefile
+++ b/tools/testing/selftests/sched/Makefile
@@ -4,8 +4,7 @@  ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
 CLANG_FLAGS += -no-integrated-as
 endif
 
-CFLAGS += -O2 -Wall -g -I./ $(KHDR_INCLUDES) -Wl,-rpath=./ \
-	  $(CLANG_FLAGS)
+CFLAGS += -O2 -Wall -g -I./ $(KHDR_INCLUDES) $(CLANG_FLAGS)
 LDLIBS += -lpthread
 
 TEST_GEN_FILES := cs_prctl_test