From: Michael Cree <mcree@orcon.net.nz>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>,
linux-arm-kernel@lists.infradead.org,
linux-arch <linux-arch@vger.kernel.org>,
linux-api <linux-api@vger.kernel.org>,
linux-alpha@vger.kernel.org
Subject: Re: [PATCH 2/3] ARM: convert to generated system call tables
Date: Wed, 26 Oct 2016 20:04:30 +1300 [thread overview]
Message-ID: <20161026070430.e2tkbzza5lk4lgju@tower> (raw)
In-Reply-To: <4146248.jXuviLlvH5@wuerfel>
On Tue, Oct 25, 2016 at 12:28:16PM +0200, Arnd Bergmann wrote:
> On Tuesday, October 25, 2016 10:12:10 PM CEST Michael Cree wrote:
> > On Fri, Oct 21, 2016 at 03:06:45PM +0200, Arnd Bergmann wrote:
> > > I see your point, but I think there are serious issues with the current
> > > approach as well:
> > >
> > > - a lot of the less common architectures just don't get updated
> > > in time, out of 22 architectures that don't use asm-generic/unistd.h,
> > > only 12 have pwritev2 in linux-next, and only three have pkey_mprotect
> > >
> > > - some architectures that add all syscalls sometimes make a mistake
> > > and forget one, e.g. alpha apparently never added __NR_bpf, but it
> > > did add the later __NR_execveat.
> >
> > __NR_bpf was not forgotten on Alpha. It was not wired up because
> > extra architecture support is needed which has not been implemented.
> >
> > But maybe we should just wire it up to sys_ni_syscall in the meantime
> > so a syscall number is reserved for it, and user space can call it to
> > get -ENOSYS returned.
>
> Ah, I must have misinterpreted the code then. I assumed that the
> bpf syscall always works on all architectures, but that only the
> jit compiler for it required architecture specific code to make it
> more efficient.
Oh. When someone posted wiring up of syscalls on Alpha some time
back I raised a query about seccomp then someone else (I can't be
bothered looking up the old emails, it doesn't really matter)
said bpf was in the same basket, so the patch was re-submitted with
neither of those syscalls.
> sys_seccomp is another one that falls into a similar category, but
> it already depends on HAVE_ARCH_SECCOMP_FILTER, and most other
> architectures have assigned a syscall number but not set this symbol.
> This one will actually allow you to set strict seccomp mode even
> without the Kconfig symbol, just not allow to set a filter.
We have got way behind on syscalls on Alpha and I was just in the
process of wiring them up and testing them, so I will include both
seccomp and bpf in that.
Cheers
Michael.
next prev parent reply other threads:[~2016-10-26 7:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1bwa6s-0004ZY-4k@rmk-PC.armlinux.org.uk>
[not found] ` <13702107.LdHY4HTXyY@wuerfel>
[not found] ` <20161019155325.GR1041@n2100.armlinux.org.uk>
2016-10-21 13:06 ` [PATCH 2/3] ARM: convert to generated system call tables Arnd Bergmann
2016-10-21 13:37 ` Russell King - ARM Linux
[not found] ` <20161021133708.GA1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
2016-10-21 15:18 ` Arnd Bergmann
2016-10-21 15:48 ` Russell King - ARM Linux
[not found] ` <20161021154856.GC1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
2016-10-21 16:48 ` Joseph Myers
[not found] ` <alpine.DEB.2.20.1610211641430.27636-9YEB1lltEqivcGRMvF24k2I39yigxGEX@public.gmane.org>
2016-10-21 16:57 ` Russell King - ARM Linux
2016-10-21 20:35 ` Arnd Bergmann
2016-10-22 20:23 ` Robert Jarzmik
2016-10-24 9:25 ` Geert Uytterhoeven
[not found] ` <CAMuHMdVy_h6Uss9bwVK5hGD42bXeEBcBsBDwCpx_eYnT9r+=Lw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-10-26 20:14 ` Robert Jarzmik
2016-10-24 9:29 ` Geert Uytterhoeven
2016-10-25 9:12 ` Michael Cree
2016-10-25 10:28 ` Arnd Bergmann
2016-10-25 17:03 ` Richard Henderson
2016-10-25 17:09 ` Geert Uytterhoeven
2016-10-26 7:04 ` Michael Cree [this message]
2016-10-26 9:12 ` bpf on Alpha [was Re: [PATCH 2/3] ARM: convert to generated system call tables] Michael Cree
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=20161026070430.e2tkbzza5lk4lgju@tower \
--to=mcree@orcon.net.nz \
--cc=arnd@arndb.de \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@armlinux.org.uk \
/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).