linux-mips
[Top] [All Lists]

Re: [PATCH] MIPS: fix forced successful syscalls

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] MIPS: fix forced successful syscalls
From: Tanguy Bouzeloc <tanguy.bouzeloc@efixo.com>
Date: Thu, 03 Oct 2013 16:53:31 +0200
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-reply-to: <20131002091909.GA23236@linux-mips.org>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1380550969-9522-1-git-send-email-tanguy.bouzeloc@efixo.com> <20131002091909.GA23236@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9
On 10/02/2013 11:19 AM, Ralf Baechle wrote:
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" (&regs));
         /* 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


I discover the issue when changing the HZ of the kernel to 100HZ, in this case the jiffies returned to the userland are the same as the kernel ticks and it'll wrap after 5 minutes of uptime. With kernel HZ at 250 or 1000H it'll make happen the ticks wrap after 230~260j.

Unfortunately programs relying on ticks (they shouldn't but that happens) have unpredictable behavior for 11.3s before the wrap.

I can update the patch in order to access atomically the thread flags, the point is ... it'll make the kernel incompatible with old hardware.

Regards,
Tanguy.

<Prev in Thread] Current Thread [Next in Thread>