[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction
- To: Ingo Molnar <mingo@xxxxxxx>
- From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
- Date: Fri, 20 Jun 2008 13:05:30 -0700
- Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>, kvm-devel <kvm-devel@xxxxxxxxxxxxxxxxxxxxx>, benh@xxxxxxxxxxxxxxxxxxx, x86@xxxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Virtualization Mailing List <virtualization@xxxxxxxxxxxxxx>, Hugh Dickins <hugh@xxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Fri, 20 Jun 2008 13:05:57 -0700
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
Ingo Molnar wrote:
* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
On Fri, 20 Jun 2008, Jeremy Fitzhardinge wrote:
Blows up on "gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)":
Yeah, I was a bit worried about that. Gcc sometimes does insane
things.
We literally just tested that the asm should only _ever_ be generated
with a constant value, but if some gcc dead-code removal thing doesn't
work, it will then screw up and try to generate the asm even for a
non-constant thing.
The fairly trivial fix is probably to just change the "i" to "ir",
safe in the knowledge that any _sane_ case will never use the "r"
possibility. I suspect even your insane case will end up then killing
the bad choice later.
okay - Jeremy, could you try the fix below? (or tip/master, i just
pushed this out)
Hm. On 32-bit I get these, but they're warnings. On 64-bit they're errors.
{standard input}: Assembler messages:
{standard input}:1609: Warning: using `%dl' instead of `%edx' due to `b'
suffix
vs
{standard input}: Assembler messages:
{standard input}:20511: Error: Incorrect register `%eax' used with `b'
suffix
(i dont use gcc 3.x myself to build the kernel, had way too many
miscompilations in randconfig tests in the past.)
I do it mainly to pick up these kinds of problems.
Ingo
-------------->
commit b68b80b8ab39c42707dc126c41e87d46edc97c27
Author: Ingo Molnar <mingo@xxxxxxx>
Date: Fri Jun 20 21:50:20 2008 +0200
x86, bitops: make constant-bit set/clear_bit ops faster, gcc workaround
Jeremy Fitzhardinge reported this compiler bug:
Suggestion from Linus: add "r" to the input constraint of the
set_bit()/clear_bit()'s constant 'nr' branch:
Blows up on "gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)":
CC init/main.o
include2/asm/bitops.h: In function `start_kernel':
include2/asm/bitops.h:59: warning: asm operand 1 probably doesn't match
constraints
include2/asm/bitops.h:59: warning: asm operand 1 probably doesn't match
constraints
include2/asm/bitops.h:59: warning: asm operand 1 probably doesn't match
constraints
include2/asm/bitops.h:59: error: impossible constraint in `asm'
include2/asm/bitops.h:59: error: impossible constraint in `asm'
include2/asm/bitops.h:59: error: impossible constraint in `asm'
Reported-by: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>
diff --git a/include/asm-x86/bitops.h b/include/asm-x86/bitops.h
index 6c50548..4575de4 100644
--- a/include/asm-x86/bitops.h
+++ b/include/asm-x86/bitops.h
@@ -58,7 +58,7 @@ static inline void set_bit(unsigned int nr, volatile unsigned
long *addr)
if (IS_IMMEDIATE(nr)) {
asm volatile(LOCK_PREFIX "orb %1,%0"
: CONST_MASK_ADDR(nr, addr)
- : "i" (CONST_MASK(nr))
+ : "ir" (CONST_MASK(nr))
: "memory");
} else {
asm volatile(LOCK_PREFIX "bts %1,%0"
@@ -95,7 +95,7 @@ static inline void clear_bit(int nr, volatile unsigned long
*addr)
if (IS_IMMEDIATE(nr)) {
asm volatile(LOCK_PREFIX "andb %1,%0"
: CONST_MASK_ADDR(nr, addr)
- : "i" (~CONST_MASK(nr)));
+ : "ir" (~CONST_MASK(nr)));
} else {
asm volatile(LOCK_PREFIX "btr %1,%0"
: BITOP_ADDR(addr)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|