On Wed, 19 Feb 2025, Dmitry V. Levin wrote:
> > -- given MIPS syscall_set_nr() implementation in 3/6 this conditional is
> > supposed to never be true. Should it be BUG_ON() or discarded entirely?
>
> I agree it should be discarded: given that the syscall number read from
> regs[2] after syscal
Now a single beauty file is generated and used by all architectures,
remove the per-architecture Makefiles, Kbuild files and previous
generator script.
Note: there was conversation with Charlie Jenkins
and they'd written an alternate approach to
support multiple architectures:
https://lore.kernel
Arnd Bergmann described that MIPS system calls don't necessarily start
from 0 as an ABI prefix is applied:
https://lore.kernel.org/lkml/8ed7dfb2-1e4d-4aa4-a04b-0397a8936...@app.fastmail.com/
When decoding the "id" (aka system call number) for MIPS ignore values
greater-than 1000.
Signed-off-by: Ia
Switch to use the lookup table containing all architectures rather
than tables matching the perf binary.
This fixes perf trace when executed on a 32-bit i386 binary on an
x86-64 machine. Note in the following the system call names of the
32-bit i386 binary as seen by an x86-64 perf.
Before:
```
Use the executable from /proc/pid/exe and read the e_machine from the
ELF header. On failure use EM_HOST. Change builtin-trace syscall
functions to pass e_machine from the thread rather than EM_HOST, so
that in later patches when syscalltbl can use the e_machine the system
calls are specific to the
The syscalltbl held entries of system call name and number pairs,
generated from a native syscalltbl at start up. As there are gaps in
the system call number there is a notion of index into the
table. Going forward we want the system call table to be identifiable
by a machine type, for example, i38
Rather than generating individual syscall header files generate a
single trace/beauty/generated/syscalltbl.c. In a syscalltbls array
have references to each architectures tables along with the
corresponding e_machine. When the 32-bit or 64-bit table is ambiguous,
match the perf binary's type. For A
Identify struct syscall information in the syscalls table by a machine
type and syscall number, not just system call number. Having the
machine type means that 32-bit system calls can be differentiated from
64-bit ones on a machine capable of both. Having a table for all
machine types and all syste
The definition of "static const char *const syscalltbl[] = {" is done
in a generated syscalls_32.h or syscalls_64.h that is architecture
dependent. In order to include the appropriate file a syscall_table.h
is found via the perf include path and it includes the syscalls_32.h
or syscalls_64.h as app
This work builds on the clean up of system call tables and removal of
libaudit by Charlie Jenkins .
The system call table in perf trace is used to map system call numbers
to names and vice versa. Prior to these changes, a single table
matching the perf binary's build was present. The table would b
On Wed, Feb 19, 2025 at 05:15:48PM +, Maciej W. Rozycki wrote:
> On Mon, 17 Feb 2025, Dmitry V. Levin wrote:
[...]
> > diff --git a/arch/csky/include/asm/syscall.h
> > b/arch/csky/include/asm/syscall.h
> > index 0de5734950bf..30403f7a0487 100644
> > --- a/arch/csky/include/asm/syscall.h
> > ++
On Mon, 17 Feb 2025, Dmitry V. Levin wrote:
> This function is going to be needed on all HAVE_ARCH_TRACEHOOK
> architectures to implement PTRACE_SET_SYSCALL_INFO API.
>
> This partially reverts commit 7962c2eddbfe ("arch: remove unused
> function syscall_set_arguments()") by reusing some of old
>
Lovely cleanup and a great suggestion from Al.
Reviewed-by: Sam James
I'd suggest adding a:
Suggested-by: Al Viro
thanks,
sam
Argh, sorry, GMail switched back to HTML mode somehow. Maybe I have to
get a proper mail client after all.
Here's the clean version.
On Wed, 19 Feb 2025 at 11:57, Borislav Petkov wrote:
>
> > + * Runtime usage:
> > + *
> > + * 1. Call asi_enter() to switch to the restricted address space. This
On Tue, Feb 18, 2025 at 03:49:54PM +0530, Anshuman Khandual wrote:
> From: Ryan Roberts
>
> ioremap_prot() currently accepts pgprot_val parameter as an unsigned long,
> thus implicitly assuming that pgprot_val and pgprot_t could never be bigger
> than unsigned long. But this assumption soon will
On Fri, Jan 10, 2025 at 06:40:29PM +, Brendan Jackman wrote:
> Subject: Re: [PATCH RFC v2 03/29] mm: asi: Introduce ASI core API
x86/asi: ...
> Introduce core API for Address Space Isolation (ASI). Kernel address
> space isolation provides the ability to run some kernel
> code with a restric
16 matches
Mail list logo
