public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: linux-ia64@vger.kernel.org
Subject: [PATCH] fix siglock
Date: Thu, 09 Sep 2010 16:56:02 +0000	[thread overview]
Message-ID: <4c8911a2302651c5f3@agluck-desktop.sc.intel.com> (raw)

When ia64 converted to using ticket locks, an inline implementation
of trylock/unlock in fsys.S was missed.  This was not noticed because
in most circumstances it simply resulted in using the slow path because
the siglock was apparently not available (under old spinlock rules).

Problems occur when the ticket spinlock has value 0x0 (when first
initialised, or when it wraps around). At this point the fsys.S
code acquires the lock (changing the 0x0 to 0x1. If another process
attempts to get the lock at this point, it will change the value from
0x1 to 0x2 (using new ticket lock rules). Then the fsys.S code will
free the lock using old spinlock rules by writing 0x0 to it. From
here a variety of bad things can happen.

---

This patch boots ... just started the stress test - running for ten
minutes (means nothing, it usually fails at about 1 hour for me).

diff --git a/arch/ia64/kernel/fsys.S b/arch/ia64/kernel/fsys.S
index 3567d54..a6c4695 100644
--- a/arch/ia64/kernel/fsys.S
+++ b/arch/ia64/kernel/fsys.S
@@ -424,14 +424,26 @@ EX(.fail_efault, ld8 r14=[r33])			// r14 <- *set
 	andcm r14=r14,r17			// filter out SIGKILL & SIGSTOP
 
 #ifdef CONFIG_SMP
-	mov r17=1
-	;;
-	cmpxchg4.acq r18=[r31],r17,ar.ccv	// try to acquire the lock
+	// __ticket_spin_trylock(r31)
+	ld4 r17=[r31]
 	mov r8=EINVAL			// default to EINVAL
 	;;
+	extr r9=r17,17,15
+	;;
+	xor r18=r17,r9
+	adds r19=1,r17
+	;;
+	extr.u r18=r18,0,15
+	;;
+	cmp.eq p0,p7=0,r18
+(p7)	br.cond.spnt.many .lock_contention
+	mov.m ar.ccv=r17
+	;;
+	cmpxchg4.acq r9=[r31],r19,ar.ccv
+	;;
+	cmp4.eq p0,p7=r9,r17
+(p7)	br.cond.spnt.many .lock_contention
 	ld8 r3=[r2]			// re-read current->blocked now that we hold the lock
-	cmp4.ne p6,p0=r18,r0
-(p6)	br.cond.spnt.many .lock_contention
 	;;
 #else
 	ld8 r3=[r2]			// re-read current->blocked now that we hold the lock
@@ -490,7 +502,17 @@ EX(.fail_efault, ld8 r14=[r33])			// r14 <- *set
 (p6)	br.cond.spnt.few 1b			// yes -> retry
 
 #ifdef CONFIG_SMP
-	st4.rel [r31]=r0			// release the lock
+	// __ticket_spin_unlock(r31)
+	adds r31=2,r31
+	;;
+	ld2.bias r2=[r31]
+	mov r3e534
+	;;
+	adds r2=2,r2
+	;;
+	and r3=r3,r2
+	;;
+	st2.rel [r31]=r3
 #endif
 	SSM_PSR_I(p0, p9, r31)
 	;;

             reply	other threads:[~2010-09-09 16:56 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-09 16:56 Luck, Tony [this message]
2010-09-09 17:41 ` [PATCH] fix siglock Luck, Tony
2010-09-09 20:10 ` Luck, Tony

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4c8911a2302651c5f3@agluck-desktop.sc.intel.com \
    --to=tony.luck@intel.com \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox