From: Ingo Molnar <mingo@kernel.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Christoph Hellwig <hch@infradead.org>,
Rabin Vincent <rabin@rab.in>,
linux-arm-kernel@lists.infradead.org,
Ingo Molnar <mingo@redhat.com>,
linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH] tracing/syscalls: ignore numbers outside NR_syscalls' range
Date: Fri, 31 Oct 2014 11:01:53 +0100 [thread overview]
Message-ID: <20141031100153.GA23722@gmail.com> (raw)
In-Reply-To: <20141030101808.GO27405@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Thu, Oct 30, 2014 at 01:26:06AM -0700, Christoph Hellwig wrote:
> > On Wed, Oct 29, 2014 at 11:06:58PM +0100, Rabin Vincent wrote:
> > > ARM has some private syscalls (for example, set_tls(2)) which lie
> > > outside the range of NR_syscalls. If any of these are called while
> > > syscall tracing is being performed, out-of-bounds array access will
> > > occur in the ftrace and perf sys_{enter,exit} handlers.
> >
> > While this patch looks like good caution, having syscalls
> > outside of NR_syscalls seems like a receipe for a disaster.
> > Can you try to fix that issue as ell, please?
>
> No. We've had them since the inception of Linux on ARM. They
> predate this tracing crap by more than a decade. We're not
> changing them because that would be a massive user API
> breakage.
So if you go around calling other people's code 'crap' so easily:
if we should call something 'crap' in this area it's the decision
of ARM to deviate from all other architectures arbitrarily and to
introduce 'private' syscalls outside NR_syscalls...
There's a reason why we have NR_syscalls with relatively tighly
packed syscall numbers and there's a reason why we don't do
'private' syscalls on other architectures.
I'd probably have NAK-ed ARM's 'private syscalls' had I known
about it when this was introduced for ARM. IMO you should be
ashamed for it instead of blaming others for the complication ...
But yes, it's probably an ABI, albeit a crappy one, which is now
hurting the introduction of a generic kernel facility in the ARM
space.
Thanks,
Ingo
prev parent reply other threads:[~2014-10-31 10:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-29 22:06 [PATCH] tracing/syscalls: ignore numbers outside NR_syscalls' range Rabin Vincent
2014-10-30 8:26 ` Christoph Hellwig
2014-10-30 10:18 ` Russell King - ARM Linux
2014-10-30 11:10 ` Steven Rostedt
2014-10-30 11:14 ` Russell King - ARM Linux
2014-10-30 11:30 ` Steven Rostedt
2014-10-30 11:35 ` Russell King - ARM Linux
2014-11-03 17:08 ` Nathan Lynch
2014-11-03 17:58 ` Steven Rostedt
2014-10-30 11:52 ` Steven Rostedt
2014-10-30 11:55 ` Steven Rostedt
2014-10-31 10:01 ` Ingo Molnar [this message]
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=20141031100153.GA23722@gmail.com \
--to=mingo@kernel.org \
--cc=hch@infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mingo@redhat.com \
--cc=rabin@rab.in \
--cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).