Thread (22 messages) 22 messages, 4 authors, 2020-09-28

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 number
And 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help