From: Andre Przywara <andre.przywara@arm.com>
To: Andrea Arcangeli <aarcange@redhat.com>,
Shuah Khan <shuahkh@osg.samsung.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Pavel Emelyanov <xemul@parallels.com>,
Will Deacon <Will.Deacon@arm.com>
Subject: Re: [PATCH 2/2] selftests/userfaultfd: improve syscall number definition
Date: Tue, 22 Sep 2015 18:15:12 +0100 [thread overview]
Message-ID: <56018CA0.8050600@arm.com> (raw)
In-Reply-To: <20150922140625.GH25412@redhat.com>
Hi Shuah, Andrea,
On 22/09/15 15:06, Andrea Arcangeli wrote:
> On Tue, Sep 22, 2015 at 07:49:13AM -0600, Shuah Khan wrote:
>> On 09/22/2015 04:45 AM, Andre Przywara wrote:
>>> At the moment the userfaultfd test program only supports x86 and an
>>> architecture called "powewrpc" ;-)
>>> Fix that typo and add the syscall numbers for other architectures as
>>> well.
>>> Also as in an ideal world a syscall number should come from the system
>>> header file <asm/unistd.h>, include that header and guard the explicit
>>> syscall number section below to avoid redefinitions.
>>>
>>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>>> ---
>>> tools/testing/selftests/vm/userfaultfd.c | 13 ++++++++++++-
>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/tools/testing/selftests/vm/userfaultfd.c b/tools/testing/selftests/vm/userfaultfd.c
>>> index 2c7cca6..63be27f 100644
>>> --- a/tools/testing/selftests/vm/userfaultfd.c
>>> +++ b/tools/testing/selftests/vm/userfaultfd.c
>>> @@ -65,16 +65,27 @@
>>> #include <sys/ioctl.h>
>>> #include <pthread.h>
>>> #include "../../../../include/uapi/linux/userfaultfd.h"
>>> +#include <asm/unistd.h>
>>>
>>> +/* ideally the above user header provides that number, but ... */
>>> +#ifndef __NR_userfaultfd
>>> #ifdef __x86_64__
>>> #define __NR_userfaultfd 323
>>> #elif defined(__i386__)
>>> #define __NR_userfaultfd 374
>>> -#elif defined(__powewrpc__)
>>> +#elif defined(__powerpc__)
>>> #define __NR_userfaultfd 364
>>> +#elif defined(__ia64__)
>>> +#define __NR_userfaultfd 1343
>>> +#elif defined(__arm__)
>>> +#define __NR_userfaultfd 388
>>> +#elif defined(__aarch64__)
>>> +/* this is from the generic syscall table, used also on other architectures */
>>> +#define __NR_userfaultfd 283
>>> #else
>>> #error "missing __NR_userfaultfd definition"
>>> #endif
>>> +#endif /* !__NR_userfaultfd */
>>>
>>> static unsigned long nr_cpus, nr_pages, nr_pages_per_cpu, page_size;
>>>
>>>
>>
>> This is not okay. User-space shouldn't be (re)defining/duplicating
>> syscall numbers. I can't take this patch.
While I agree that this isn't the right approach from a userland point
of view, I wonder how this is supposed to work for the next few months?
Is everybody required to overwrite their distribution-provided kernel
headers just for compiling this test program?
> -mm has already been updated to do exactly that. Syscall numbers end
> up hardcoded into userland binaries/libs somewhere, so it's not a
> bugfix but certainly it's a nice cleanup to remove the whole #ifdef block.
>
> Andre, could you see if linux-next (which includes -mm) works for you
> by just running "cd tools/testing/selftests/vm/ && make"? If there's
> any further change required could you diff it against linux-next?
This doesn't compile now for me, because it looks into
/usr/include/asm/unistd.h, which I keep to the distribution copy of it.
Also linux/userfaultfd.h is missing, because it's brand new.
If that tool lives in the kernel repo, it should be able to either use
the uapi headers directly or hardcode the syscall numbers - strictly
it's not a sane userland program anymore, but for that kind of tools I
deem it's totally acceptable. I think this is one rationale for keeping
it inside the linux.git repo.
Obviously you were facing the same problem in the beginning (looking at
the original code), so I was just extending the original solution to
cover more architectures and prepare for the time when those symbols
start to appear in distributions.
I guess the right solution would be to hack the Makefile to set the
include path to the kernel's copy of include/uapi, though I am not sure
this works cleanly for different architectures and separate build
directories. I will give this a try ...
Cheers,
Andre.
next prev parent reply other threads:[~2015-09-22 17:15 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 10:45 [PATCH 0/2] selftests/userfaultfd: fix build Andre Przywara
2015-09-22 10:45 ` Andre Przywara
[not found] ` <1442918756-17892-1-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
2015-09-22 10:45 ` [PATCH 1/2] userfaultfd: remove kernel header include from uapi header Andre Przywara
2015-09-22 10:45 ` Andre Przywara
2015-09-22 10:45 ` [PATCH 2/2] selftests/userfaultfd: improve syscall number definition Andre Przywara
2015-09-22 10:45 ` Andre Przywara
[not found] ` <1442918756-17892-3-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
2015-09-22 13:49 ` Shuah Khan
2015-09-22 13:49 ` Shuah Khan
[not found] ` <56015C59.5010300-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
2015-09-22 14:06 ` Andrea Arcangeli
2015-09-22 14:06 ` Andrea Arcangeli
2015-09-22 17:15 ` Andre Przywara [this message]
[not found] ` <56018CA0.8050600-5wv7dgnIgG8@public.gmane.org>
2015-09-23 9:55 ` Michael Ellerman
2015-09-23 9:55 ` Michael Ellerman
[not found] ` <1443002109.9279.1.camel-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
2015-09-23 13:11 ` Andre Przywara
2015-09-23 13:11 ` Andre Przywara
[not found] ` <5602A505.8090804-5wv7dgnIgG8@public.gmane.org>
2015-09-24 2:04 ` Michael Ellerman
2015-09-24 2:04 ` Michael Ellerman
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=56018CA0.8050600@arm.com \
--to=andre.przywara@arm.com \
--cc=Will.Deacon@arm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shuahkh@osg.samsung.com \
--cc=xemul@parallels.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.