[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <766a0820-b62e-4b2d-be56-44ff479f962d@nvidia.com>
Date: Mon, 17 Jun 2024 18:52:15 -0700
From: John Hubbard <jhubbard@...dia.com>
To: David Hildenbrand <david@...hat.com>, Andrew Morton
<akpm@...ux-foundation.org>, Jeff Xu <jeffxu@...omium.org>, Shuah Khan
<shuah@...nel.org>
CC: Andrei Vagin <avagin@...gle.com>, Axel Rasmussen
<axelrasmussen@...gle.com>, Christian Brauner <brauner@...nel.org>, Kees Cook
<kees@...nel.org>, Kent Overstreet <kent.overstreet@...ux.dev>, "Liam R .
Howlett" <Liam.Howlett@...cle.com>, Muhammad Usama Anjum
<usama.anjum@...labora.com>, Peter Xu <peterx@...hat.com>, Rich Felker
<dalias@...c.org>, <linux-mm@...ck.org>, <linux-kselftest@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 1/6] selftests/mm: mseal, self_elf: fix missing
__NR_mseal
On 6/17/24 11:11 AM, David Hildenbrand wrote:
> On 14.06.24 20:02, John Hubbard wrote:
>> On 6/14/24 5:41 AM, David Hildenbrand wrote:
>>> On 14.06.24 14:28, David Hildenbrand wrote:
>>>> On 14.06.24 04:30, John Hubbard wrote:
...
>>> ... thinking again, are some of these headers arch-specific (IOW,
>>> generating them per-arch would result in something slightly different)?
>>
>> Oh wow, yes they are. I'm guilty of x86-centric thinking (again).
>>
>> hmm, this is going to make it really a lot of trouble to do this
>> approach. But there's no point in turning back now, so I guess I'd
>> better fire up the cross-compilers and generate for all the arches.
>>
>
> Cross compilers might not be required.
>
> At least for me, at simple
>
> rm -rf usr/include
> export ARCH=s390
> make headers
> make headers_install
>
> Installed the proper s390 headers, and "usr/include/asm" would contain the s390 specifics.
Yes.
>
> Some scripting would be required to make this much easier to generate+wire up for all archs semi-automatically.
After exploring this, and eventually re-inventing the concept of asm-generic,
I now understand What To Do.
>>>
>>> In tools/include/uapi/asm-generic/unistd.h, we already do have
>>> __NR_mseal ...
>>
>> Yes, but it doesn't get used in selftests/mm, with the way headers are
>> set up right now.
>
> Right
>
...it turns out that the right answer is to simply include asm-generic/unistd.h.
That is the only way to safely use system call numbers across CPU architectures,
and we already have it. So the entire patch simplifies back down to two lines
of diff:
diff --git a/tools/testing/selftests/mm/mseal_test.c b/tools/testing/selftests/mm/mseal_test.c
index 41998cf1dcf5..58c888529f42 100644
--- a/tools/testing/selftests/mm/mseal_test.c
+++ b/tools/testing/selftests/mm/mseal_test.c
@@ -3,7 +3,7 @@
#include <linux/mman.h>
#include <sys/mman.h>
#include <stdint.h>
-#include <unistd.h>
+#include <asm-generic/unistd.h>
#include <string.h>
#include <sys/time.h>
#include <sys/resource.h>
diff --git a/tools/testing/selftests/mm/seal_elf.c b/tools/testing/selftests/mm/seal_elf.c
index f2babec79bb6..27bf2f84231d 100644
--- a/tools/testing/selftests/mm/seal_elf.c
+++ b/tools/testing/selftests/mm/seal_elf.c
@@ -2,7 +2,7 @@
#define _GNU_SOURCE
#include <sys/mman.h>
#include <stdint.h>
-#include <unistd.h>
+#include <asm-generic/unistd.h>
#include <string.h>
#include <sys/time.h>
#include <sys/resource.h>
Which is a little embarrassing, after all this churn, but it's not always
clear how these headers are meant to be used, at first. Now it's clear.
I think. :)
I'll post a v3 shortly
thanks,
--
John Hubbard
NVIDIA
Powered by blists - more mailing lists