From: Sheng Yang <sheng@linux.intel.com>
To: linux-kernel@vger.kernel.org
Cc: linux-mm <linux-mm@kvack.org>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>,
Sheng Yang <sheng@linux.intel.com>
Subject: [PATCH] x86: Extend test_and_set_bit() test_and_clean_bit() to 64 bits in X86_64
Date: Wed, 13 May 2009 16:17:27 +0800 [thread overview]
Message-ID: <1242202647-32446-1-git-send-email-sheng@linux.intel.com> (raw)
This fix 44/45 bit width memory can't boot up issue. The reason is
free_bootmem_node()->mark_bootmem_node()->__free() use test_and_clean_bit() to
clean node_bootmem_map, but for 44bits width address, the idx set bit 31 (43 -
12), which consider as a nagetive value for bts.
This patch applied to tip/mm.
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
arch/x86/include/asm/bitops.h | 24 +++++++++++++++---------
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 02b47a6..400dd28 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -41,6 +41,12 @@
#define CONST_MASK_ADDR(nr, addr) BITOP_ADDR((void *)(addr) + ((nr)>>3))
#define CONST_MASK(nr) (1 << ((nr) & 7))
+#ifdef CONFIG_X86_64
+#define REX_X86 "rex "
+#else
+#define REX_X86
+#endif
+
/**
* set_bit - Atomically set a bit in memory
* @nr: the bit to set
@@ -192,11 +198,11 @@ static inline void change_bit(int nr, volatile unsigned long *addr)
* This operation is atomic and cannot be reordered.
* It also implies a memory barrier.
*/
-static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_set_bit(long int nr, volatile unsigned long *addr)
{
int oldbit;
- asm volatile(LOCK_PREFIX "bts %2,%1\n\t"
+ asm volatile(LOCK_PREFIX REX_X86 "bts %2,%1\n\t"
"sbb %0,%0" : "=r" (oldbit), ADDR : "Ir" (nr) : "memory");
return oldbit;
@@ -224,11 +230,11 @@ test_and_set_bit_lock(int nr, volatile unsigned long *addr)
* If two examples of this operation race, one can appear to succeed
* but actually fail. You must protect multiple accesses with a lock.
*/
-static inline int __test_and_set_bit(int nr, volatile unsigned long *addr)
+static inline int __test_and_set_bit(long int nr, volatile unsigned long *addr)
{
int oldbit;
- asm("bts %2,%1\n\t"
+ asm(REX_X86 "bts %2,%1\n\t"
"sbb %0,%0"
: "=r" (oldbit), ADDR
: "Ir" (nr));
@@ -243,14 +249,13 @@ static inline int __test_and_set_bit(int nr, volatile unsigned long *addr)
* This operation is atomic and cannot be reordered.
* It also implies a memory barrier.
*/
-static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_clear_bit(long int nr, volatile unsigned long *addr)
{
int oldbit;
- asm volatile(LOCK_PREFIX "btr %2,%1\n\t"
+ asm volatile(LOCK_PREFIX REX_X86 "btr %2,%1\n\t"
"sbb %0,%0"
: "=r" (oldbit), ADDR : "Ir" (nr) : "memory");
-
return oldbit;
}
@@ -263,11 +268,12 @@ static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
* If two examples of this operation race, one can appear to succeed
* but actually fail. You must protect multiple accesses with a lock.
*/
-static inline int __test_and_clear_bit(int nr, volatile unsigned long *addr)
+static inline int __test_and_clear_bit(long int nr,
+ volatile unsigned long *addr)
{
int oldbit;
- asm volatile("btr %2,%1\n\t"
+ asm volatile(REX_X86 "btr %2,%1\n\t"
"sbb %0,%0"
: "=r" (oldbit), ADDR
: "Ir" (nr));
--
1.5.4.5
WARNING: multiple messages have this Message-ID (diff)
From: Sheng Yang <sheng@linux.intel.com>
To: linux-kernel@vger.kernel.org
Cc: linux-mm <linux-mm@kvack.org>, Ingo Molnar <mingo@elte.hu>,
"H. Peter Anvin" <hpa@zytor.com>,
Sheng Yang <sheng@linux.intel.com>
Subject: [PATCH] x86: Extend test_and_set_bit() test_and_clean_bit() to 64 bits in X86_64
Date: Wed, 13 May 2009 16:17:27 +0800 [thread overview]
Message-ID: <1242202647-32446-1-git-send-email-sheng@linux.intel.com> (raw)
This fix 44/45 bit width memory can't boot up issue. The reason is
free_bootmem_node()->mark_bootmem_node()->__free() use test_and_clean_bit() to
clean node_bootmem_map, but for 44bits width address, the idx set bit 31 (43 -
12), which consider as a nagetive value for bts.
This patch applied to tip/mm.
Signed-off-by: Sheng Yang <sheng@linux.intel.com>
---
arch/x86/include/asm/bitops.h | 24 +++++++++++++++---------
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index 02b47a6..400dd28 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -41,6 +41,12 @@
#define CONST_MASK_ADDR(nr, addr) BITOP_ADDR((void *)(addr) + ((nr)>>3))
#define CONST_MASK(nr) (1 << ((nr) & 7))
+#ifdef CONFIG_X86_64
+#define REX_X86 "rex "
+#else
+#define REX_X86
+#endif
+
/**
* set_bit - Atomically set a bit in memory
* @nr: the bit to set
@@ -192,11 +198,11 @@ static inline void change_bit(int nr, volatile unsigned long *addr)
* This operation is atomic and cannot be reordered.
* It also implies a memory barrier.
*/
-static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_set_bit(long int nr, volatile unsigned long *addr)
{
int oldbit;
- asm volatile(LOCK_PREFIX "bts %2,%1\n\t"
+ asm volatile(LOCK_PREFIX REX_X86 "bts %2,%1\n\t"
"sbb %0,%0" : "=r" (oldbit), ADDR : "Ir" (nr) : "memory");
return oldbit;
@@ -224,11 +230,11 @@ test_and_set_bit_lock(int nr, volatile unsigned long *addr)
* If two examples of this operation race, one can appear to succeed
* but actually fail. You must protect multiple accesses with a lock.
*/
-static inline int __test_and_set_bit(int nr, volatile unsigned long *addr)
+static inline int __test_and_set_bit(long int nr, volatile unsigned long *addr)
{
int oldbit;
- asm("bts %2,%1\n\t"
+ asm(REX_X86 "bts %2,%1\n\t"
"sbb %0,%0"
: "=r" (oldbit), ADDR
: "Ir" (nr));
@@ -243,14 +249,13 @@ static inline int __test_and_set_bit(int nr, volatile unsigned long *addr)
* This operation is atomic and cannot be reordered.
* It also implies a memory barrier.
*/
-static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
+static inline int test_and_clear_bit(long int nr, volatile unsigned long *addr)
{
int oldbit;
- asm volatile(LOCK_PREFIX "btr %2,%1\n\t"
+ asm volatile(LOCK_PREFIX REX_X86 "btr %2,%1\n\t"
"sbb %0,%0"
: "=r" (oldbit), ADDR : "Ir" (nr) : "memory");
-
return oldbit;
}
@@ -263,11 +268,12 @@ static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
* If two examples of this operation race, one can appear to succeed
* but actually fail. You must protect multiple accesses with a lock.
*/
-static inline int __test_and_clear_bit(int nr, volatile unsigned long *addr)
+static inline int __test_and_clear_bit(long int nr,
+ volatile unsigned long *addr)
{
int oldbit;
- asm volatile("btr %2,%1\n\t"
+ asm volatile(REX_X86 "btr %2,%1\n\t"
"sbb %0,%0"
: "=r" (oldbit), ADDR
: "Ir" (nr));
--
1.5.4.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2009-05-13 8:17 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-13 8:17 Sheng Yang [this message]
2009-05-13 8:17 ` [PATCH] x86: Extend test_and_set_bit() test_and_clean_bit() to 64 bits in X86_64 Sheng Yang
2009-05-13 8:38 ` Andi Kleen
2009-05-13 8:38 ` Andi Kleen
2009-05-14 3:45 ` Sheng Yang
2009-05-14 3:45 ` Sheng Yang
2009-05-14 8:32 ` Andi Kleen
2009-05-14 8:32 ` Andi Kleen
2009-05-14 14:09 ` H. Peter Anvin
2009-05-14 14:09 ` H. Peter Anvin
2009-05-14 14:16 ` Andi Kleen
2009-05-14 14:16 ` Andi Kleen
2009-05-14 14:16 ` H. Peter Anvin
2009-05-14 14:16 ` H. Peter Anvin
2009-05-14 14:27 ` Andi Kleen
2009-05-14 14:27 ` Andi Kleen
2009-05-14 14:25 ` H. Peter Anvin
2009-05-14 14:25 ` H. Peter Anvin
2009-05-14 14:33 ` Andi Kleen
2009-05-14 14:33 ` Andi Kleen
2009-05-14 14:36 ` H. Peter Anvin
2009-05-14 14:36 ` H. Peter Anvin
2009-05-13 16:18 ` H. Peter Anvin
2009-05-13 16:55 ` H. Peter Anvin
2009-05-13 16:55 ` H. Peter Anvin
2009-05-13 17:29 ` H. Peter Anvin
2009-05-14 3:52 ` Sheng Yang
2009-05-14 3:52 ` Sheng Yang
2009-05-14 14:09 ` H. Peter Anvin
2009-05-14 14:09 ` H. Peter Anvin
2009-05-14 13:57 ` Christoph Hellwig
2009-05-14 13:57 ` Christoph Hellwig
2009-05-14 14:29 ` H. Peter Anvin
2009-05-14 14:29 ` H. Peter Anvin
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=1242202647-32446-1-git-send-email-sheng@linux.intel.com \
--to=sheng@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.