From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6602 invoked by alias); 23 Jan 2013 18:13:32 -0000 Received: (qmail 6588 invoked by uid 22791); 23 Jan 2013 18:13:30 -0000 X-SWARE-Spam-Status: No, hits=-8.9 required=5.0 tests=AWL,BAYES_00,KHOP_PGP_SIGNED,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.gentoo.org (HELO smtp.gentoo.org) (140.211.166.183) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 23 Jan 2013 18:13:19 +0000 Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 0CD4533DB44; Wed, 23 Jan 2013 18:13:19 +0000 (UTC) From: Mike Frysinger To: "Maciej W. Rozycki" Subject: Re: [PATCH][BZ #15054] MIPS: Fix syscall wrappers for syscall restart support Date: Wed, 23 Jan 2013 18:13:00 -0000 User-Agent: KMail/1.13.7 (Linux/3.7.1; KDE/4.6.5; x86_64; ; ) Cc: Ralf Baechle , libc-ports@sourceware.org References: <201301230009.23864.vapier@gentoo.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4266418.kElbgbWMFo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201301231317.34359.vapier@gentoo.org> X-IsSubscribed: yes 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/msg00046.txt.bz2 --nextPart4266418.kElbgbWMFo Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 1590 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 do= es > > > not respect the kernel's syscall restart convention. > > >=20 > > > That convention requires the instruction immediately preceding SYSCA= LL > > > to initialize $v0 with the syscall number. Then if a restart trigger= s, > > > $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. > >=20 > > na=EFvely, 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). >=20 > 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 abl= e to=20 make future kernels more robust against shady userlands. as you've pointed= =20 out, this is an extremely subtle bug that can easily go unnoticed for a lon= g=20 time which simply injects random flakiness into the runtime system. -mike --nextPart4266418.kElbgbWMFo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. Content-length: 836 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJRACk+AAoJEEFjO5/oN/WBK8wQAIXFrctTgb41/cexTu1tUMVa WFbcpgSGCd6qLjvRL2sjWOQO9ry5y4MbGGCY5cSRguCbBL5+X6Tz3EIVkBeBnEmw 7UrauOD9V0D7ksGHgKRx/08HZIa4clwQfTkkp6nF29zKAVkDiIzuaxhUK2wWEaeI beckcwmSdRhd6uSh11TBgEyPVEjV7E1MkM+oyJkX9Vr/ui/QmabhnaHGW0Qxf3rd 0vekpwUaXIwZt3dzfq/j4HneQJsQlzB8vRYztEnol5blcEEnHnuDP+uCafBynKZK dVMgec4VPnAxJIJjAsz0cc6Yk2a07rKnh+Rpns2JIy4AlV/2HLgmZBfI+nT4R0nm sQIAH2zvpLQi0Q33B1f6NcDJCcuPQdz/HdjGw99FJOM++3nzRDeALW/+QYfBpWmx Kaz6PKmkbyQDWHGRV3vzyZOtSU8y8PcEMMhltyOcpLw/eg5IbZYsIAuKXJCiQwEd QV6U7k5VOy8PZN+LhHgbEDcLn91JjyzFC+s0A0yhMZVFETp/E4q+a+BSYsim6LFd 9ikgKqLHattGvj+JfTtFsE26nFjMM3KW2HzfbI6UInrgAL2kt28hANBgqp1fz2f5 /nQoSAC5F/tE+4V+lxudXnpbIYOyZuGP3h43ryxg76c60M23frC9m0h6/RJH7nXu QC/NF1mUu0/iPZLpYxYv =pXMg -----END PGP SIGNATURE----- --nextPart4266418.kElbgbWMFo--