Subject: Re: [merge] Build failure selftest/powerpc/mm/pkey_exec_prot

From: Michael Ellerman <[email-masked]>
Date: Tue, 04 Aug 2020 11:08:44 +1000

Sandipan Das <[email-masked]> writes:
> On 03/08/20 4:32 pm, Michael Ellerman wrote:
>> Sachin Sant <[email-masked]> writes:
>>>> On 02-Aug-2020, at 10:58 PM, Sandipan Das <[email-masked]> wrote:
>>>> On 02/08/20 4:45 pm, Sachin Sant wrote:
>>>>> pkey_exec_prot test from linuxppc merge branch (3f68564f1f5a) fails to
>>>>> build due to following error:
>>>>>
>>>>> gcc -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1276-g3f68564f1f5a"' -I/home/sachin/linux/tools/testing/selftests/powerpc/include  -m64    pkey_exec_prot.c /home/sachin/linux/tools/testing/selftests/kselftest_harness.h /home/sachin/linux/tools/testing/selftests/kselftest.h ../harness.c ../utils.c  -o /home/sachin/linux/tools/testing/selftests/powerpc/mm/pkey_exec_prot
>>>>> In file included from pkey_exec_prot.c:18:
>>>>> /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:34: error: "SYS_pkey_mprotect" redefined [-Werror]
>>>>> #define SYS_pkey_mprotect 386
>>>>>
>>>>> In file included from /usr/include/sys/syscall.h:31,
>>>>>                 from /home/sachin/linux/tools/testing/selftests/powerpc/include/utils.h:47,
>>>>>                 from /home/sachin/linux/tools/testing/selftests/powerpc/include/pkeys.h:12,
>>>>>                 from pkey_exec_prot.c:18:
>>>>> /usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
>>>>> # define SYS_pkey_mprotect __NR_pkey_mprotect
>>>>>
>>>>> commit 128d3d021007 introduced this error.
>>>>> selftests/powerpc: Move pkey helpers to headers
>>>>>
>>>>> Possibly the # defines for sys calls can be retained in pkey_exec_prot.c or
>>>>>
>>>>
>>>> I am unable to reproduce this on the latest merge branch (HEAD at f59195f7faa4).
>>>> I don't see any redefinitions in pkey_exec_prot.c either.
>>>>
>>>
>>> I can still see this problem on latest merge branch.
>>> I have following gcc version
>>>
>>> gcc version 8.3.1 20191121
>> 
>> What libc version? Or just the distro & version?
>
> Sachin observed this on RHEL 8.2 with glibc-2.28.
> I couldn't reproduce it on Ubuntu 20.04 and Fedora 32 and both these distros
> are using glibc-2.31.

OK odd. Usually it's newer glibc that hits this problem.

I guess on RHEL 8.2 we're getting the asm-generic version? But that
would be quite wrong if that's what's happening.

cheers