Re: [PATCH 4/9] ARM: syscall: always store thread_info->syscall
From: Arnd Bergmann <arnd@arndb.de>
Date: 2020-09-28 12:43:04
Also in:
linux-arch, lkml
On Mon, Sep 28, 2020 at 11:41 AM Linus Walleij [off-list ref] wrote:
Hi Arnd, help me out here because I feel vaguely stupid... On Mon, Sep 7, 2020 at 5:38 PM Arnd Bergmann [off-list ref] wrote:quoted
{ + if (IS_ENABLED(CONFIG_OABI_COMPAT)) + return task_thread_info(task)->syscall & ~__NR_OABI_SYSCALL_BASE;Where __NR_OABI_SYSCALL_BASE is #define __NR_OABI_SYSCALL_BASE 0x900000 So you will end up with sycall number & FF6FFFFF masking off bits 20 and 23.
Right. I fixed a bug in here since I sent this, the correct version also needs to mask away the __NR_OABI_SYSCALL_BASE for a native oabi kernel, not just for an eabi kernel with oabi-compat mode.
I suppose this is based on this:quoted
bics r10, r10, #0xff000000 + str r10, [tsk, #TI_SYSCALL]OK we mask off bits 24-31 before we store this.quoted
bic scno, scno, #0xff000000 @ mask off SWI op-code + str scno, [tsk, #TI_SYSCALL]And here too.quoted
eor scno, scno, #__NR_SYSCALL_BASE @ check OS numberAnd then happens that which will ... I don't know really. Exclusive or with 0x9000000 is not immediately intuitive evident to me, I suppose it is for everyone else... :/
This is how the SWI/SVC immediate argument gets turned into a system call number that is used as an offset into the sys_call_table. OABI syscalls are called with '__NR_OABI_SYSCALL_BASE | scno' in the immediate argument of the instruction, so using an 'eor ... , #__NR_SYSCALL_BASE' means that any valid argument afterwards is a number between zero and __NR_syscalls, and any invalid argument is a number outside of that range EABI syscalls are just 'SVC 0' with the syscall number in register 7 and no offset. See also https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f2829a31573e3e502b874c8d69a765f7a778793
I need some idea how this numberspace is managed in order to understand the code so I can review it, I guess it all makes perfect sense but I need some background here.
I also had never understood this part before, and I'm still not
sure where the 0x900000 actually comes from, though my best
guess is that this was intended as a an OS specific number space,
with '9' being assigned to Linux (similar to the way Itanium and
MIPS do with their respective offsets). By the time EABI got added,
this was apparently no longer considered helpful.
Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel