From: Sandipan Das <sandipan@linux.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Sachin Sant <sachinp@linux.vnet.ibm.com>, linuxppc-dev@lists.ozlabs.org
Subject: Re: [merge] Build failure selftest/powerpc/mm/pkey_exec_prot
Date: Tue, 4 Aug 2020 22:15:41 +0530 [thread overview]
Message-ID: <a2e6d27e-7e92-ff33-a930-9bb132392759@linux.ibm.com> (raw)
In-Reply-To: <877duezjk3.fsf@mpe.ellerman.id.au>
On 04/08/20 5:53 pm, Michael Ellerman wrote:
> Sandipan Das <sandipan@linux.ibm.com> writes:
>> On 04/08/20 6:38 am, Michael Ellerman wrote:
>>> Sandipan Das <sandipan@linux.ibm.com> writes:
>>>> On 03/08/20 4:32 pm, Michael Ellerman wrote:
>>>>> Sachin Sant <sachinp@linux.vnet.ibm.com> writes:
>>>>>>> On 02-Aug-2020, at 10:58 PM, Sandipan Das <sandipan@linux.ibm.com> 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.
>>
>> If I let GCC dump all the headers that are being used for the source file, I always
>> see syscall.h being included on the RHEL 8.2 system. That is the header with the
>> conflicting definition.
>>
>> $ cd tools/testing/selftests/powerpc/mm
>> $ gcc -H -std=gnu99 -O2 -Wall -Werror -DGIT_VERSION='"v5.8-rc7-1456-gf59195f7faa4-dirty"' \
>> -I../include -m64 pkey_exec_prot.c ../../kselftest_harness.h ../../kselftest.h ../harness.c ../utils.c \
>> -o pkey_exec_prot 2>&1 | grep syscall
>>
>> On Ubuntu 20.04 and Fedora 32, grep doesn't find any matching text.
>> On RHEL 8.2, it shows the following.
>> ... /usr/include/sys/syscall.h
>> .... /usr/include/bits/syscall.h
>> In file included from /usr/include/sys/syscall.h:31,
>> /usr/include/bits/syscall.h:1583: note: this is the location of the previous definition
>> In file included from /usr/include/sys/syscall.h:31,
>> /usr/include/bits/syscall.h:1575: note: this is the location of the previous definition
>> In file included from /usr/include/sys/syscall.h:31,
>> /usr/include/bits/syscall.h:1579: note: this is the location of the previous definition
>> /usr/include/bits/syscall.h
>> .. /usr/include/sys/syscall.h
>> ... /usr/include/bits/syscall.h
>> /usr/include/bits/syscall.h
>> .. /usr/include/sys/syscall.h
>> ... /usr/include/bits/syscall.h
>> /usr/include/bits/syscall.h
>>
>> So utils.h is also including /usr/include/sys/syscall.h for glibc versions older than 2.30
>> because of commit 743f3544fffb ("selftests/powerpc: Add wrapper for gettid") :)
>
> Haha, of course. :facepalm_emoji:
>
>> [...]
>> . ../include/pkeys.h
>> [...]
>> .. ../include/utils.h
>> [...]
>> ... /usr/include/sys/syscall.h
>> .... /usr/include/asm/unistd.h
>> .... /usr/include/bits/syscall.h
>> In file included from pkey_exec_prot.c:18:
>> ../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 ../include/utils.h:47,
>> from ../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
>
> Aha, that explains why redefining gives us an error, because we're
> defining it to the literal 386 whereas the system header is defining it
> to the __NR value.
>
> Is there a reason to use the SYS_ name?
>
That's just something I borrowed from the pkey tests under selftests/vm
... but without the #ifndefs
> Typically we just use the __NR value directly, and that would avoid any
> problems with redefinition I think, as long as we're using the same
> value as the system header (which we always should be).
>
Agreed. David Laight suggested this too. Will send v4 with these changes.
- Sandipan
> eg:
>
> diff --git a/tools/testing/selftests/powerpc/include/pkeys.h b/tools/testing/selftests/powerpc/include/pkeys.h
> index 6ba95039a034..3312cb1b058d 100644
> --- a/tools/testing/selftests/powerpc/include/pkeys.h
> +++ b/tools/testing/selftests/powerpc/include/pkeys.h
> @@ -31,9 +31,9 @@
>
> #define SI_PKEY_OFFSET 0x20
>
> -#define SYS_pkey_mprotect 386
> -#define SYS_pkey_alloc 384
> -#define SYS_pkey_free 385
> +#define __NR_pkey_mprotect 386
> +#define __NR_pkey_alloc 384
> +#define __NR_pkey_free 385
>
> #define PKEY_BITS_PER_PKEY 2
> #define NR_PKEYS 32
> @@ -62,17 +62,17 @@ void pkey_set_rights(int pkey, unsigned long rights)
>
> int sys_pkey_mprotect(void *addr, size_t len, int prot, int pkey)
> {
> - return syscall(SYS_pkey_mprotect, addr, len, prot, pkey);
> + return syscall(__NR_pkey_mprotect, addr, len, prot, pkey);
> }
>
> int sys_pkey_alloc(unsigned long flags, unsigned long rights)
> {
> - return syscall(SYS_pkey_alloc, flags, rights);
> + return syscall(__NR_pkey_alloc, flags, rights);
> }
>
> int sys_pkey_free(int pkey)
> {
> - return syscall(SYS_pkey_free, pkey);
> + return syscall(__NR_pkey_free, pkey);
> }
>
> int pkeys_unsupported(void)
>
prev parent reply other threads:[~2020-08-04 16:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-02 11:15 [merge] Build failure selftest/powerpc/mm/pkey_exec_prot Sachin Sant
2020-08-02 17:28 ` Sandipan Das
2020-08-03 5:43 ` Sachin Sant
2020-08-03 11:02 ` Michael Ellerman
2020-08-03 11:27 ` Sandipan Das
2020-08-04 1:08 ` Michael Ellerman
2020-08-04 6:35 ` Sandipan Das
2020-08-04 12:23 ` Michael Ellerman
2020-08-04 16:45 ` Sandipan Das [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a2e6d27e-7e92-ff33-a930-9bb132392759@linux.ibm.com \
--to=sandipan@linux.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=sachinp@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).