From: Mike Frysinger <vapier@gentoo.org>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: Ralf Baechle <ralf@linux-mips.org>, libc-ports@sourceware.org
Subject: Re: [PATCH][BZ #15054] MIPS: Fix syscall wrappers for syscall restart support
Date: Wed, 23 Jan 2013 18:13:00 -0000 [thread overview]
Message-ID: <201301231317.34359.vapier@gentoo.org> (raw)
In-Reply-To: <alpine.DEB.1.10.1301230518180.4834@tp.orcam.me.uk>
[-- Attachment #1: Type: Text/Plain, Size: 1592 bytes --]
On Wednesday 23 January 2013 00:40:24 Maciej W. Rozycki wrote:
> On Wed, 23 Jan 2013, Mike Frysinger wrote:
> > > We have an issue with the INTERNAL_SYSCALL_NCS wrapper in that it does
> > > not respect the kernel's syscall restart convention.
> > >
> > > That convention requires the instruction immediately preceding SYSCALL
> > > to initialize $v0 with the syscall number. Then if a restart triggers,
> > > $v0 will have been clobbered by the syscall interrupted, and needs to
> > > be reinititalized. The kernel will decrement the PC by 4 before
> > > switching back to the user mode so that $v0 has been reloaded before
> > > SYSCALL is executed again. This implies the place $v0 is loaded from
> > > must be preserved across a syscall, e.g. an immediate, static
> > > register, stack slot, etc.
> >
> > naïvely, but why can't the mips kernel paths take care of the reload
> > itself ? other arches have scratch space in their pt_regs for doing just
> > this (a bunch of arches use the orig_<reg> convention).
>
> I agree it would be the most reasonable approach if designing from
> scratch; unfortunately what we have is how the ABI has been set back in
> 1994. You won't be able to patch up all the kernel binaries out there,
> sigh...
sure, you won't be able to retroactively fixing kernels. but you'll be able to
make future kernels more robust against shady userlands. as you've pointed
out, this is an extremely subtle bug that can easily go unnoticed for a long
time which simply injects random flakiness into the runtime system.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2013-01-23 18:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 3:09 Maciej W. Rozycki
2013-01-23 5:05 ` Mike Frysinger
2013-01-23 5:40 ` Maciej W. Rozycki
2013-01-23 18:13 ` Mike Frysinger [this message]
2013-01-29 18:12 ` Maciej W. Rozycki
2013-01-29 19:04 ` Ralf Baechle
2013-01-29 19:12 ` Maciej W. Rozycki
2013-01-30 1:26 ` Ralf Baechle
2013-01-30 6:50 ` Mike Frysinger
2013-01-23 17:06 ` Joseph S. Myers
2013-01-24 12:47 ` Maciej W. Rozycki
2013-01-24 16:31 ` Joseph S. Myers
2013-01-29 18:10 ` Maciej W. Rozycki
2013-01-29 23:59 ` Joseph S. Myers
2013-02-05 15:26 ` Maciej W. Rozycki
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=201301231317.34359.vapier@gentoo.org \
--to=vapier@gentoo.org \
--cc=libc-ports@sourceware.org \
--cc=macro@codesourcery.com \
--cc=ralf@linux-mips.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 read-only IMAP folder(s) and NNTP newsgroup(s).