From: Ralf Baechle <ralf@linux-mips.org>
To: Tanguy Bouzeloc <tanguy.bouzeloc@efixo.com>
Cc: linux-mips@linux-mips.org
Subject: Re: [PATCH] MIPS: fix forced successful syscalls
Date: Wed, 2 Oct 2013 11:19:09 +0200 [thread overview]
Message-ID: <20131002091909.GA23236@linux-mips.org> (raw)
In-Reply-To: <1380550969-9522-1-git-send-email-tanguy.bouzeloc@efixo.com>
On Mon, Sep 30, 2013 at 04:22:49PM +0200, Tanguy Bouzeloc wrote:
> Date: Mon, 30 Sep 2013 16:22:49 +0200
> From: Tanguy Bouzeloc <tanguy.bouzeloc@efixo.com>
> To: ralf@linux-mips.org
> Cc: linux-mips@linux-mips.org, Tanguy Bouzeloc <tanguy.bouzeloc@efixo.com>
> Subject: [PATCH] MIPS: fix forced successful syscalls
>
> On mips any syscalls who return a value between -MAXERRNO (1133) and
> -1, is considered as an error (the error flag is set and return value
> is the positive value of the error number).
>
> But some syscalls can return values between -MAXERRNO and -1 like
> sys_time and sys_times. In this case the userspace return value is
> -return value of the syscall and the error flag set.
>
> This patch add a TIF_NOERROR thread flag which indicates that the
> return value of a syscall is always correct.
To my personal embarassment I have to admit that I knew about this since the
day the syscall wrapper was written - but was considering it an acceptable
bug ...
Where it really bits is sigreturn and similar which use the following
stunt:
/*
* Don't let your children do this ...
*/
__asm__ __volatile__(
"move\t$29, %0\n\t"
"j\tsyscall_exit"
:/* no outputs */
:"r" (®s));
/* Unreached */
to keep the syscall return path from tampering with the return value.
The scall*.S part of your patch is clearing TIF_NOERROR using a non-atomic
LW/SW sequence. This needs to be done atomically or the thread's flags
variable might get corrupted. This is complicated by MIPS I, R5900 and
afair some older oddball not-quite MIPS II CPUs lacking LL/SC rsp. LLD/SCD.
Ralf
next prev parent reply other threads:[~2013-10-02 9:19 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-30 14:22 [PATCH] MIPS: fix forced successful syscalls Tanguy Bouzeloc
2013-10-02 9:19 ` Ralf Baechle [this message]
2013-10-03 14:53 ` Tanguy Bouzeloc
2013-10-08 7:42 ` Ralf Baechle
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=20131002091909.GA23236@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=linux-mips@linux-mips.org \
--cc=tanguy.bouzeloc@efixo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.