From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25118 invoked by alias); 29 Jan 2013 18:12:25 -0000 Received: (qmail 25104 invoked by uid 22791); 29 Jan 2013 18:12:24 -0000 X-SWARE-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Jan 2013 18:12:20 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1U0FfO-0007kH-9T from Maciej_Rozycki@mentor.com ; Tue, 29 Jan 2013 10:12:18 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jan 2013 10:12:17 -0800 Received: from [172.30.5.53] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 29 Jan 2013 18:12:15 +0000 Date: Tue, 29 Jan 2013 18:12:00 -0000 From: "Maciej W. Rozycki" To: Ralf Baechle , Mike Frysinger CC: Subject: Re: [PATCH][BZ #15054] MIPS: Fix syscall wrappers for syscall restart support In-Reply-To: <201301231317.34359.vapier@gentoo.org> Message-ID: References: <201301230009.23864.vapier@gentoo.org> <201301231317.34359.vapier@gentoo.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2013-01/txt/msg00075.txt.bz2 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_ 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. That's not unreasonable, I agree. Ralf, what do you think? Maciej