lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 3 Jul 2009 20:00:42 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	mingo@...hat.com, hpa@...or.com, paulus@...ba.org, acme@...hat.com,
	linux-kernel@...r.kernel.org, eric.dumazet@...il.com,
	a.p.zijlstra@...llo.nl, efault@....de, arnd@...db.de,
	fweisbec@...il.com, dhowells@...hat.com, akpm@...ux-foundation.org,
	tglx@...utronix.de, linux-tip-commits@...r.kernel.org
Subject: Re: [tip:perfcounters/urgent] x86: atomic64: Fix unclean type use
	in atomic64_xchg()


* Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Fri, 3 Jul 2009, tip-bot for Ingo Molnar wrote:
> > 
> > Fix atomic64_xchg() to use __atomic64_read() instead.
> 
> Hmm. The whole __atomic64_read() thing should be dropped. Are 
> there any users? None of them should be valid, as Eric's numbers 
> showed. It's apparently better to start out with a random value 
> rather than actually trying to read it.

ah, yes.

We still have this use:

u64 atomic64_xchg(atomic64_t *ptr, u64 new_val)
{
        u64 old_val;

        do {
                old_val = __atomic64_read(ptr);
        } while (atomic64_cmpxchg(ptr, old_val, new_val) != old_val);

        return old_val;
}
EXPORT_SYMBOL(atomic64_xchg);

I'm testing the commit below which improves this loop and also 
removes __atomic64_read().

	Ingo

---------------->
>From 2f4f497dfb708daa52392db98b4bb3d6378be3d3 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@...e.hu>
Date: Fri, 3 Jul 2009 19:56:36 +0200
Subject: [PATCH] x86: atomic64: Improve atomic64_xchg()

Remove the read-first logic from atomic64_xchg() and simplify
the loop.

This function was the last user of __atomic64_read() - remove it.

Also, change the 'real_val' assumption from the somewhat quirky
1ULL << 32 value to the (just as arbitrary, but simpler) value
of 0.

Reported-by: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Eric Dumazet <eric.dumazet@...il.com>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Mike Galbraith <efault@....de>
Cc: Paul Mackerras <paulus@...ba.org>
Cc: Arnaldo Carvalho de Melo <acme@...hat.com>
Cc: Frederic Weisbecker <fweisbec@...il.com>
Cc: David Howells <dhowells@...hat.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Arnd Bergmann <arnd@...db.de>
LKML-Reference: <tip-05118ab8859492ac9ddda0154cf90e37b0a4a0b0@....kernel.org>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
 arch/x86/include/asm/atomic_32.h |    9 ---------
 arch/x86/lib/atomic64_32.c       |   21 +++++++++++++++------
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/atomic_32.h b/arch/x86/include/asm/atomic_32.h
index aa045de..d7c8849 100644
--- a/arch/x86/include/asm/atomic_32.h
+++ b/arch/x86/include/asm/atomic_32.h
@@ -268,15 +268,6 @@ typedef struct {
 
 #define ATOMIC64_INIT(val)	{ (val) }
 
-/**
- * atomic64_read - read atomic64 variable
- * @ptr: pointer of type atomic64_t
- *
- * Atomically reads the value of @v.
- * Doesn't imply a read memory barrier.
- */
-#define __atomic64_read(ptr)		((ptr)->counter)
-
 extern u64 atomic64_cmpxchg(atomic64_t *ptr, u64 old_val, u64 new_val);
 
 /**
diff --git a/arch/x86/lib/atomic64_32.c b/arch/x86/lib/atomic64_32.c
index aab898c..0fac67b 100644
--- a/arch/x86/lib/atomic64_32.c
+++ b/arch/x86/lib/atomic64_32.c
@@ -31,14 +31,23 @@ EXPORT_SYMBOL(atomic64_cmpxchg);
  * Atomically xchgs the value of @ptr to @new_val and returns
  * the old value.
  */
-
 u64 atomic64_xchg(atomic64_t *ptr, u64 new_val)
 {
-	u64 old_val;
+	/*
+	 * Try first with a (possibly incorrect) assumption about
+	 * what we have there. We'll do two loops most likely,
+	 * but we'll get an ownership MESI transaction straight away
+	 * instead of a read transaction followed by a
+	 * flush-for-ownership transaction:
+	 */
+	u64 old_val, real_val = 0;
 
 	do {
-		old_val = __atomic64_read(ptr);
-	} while (atomic64_cmpxchg(ptr, old_val, new_val) != old_val);
+		old_val = real_val;
+
+		real_val = atomic64_cmpxchg(ptr, old_val, new_val);
+
+	} while (real_val != old_val);
 
 	return old_val;
 }
@@ -89,13 +98,13 @@ EXPORT_SYMBOL(atomic64_read);
 noinline u64 atomic64_add_return(u64 delta, atomic64_t *ptr)
 {
 	/*
-	 * Try first with a (probably incorrect) assumption about
+	 * Try first with a (possibly incorrect) assumption about
 	 * what we have there. We'll do two loops most likely,
 	 * but we'll get an ownership MESI transaction straight away
 	 * instead of a read transaction followed by a
 	 * flush-for-ownership transaction:
 	 */
-	u64 old_val, new_val, real_val = 1ULL << 32;
+	u64 old_val, new_val, real_val = 0;
 
 	do {
 		old_val = real_val;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ