From: Arnd Bergmann <arnd@arndb.de>
To: Vincent Chen <deanbo422@gmail.com>
Cc: Greentime <greentime@andestech.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jason Cooper <jason@lakedaemon.net>,
Marc Zyngier <marc.zyngier@arm.com>,
Rob Herring <robh+dt@kernel.org>,
Networking <netdev@vger.kernel.org>,
Vincent Chen <vincentc@andestech.com>
Subject: Re: FW: [PATCH 15/31] nds32: System calls handling
Date: Mon, 13 Nov 2017 12:42:41 +0100 [thread overview]
Message-ID: <CAK8P3a0nLTbTE4SuRPVSDKzeOs0TCejfhDA1RccmYVPyWdiHHQ@mail.gmail.com> (raw)
In-Reply-To: <CAJsyPhzVyV43-N4R+ckXVauceCoeXK24P9Swup2_kpbL866naQ@mail.gmail.com>
On Mon, Nov 13, 2017 at 3:51 AM, Vincent Chen <deanbo422@gmail.com> wrote:
>>>On Wed, Nov 8, 2017 at 6:55 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>> From: Greentime Hu <greentime@andestech.com>
>
>>> +#define __ARCH_WANT_SYS_CLONE
>>
>>This seems ok, though it would be nice to have the reverse logic and have architectures opt-out of the generic version when they need to provide their own, rather than having most architectures set it.
>>
>
> Thanks
> I will provide nds32 SYSCALL_DEFINE_5(clone) in the next version patch.
That's not what I meant, my suggestion is to create a new patch to remove the
__ARCH_WANT_SYS_CLONE symbol from all architectures, and instead use
something like __ARCH_HAVE_SYS_CLONE on architectures that do *not*
want the generic implementation.
nds32 clearly wants the generic implementation here, it just shouldn't have to
select that symbol to get it.
>>> +/*
>>> + * Special system call wrappers
>>> + *
>>> + * $r0 = syscall number
>>> + * $r8 = syscall table
>>> + */
>>> + .type sys_syscall, #function
>>> +ENTRY(sys_syscall)
>>> + addi $p1, $r0, #-__NR_syscalls
>>> + bgtz $p1, 3f
>>> + move $p1, $r0
>>> + move $r0, $r1
>>> + move $r1, $r2
>>> + move $r2, $r3
>>> + move $r3, $r4
>>> + move $r4, $r5
>>> +! add for syscall 6 args
>>> + lwi $r5, [$sp + #SP_OFFSET ]
>>> + lwi $r5, [$r5]
>>> +! ~add for syscall 6 args
>>> +
>>> + lw $p1, [tbl+$p1<<2]
>>> .+ jr $p1
>>> +3: b sys_ni_syscall
>>> +ENDPROC(sys_syscall)
>>
>>Can you explain what this is used for?
>>
>
> This is used to handle syscall(int number, ....).
> Unlike other architectures, the system number shall be determined in
> compile time when issuing system call in nds32.
> Therefore, we only can parse the content of syscall(int number, ....)
> and distribute it to destination handler in kernel space
> (Other architecture can handle it in user space by glibc's syscall wrapper)
Hmm, I think other architectures that run into this problem use self-modifying
code for syscall(), but that is also ugly as it requires having a page that
is both writable and executable.
I think your approach can be tricky for things like seccomp(). It's possible
that you get all of it right, but if you can come up with a different solution,
that might be better.
How much would it cost to simply always pass the syscall number
in a register, and not use the immediate argument at all?
>>> --- /dev/null
>>> +++ b/arch/nds32/kernel/sys_nds32.c
>>> +
>>> +long sys_mmap2(unsigned long addr, unsigned long len,
>>> + unsigned long prot, unsigned long flags,
>>> + unsigned long fd, unsigned long pgoff) {
>>> + if (pgoff & (~PAGE_MASK >> 12))
>>> + return -EINVAL;
>>> +
>>> + return sys_mmap_pgoff(addr, len, prot, flags, fd,
>>> + pgoff >> (PAGE_SHIFT - 12)); }
>>> +
>>> +asmlinkage long sys_fadvise64_64_wrapper(int fd, int advice, loff_t offset,
>>> + loff_t len) {
>>> + return sys_fadvise64_64(fd, offset, len, advice); }
>>
>>You should always use SYSCALL_DEFINE*() macros to define entry points for your own syscalls in C code for consistency. I also wonder if we should just move those two into common code, a lot of architectures need the first one in particular.
>>
>
> The sys_fadvise64_64_wrapper is used to reorder the input parameter.
>
> In order to solve register alignment problem, we adjust the input
> parameter order of fadvise64_64 while issuing this syscall.
> Therefore, we need this wrapper to reorder the input parameter to fit
> sys_fadvise64_64's API in kernel.
I understand what it's used for, it's just that I would recommend writing it
differently, as
SYSCALL_DEFINE4(fadvise64_64_wrapper, int, fd, int, advice, loff_t,
offset, loff_t, len)
{
return sys_fadvise64_64(fd, offset, len, advice);
}
Arnd
next prev parent reply other threads:[~2017-11-13 11:42 UTC|newest]
Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-08 5:54 [PATCH 00/31] Andes(nds32) Linux Kernel Port Greentime Hu
2017-11-08 5:54 ` [PATCH 01/31] nds32: Assembly macros and definitions Greentime Hu
2017-11-08 5:54 ` [PATCH 02/31] nds32: Kernel booting and initialization Greentime Hu
2017-11-08 13:38 ` Rob Herring
2017-11-09 9:49 ` Greentime Hu
2017-11-08 5:54 ` [PATCH 03/31] nds32: Support early_printk Greentime Hu
2017-11-08 9:47 ` Tobias Klauser
2017-11-09 7:19 ` Greentime Hu
2017-11-08 5:54 ` [PATCH 04/31] nds32: Exception handling Greentime Hu
2017-11-08 8:23 ` Arnd Bergmann
[not found] ` <E26F4CF8B7DDDB4383A6C2D78D5C3CD56B4974CE@ATCPCS16.andestech.com>
2017-11-13 10:54 ` Fwd: FW: " Vincent Chen
2017-11-08 5:54 ` [PATCH 05/31] nds32: MMU definitions Greentime Hu
2017-11-08 8:36 ` Arnd Bergmann
2017-11-08 8:46 ` Greentime Hu
2017-11-08 5:54 ` [PATCH 06/31] nds32: MMU initialization Greentime Hu
2017-11-08 5:54 ` [PATCH 07/31] nds32: MMU fault handling and page table management Greentime Hu
2017-11-08 5:54 ` [PATCH 08/31] nds32: Cache and TLB routines Greentime Hu
2017-11-08 8:45 ` Arnd Bergmann
2017-11-08 9:01 ` Greentime Hu
2017-11-08 5:54 ` [PATCH 09/31] nds32: Process management Greentime Hu
2017-11-08 5:54 ` [PATCH 10/31] nds32: IRQ handling Greentime Hu
2017-11-08 8:49 ` Arnd Bergmann
2017-11-08 9:06 ` Greentime Hu
2017-11-08 5:54 ` [PATCH 11/31] nds32: Atomic operations Greentime Hu
2017-11-08 8:54 ` Arnd Bergmann
2017-11-08 9:32 ` vincentc
2017-11-20 14:29 ` Will Deacon
2017-11-22 3:02 ` Vincent Chen
2017-11-08 5:55 ` [PATCH 12/31] nds32: Device specific operations Greentime Hu
2017-11-08 9:04 ` Arnd Bergmann
2017-11-09 7:04 ` Greentime Hu
2017-11-10 16:07 ` Greentime Hu
2017-11-10 16:14 ` Arnd Bergmann
2017-11-22 10:02 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 13/31] nds32: DMA mapping API Greentime Hu
2017-11-08 9:09 ` Arnd Bergmann
2017-11-09 7:12 ` Greentime Hu
2017-11-09 10:14 ` Arnd Bergmann
2017-11-10 8:13 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 14/31] nds32: ELF definitions Greentime Hu
2017-11-08 5:55 ` [PATCH 15/31] nds32: System calls handling Greentime Hu
2017-11-08 9:30 ` Arnd Bergmann
[not found] ` <E26F4CF8B7DDDB4383A6C2D78D5C3CD56B497241@ATCPCS16.andestech.com>
2017-11-13 2:51 ` Fwd: FW: " Vincent Chen
2017-11-13 11:42 ` Arnd Bergmann [this message]
2017-11-22 3:13 ` Vincent Chen
2017-11-08 5:55 ` [PATCH 16/31] nds32: VDSO support Greentime Hu
2017-11-08 9:37 ` Arnd Bergmann
2017-11-08 20:00 ` Deepa Dinamani
2017-11-08 20:06 ` Arnd Bergmann
2017-11-08 20:14 ` Deepa Dinamani
2017-11-08 5:55 ` [PATCH 17/31] nds32: Signal handling support Greentime Hu
2017-11-09 1:26 ` Al Viro
[not found] ` <E26F4CF8B7DDDB4383A6C2D78D5C3CD56B497460@ATCPCS16.andestech.com>
2017-11-13 2:34 ` Fwd: FW: " Vincent Chen
2017-11-08 5:55 ` [PATCH 18/31] nds32: Library functions Greentime Hu
2017-11-08 9:45 ` Arnd Bergmann
2017-11-09 0:40 ` Al Viro
[not found] ` <E26F4CF8B7DDDB4383A6C2D78D5C3CD56B497559@ATCPCS16.andestech.com>
2017-11-14 4:47 ` Fwd: FW: " Vincent Chen
2017-11-18 2:44 ` Al Viro
2017-11-08 5:55 ` [PATCH 19/31] nds32: Debugging support Greentime Hu
2017-11-08 5:55 ` [PATCH 20/31] nds32: L2 cache support Greentime Hu
2017-11-08 9:48 ` Arnd Bergmann
2017-11-09 7:24 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 21/31] nds32: Loadable modules Greentime Hu
2017-11-08 5:55 ` [PATCH 22/31] nds32: Generic timers support Greentime Hu
2017-11-08 5:55 ` [PATCH 23/31] nds32: Device tree support Greentime Hu
2017-11-08 9:53 ` Arnd Bergmann
2017-11-09 7:48 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 24/31] nds32: Miscellaneous header files Greentime Hu
2017-11-08 9:57 ` Arnd Bergmann
2017-11-08 5:55 ` [PATCH 25/31] nds32: defconfig Greentime Hu
2017-11-08 10:03 ` Arnd Bergmann
2017-11-09 8:00 ` Greentime Hu
2017-11-09 10:20 ` Arnd Bergmann
2017-11-10 8:16 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 26/31] nds32: Build infrastructure Greentime Hu
2017-11-08 10:16 ` Arnd Bergmann
2017-11-09 9:02 ` Greentime Hu
2017-11-09 10:33 ` Arnd Bergmann
2017-11-10 8:26 ` Greentime Hu
2017-11-17 12:39 ` Greentime Hu
2017-11-17 12:50 ` Arnd Bergmann
2017-11-17 13:50 ` Greentime Hu
2017-11-13 10:45 ` Geert Uytterhoeven
2017-11-16 10:03 ` Greentime Hu
2017-11-16 10:25 ` Arnd Bergmann
2017-11-17 13:53 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 27/31] dt-bindings: interrupt-controller: Andestech Internal Vector Interrupt Controller Greentime Hu
2017-11-08 13:25 ` Rob Herring
2017-11-09 9:43 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 28/31] irqchip: Andestech Internal Vector Interrupt Controller driver Greentime Hu
2017-11-08 14:24 ` Marc Zyngier
2017-11-09 10:10 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 29/31] MAINTAINERS: Add nds32 Greentime Hu
2017-11-08 13:31 ` Rob Herring
2017-11-09 9:46 ` Greentime Hu
2017-11-09 10:36 ` Arnd Bergmann
2017-11-14 15:39 ` Joe Perches
2017-11-16 12:22 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 30/31] dt-bindings: nds32 CPU Bindings Greentime Hu
2017-11-08 13:18 ` Rob Herring
2017-11-09 9:39 ` Greentime Hu
2017-11-09 13:57 ` Rob Herring
2017-11-10 6:22 ` Greentime Hu
2017-11-10 8:25 ` Arnd Bergmann
2017-11-10 8:43 ` Greentime Hu
2017-11-08 5:55 ` [PATCH 31/31] net: faraday add nds32 support Greentime Hu
2017-11-08 8:32 ` [PATCH 00/31] Andes(nds32) Linux Kernel Port David Howells
2017-11-08 8:41 ` Greentime Hu
2017-11-08 10:18 ` Arnd Bergmann
2017-11-09 9:26 ` Greentime Hu
2017-11-08 10:26 ` Arnd Bergmann
2017-11-09 9:33 ` Greentime Hu
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=CAK8P3a0nLTbTE4SuRPVSDKzeOs0TCejfhDA1RccmYVPyWdiHHQ@mail.gmail.com \
--to=arnd@arndb.de \
--cc=deanbo422@gmail.com \
--cc=greentime@andestech.com \
--cc=jason@lakedaemon.net \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=netdev@vger.kernel.org \
--cc=robh+dt@kernel.org \
--cc=tglx@linutronix.de \
--cc=vincentc@andestech.com \
/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;
as well as URLs for NNTP newsgroup(s).