numbers in the tables of all architectures is
good practice and would help avoid future conflicts.
[1]:
https://lore.kernel.org/lkml/20230824-frohlocken-vorabend-725f6fdaad50@brauner/
[2]:
https://lore.kernel.org/lkml/20230830234752.19858-1-dave.han...@linux.intel.com/
Sohil Mehta (2):
tools
The syscall table entries in the core kernel and perf are expected to be
in sync. This would fix perf build warnings and also add support for
fchmodat2 in 'perf trace'.
Signed-off-by: Sohil Mehta
---
tools/include/uapi/asm-generic/unistd.h | 5 -
tools/perf/arch/
: Sohil Mehta
---
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 ++
arch/ia64/kernel/syscalls/syscall.tbl
On 9/11/2023 2:10 PM, Edgecombe, Rick P wrote:
> On Mon, 2023-09-11 at 18:02 +0000, Sohil Mehta wrote:
>> diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl
>> b/arch/powerpc/kernel/syscalls/syscall.tbl
>> index 20e50586e8a2..2767b8a42636 100644
>> --- a/arch/powerpc/
On 9/11/2023 11:02 AM, Sohil Mehta wrote:
> Sohil Mehta (2):
> tools headers UAPI: Sync fchmodat2() syscall table entries
I now see a patch by Arnaldo that does something similar:
https://lore.kernel.org/lkml/zp8be7axdbu%2fd...@kernel.org/
Also, it states that:
"The tools
up #563 as Alpha still diverges from
the common syscall numbering system in the other architectures.
Link:
https://lore.kernel.org/lkml/20230515212255.ga562...@debug.ba.rivosinc.com/
Link:
https://lore.kernel.org/lkml/b402b80b-a7c6-4ef0-b977-c0f5f582b...@sirena.org.uk/
Signed-off-by: Sohil Meh
On 9/14/2023 11:58 AM, Sohil Mehta wrote:
> commit c35559f94ebc ("x86/shstk: Introduce map_shadow_stack syscall")
> recently added support for map_shadow_stack() but it is limited to x86
> only for now. There is a possibility that other architectures (namely,
> arm64
On 10/3/2023 9:54 AM, Arnd Bergmann wrote:
> On Tue, Oct 3, 2023, at 18:35, Sohil Mehta wrote:
>>
>> Gentle ping...
>>
>> Are there any additional comments? It applies cleanly on 6.6-rc4.
>>
>> Or does it seem ready to be merged? It has the following
>&g
Arnd, is this a good candidate for 6.7? Though old, the patch applies
cleanly on 6.6-rc4. I can re-send this one if you would prefer that.
On 8/3/2023 2:44 PM, Sohil Mehta wrote:
> On 7/10/2023 11:51 AM, Sohil Mehta wrote:
>> commit 'be65de6b03aa ("fs: Remove dcookies sup
On 10/3/2023 10:53 AM, Arnd Bergmann wrote:
> Thanks a lot for the reminder, I've added it to my asm-generic
> branch for v6.7 now, it should be in linux-next tomorrow.
>
No problem at all. Thanks for picking up the patch!
Sohil
On 10/6/2023 1:29 PM, Arnd Bergmann wrote:
> On Fri, Oct 6, 2023, at 22:01, Edgecombe, Rick P wrote:
>> Hi Arnd,
>>
>> It doesn't look like anyone is pouncing on the syscall number in linux-
>> next currently. It might be nice to have this patch go through linux-
>> next since it touches so many ar
commit 'be65de6b03aa ("fs: Remove dcookies support")' removed the
syscall definition for lookup_dcookie. However, syscall tables still
point to the old sys_lookup_dcookie() definition. Update syscall tables
of all architectures to directly point to sys_ni_syscall() instead.
commit 'be65de6b03aa ("fs: Remove dcookies support")' removed the
syscall definition for lookup_dcookie. However, syscall tables still
point to the old sys_lookup_dcookie() definition. Update syscall tables
of all architectures to directly point to sys_ni_syscall() instead.
Hi Arnd,
On 7/10/2023 11:51 AM, Sohil Mehta wrote:
> commit 'be65de6b03aa ("fs: Remove dcookies support")' removed the
> syscall definition for lookup_dcookie. However, syscall tables still
> point to the old sys_lookup_dcookie() definition. Update syscall tab
On 6/10/2022 4:35 PM, ira.we...@intel.com wrote:
glibc says it returns ENOSYS if the system does not support pkeys but I don't
see where ENOSYS is returned? AFAICS it just returns what the kernel returns.
So it is probably up to user of glibc.
Implementation of the pkeys system calls is arc
On 6/10/2022 4:35 PM, ira.we...@intel.com wrote:
Add command line options for debug level and number of iterations.
$ ./protection_keys_64 -h
Usage: ./protection_keys_64 [-h,-d,-i ]
--help,-h This help
--debug,-d Increase debug level for each -d
Is this mechanism (of count
On 6/10/2022 4:35 PM, ira.we...@intel.com wrote:
diff --git a/tools/testing/selftests/vm/protection_keys.c
b/tools/testing/selftests/vm/protection_keys.c
index d0183c381859..43e47de19c0d 100644
--- a/tools/testing/selftests/vm/protection_keys.c
+++ b/tools/testing/selftests/vm/protection_keys.c
On 6/10/2022 4:35 PM, ira.we...@intel.com wrote:
+void test_pkey_alloc_on_unsupported_cpu(void)
+{
+ int test_pkey = sys_pkey_alloc(0, 0);
+
+ dprintf1("pkey_alloc: %d (%d %s)\n", test_pkey, errno,
+strerror(errno));
+ pkey_assert(test_pkey < 0);
+ pkey_
diff --git a/mm/mprotect.c b/mm/mprotect.c
index ba5592655ee3..56d35de33725 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -773,6 +773,9 @@ SYSCALL_DEFINE2(pkey_alloc, unsigned long, flags, unsigned
long, init_val)
int pkey;
int ret;
+ if (!arch_pkeys_enabled())
+
lib/crypto/ into lib/crypto/
> MAINTAINERS: drop arch/*/lib/crypto/ pattern
>
The updated version looks good to me.
Reviewed-by: Sohil Mehta
2 ("x86 boot build: make git
ignore stale 'tools' directory") says this:
"So when removing directories that had special .gitignore patterns, make
sure to add a new gitignore entry in the parent directory for the no
longer existing subdirectory."
With that change,
Reviewed-by: Sohil Mehta
> Signed-off-by: Eric Biggers
21 matches
Mail list logo
