From patchwork Tue Mar 8 13:51:03 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nix X-Patchwork-Id: 594227 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 73C7C140662 for ; Wed, 9 Mar 2016 00:55:42 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b=PdP6aODV; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:in-reply-to :references; q=dns; s=default; b=h0piT/AB/iG9e+bzQHN3soUrA/FsyJY z+xkntOtKbjLwUbJD1ktbeOeLVPAv5zKzMGvlVesL8af+gyBsH61DbDN52F3nF82 NwmB3f8eH7VhTEd5QdFsf8BXwAVKhfNVbSVUeQd+Wo2dph9h87BTFKPapK/6Mfo0 wakfrVyLBvb8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id:in-reply-to :references; s=default; bh=TgqFFf1BCWxjqEl77idID2CK+Zg=; b=PdP6a ODVz514JBf+IJ/z85B89aTjqq3/1Ut3EKOn+WJoU2emZF1Oe7UvL97v+W3kj5BM0 e85UUSDBWMS99q8w9n3qH/ssZ6XgRxGMXtttOE/QiplbDpZseQgnCUswR+kS5lwg sH22o5DOvZdtKm6lSvgC8wo1PJmaqjgcvrVoB8= Received: (qmail 39983 invoked by alias); 8 Mar 2016 13:55:34 -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 39877 invoked by uid 89); 8 Mar 2016 13:55:33 -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:2259, canary, Hx-spam-relays-external:sk:mail.es, H*r:sk:mail.es X-HELO: mail.esperi.org.uk From: Nix To: libc-alpha@sourceware.org Subject: [PATCH 17/18] x86, pthread_cond_*wait: Do not depend on %eax not being clobbered Date: Tue, 8 Mar 2016 13:51:03 +0000 Message-Id: <1457445064-7107-18-git-send-email-nix@esperi.org.uk> In-Reply-To: <1457445064-7107-1-git-send-email-nix@esperi.org.uk> References: <1457445064-7107-1-git-send-email-nix@esperi.org.uk> X-DCC--Metrics: spindle 1282; Body=2 Fuz1=2 Fuz2=2 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