From: Ingo Molnar <mingo@kernel.org>
To: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: linux-kernel@vger.kernel.org, viro@ZenIV.linux.org.uk,
torvalds@linux-foundation.org, arnd@arndb.de,
linux-arch@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Andy Lutomirski <luto@kernel.org>,
Brian Gerst <brgerst@gmail.com>,
Denys Vlasenko <dvlasenk@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
x86@kernel.org
Subject: Re: [PATCH 0/7] use struct pt_regs based syscall calling for x86-64
Date: Fri, 30 Mar 2018 12:16:02 +0200 [thread overview]
Message-ID: <20180330101602.ongosnigfmdmgayb@gmail.com> (raw)
In-Reply-To: <20180330093720.6780-1-linux@dominikbrodowski.net>
* Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> A few questions remain, from important stuff to bikeshedding:
>
> 1) Is it acceptable to pass the existing struct pt_regs to the sys_*()
> kernel functions in emulate_vsyscall(), or should it use a hand-crafted
> struct pt_regs instead?
I think so: we already have task_pt_regs() which gives access to the real return
registers on the kernel stack.
I think as long as we constify the pointer, we should pass in the real thing.
> 2) Is it the right approach to generate the __sys32_ia32_*() names to
> include in the syscall table on-the-fly, or should they all be listed
> in arch/x86/entry/syscalls/syscall_32.tbl ?
I think as a general principle all system call tables should point to the
first-hop wrapper symbol name (i.e. __sys32_ia32_*() in this case), not to the
generic symbol name - even though we could generate the former from the latter.
The more indirection in these tables, the harder to read they become I think.
> 3) I have chosen to name the default 64-bit syscall stub sys_*(), same as
> the "normal" syscall, and the IA32_EMULATION compat syscall stub
> compat_sys_*(), same as the "normal" compat syscall. Though this
> might cause some confusion, as the "same" function uses a different
> calling convention and different parameters on x86, it has the
> advantages that
> - the kernel *has* a function sys_*() implementing the syscall,
> so those curious in stack traces etc. will find it in plain
> sight,
> - it is easier to handle in the syscall table generation, and
> - error injection works the same.
I don't think there should be a symbol space overlap, that will only lead to
confusion. The symbols can be _similar_, with a prefix, underscores or so, but
they shouldn't match I think.
> The whole series is available at
>
> https://git.kernel.org/pub/scm/linux/kernel/git/brodo/linux.git syscalls-WIP
BTW., I'd like all these bits to go through the x86 tree.
What is the expected merge route of the generic preparatory bits?
Thanks,
Ingo
next prev parent reply other threads:[~2018-03-30 10:16 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-30 9:37 [PATCH 0/7] use struct pt_regs based syscall calling for x86-64 Dominik Brodowski
2018-03-30 9:37 ` Dominik Brodowski
2018-03-30 9:37 ` [PATCH 1/7] x86: don't pointlessly reload the system call number Dominik Brodowski
2018-03-30 9:37 ` Dominik Brodowski
2018-03-30 9:37 ` [PATCH 2/7] syscalls: introduce CONFIG_ARCH_HAS_SYSCALL_WRAPPER Dominik Brodowski
2018-03-30 9:37 ` Dominik Brodowski
2018-03-30 9:37 ` [PATCH 3/7] syscalls/x86: use struct pt_regs based syscall calling for 64bit syscalls Dominik Brodowski
2018-03-30 9:37 ` Dominik Brodowski
2018-03-30 9:37 ` [PATCH 4/7] syscalls: prepare ARCH_HAS_SYSCALL_WRAPPER for compat syscalls Dominik Brodowski
2018-03-30 9:37 ` Dominik Brodowski
2018-03-30 9:37 ` [PATCH 5/7] syscalls/x86: use struct pt_regs based syscall calling for IA32_EMULATION and x32 Dominik Brodowski
2018-03-30 9:37 ` Dominik Brodowski
2018-03-30 9:37 ` [PATCH 6/7] syscalls/x86: unconditionally enable struct pt_regs based syscalls on x86_64 Dominik Brodowski
2018-03-30 9:37 ` Dominik Brodowski
2018-03-30 9:37 ` [PATCH 7/7] x86/entry/64: extend register clearing on syscall entry to lower registers Dominik Brodowski
2018-03-30 9:37 ` Dominik Brodowski
2018-03-30 10:10 ` Ingo Molnar
2018-03-30 10:10 ` Ingo Molnar
2018-03-30 10:16 ` Ingo Molnar [this message]
2018-03-30 10:16 ` [PATCH 0/7] use struct pt_regs based syscall calling for x86-64 Ingo Molnar
2018-03-30 10:46 ` Dominik Brodowski
2018-03-30 10:46 ` Dominik Brodowski
2018-03-30 11:03 ` Ingo Molnar
2018-03-30 11:03 ` Ingo Molnar
2018-03-30 11:48 ` Dominik Brodowski
2018-03-30 11:48 ` Dominik Brodowski
2018-03-30 12:00 ` Ingo Molnar
2018-03-30 12:00 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180330101602.ongosnigfmdmgayb@gmail.com \
--to=mingo@kernel.org \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=brgerst@gmail.com \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@ZenIV.linux.org.uk \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox