From patchwork Sun Mar 13 15:17:01 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nix X-Patchwork-Id: 11328 Received: (qmail 57078 invoked by alias); 13 Mar 2016 15:19:29 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 57063 invoked by uid 89); 13 Mar 2016 15:19:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.4 required=5.0 tests=AWL, BAYES_50, KAM_LAZY_DOMAIN_SECURITY, RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Hx-languages-length:2262, sk:nickal, 3097, 3096 X-HELO: mail.esperi.org.uk From: Nix To: libc-alpha@sourceware.org Subject: [PATCH 16/17 v5] x86, pthread_cond_*wait: Do not depend on %eax not being clobbered Date: Sun, 13 Mar 2016 15:17:01 +0000 Message-Id: <1457882222-22599-17-git-send-email-nix@esperi.org.uk> In-Reply-To: <1457882222-22599-1-git-send-email-nix@esperi.org.uk> References: <1457882222-22599-1-git-send-email-nix@esperi.org.uk> X-DCC-wuwien-Metrics: spindle 1290; Body=1 Fuz1=1 Fuz2=1 From: Nick Alcock The x86-specific versions of both pthread_cond_wait and pthread_cond_timedwait have (in their fall-back-to-futex-wait slow paths) calls to __pthread_mutex_cond_lock_adjust followed by __pthread_mutex_unlock_usercnt, which load the parameters before the first call but then assume that the first parameter, in %eax, will survive unaffected. This happens to have been true before now, but %eax is a call-clobbered register, and this assumption is not safe: it could change at any time, at GCC's whim, and indeed the stack-protector canary checking code clobbers %eax while checking that the canary is uncorrupted. So reload %eax before calling __pthread_mutex_unlock_usercnt. (Do this unconditionally, even when stack-protection is not in use, because it's the right thing to do, it's a slow path, and anything else is dicing with death.) v5: New. * sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S: Reload call-clobbered %eax on retry path. * sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S: Likewise. --- sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S | 1 + sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S | 1 + 2 files changed, 2 insertions(+) diff --git a/sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S b/sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S index 96f8a8d..6256376 100644 --- a/sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S +++ b/sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S @@ -297,6 +297,7 @@ __pthread_cond_timedwait: correctly. */ movl dep_mutex(%ebx), %eax call __pthread_mutex_cond_lock_adjust + movl dep_mutex(%ebx), %eax xorl %edx, %edx call __pthread_mutex_unlock_usercnt jmp 8b diff --git a/sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S b/sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S index 94302b0..5016718 100644 --- a/sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S +++ b/sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S @@ -309,6 +309,7 @@ __pthread_cond_wait: correctly. */ movl dep_mutex(%ebx), %eax call __pthread_mutex_cond_lock_adjust + movl dep_mutex(%ebx), %eax xorl %edx, %edx call __pthread_mutex_unlock_usercnt jmp 8b