linux-stable.git/include/asm-x86, branch linux-2.6.25.y

x86: fix spin_is_contended()

2008-08-20T18:15:47+00:00

commit 7bc069c6bc4ede519a7116be1b9e149a1dbf787a upstream

The masked difference is what needs to be compared against 1, rather
than the difference of masked values (which can be negative).

Signed-off-by: Jan Beulich 
Acked-by: Nick Piggin 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: fix ldt limit for 64 bit

2008-07-13T17:54:09+00:00

commit 5ac37f87ff18843aabab84cf75b2f8504c2d81fe upstream

Fix size of LDT entries. On x86-64, ldt_desc is a double-sized descriptor.

Signed-off-by: Michael Karcher 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: shift bits the right way in native_read_tscp

2008-07-03T03:46:16+00:00

Commit 41aefdcc98fdba47459eab67630293d67e855fc3 upstream

x86: shift bits the right way in native_read_tscp

native_read_tscp shifts the bits in the high order value in the
wrong direction, the attached patch fixes that.

Signed-off-by: Max Asbock 
Acked-by: Glauber Costa 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: set PAE PHYSICAL_MASK_SHIFT to 44 bits.

2008-06-24T21:08:30+00:00

commit ad524d46f36bbc32033bb72ba42958f12bf49b06 upstream

When a 64-bit x86 processor runs in 32-bit PAE mode, a pte can
potentially have the same number of physical address bits as the
64-bit host ("Enhanced Legacy PAE Paging").  This means, in theory,
we could have up to 52 bits of physical address in a pte.

The 32-bit kernel uses a 32-bit unsigned long to represent a pfn.
This means that it can only represent physical addresses up to 32+12=44
bits wide.  Rather than widening pfns everywhere, just set 2^44 as the
Linux x86_32-PAE architectural limit for physical address size.

This is a bugfix for two cases:
1. running a 32-bit PAE kernel on a machine with
  more than 64GB RAM.
2. running a 32-bit PAE Xen guest on a host machine with
  more than 64GB RAM

In both cases, a pte could need to have more than 36 bits of physical,
and masking it to 36-bits will cause fairly severe havoc.

Signed-off-by: Jeremy Fitzhardinge 
Cc: Jan Beulich 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: prevent PGE flush from interruption/preemption

2008-06-09T18:27:03+00:00

upstream commit: b1979a5fda7869a790f4fd83fb06c78498d26ba1

CR4 manipulation is not protected against interrupts and preemption,
but KVM uses smp_function_call to manipulate the X86_CR4_VMXE bit
either from the CPU hotplug code or from the kvm_init call.

We need to protect the CR4 manipulation from both interrupts and
preemption.

Original bug report: http://lkml.org/lkml/2008/5/7/48
Bugzilla entry: http://bugzilla.kernel.org/show_bug.cgi?id=10642

This is not a regression from 2.6.25, it's a long standing and hard to
trigger bug.

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Chris Wright

x86: sysfs cpu?/topology is empty in 2.6.25 (32-bit Intel system)

2008-05-15T14:50:05+00:00

commit 5c3a121d52b30a1e53cdaa802fa1965fcd243164 upstream

System topology on intel based system needs to be exported
for non-numa case as well.

All parts of asm-i386/topology.h has come under
#ifdef CONFIG_NUMA after the merge to asm-x86/topology.h

/sys/devices/system/cpu/cpu?/topology/* is populated based on
ENABLE_TOPO_DEFINES

The sysfs cpu topology is not being populated on my dual socket
dual core xeon 5160 processor based (x86 32 bit) system.

CONFIG_NUMA is not set in my case yet the topology is relevant
and useful.

irqbalance daemon application depends on topology to build the
cpus and package list and it fails on Fedora9 beta since the
sysfs topology was not being populated in the 2.6.25 kernel.

I am not sure if it was intentional to not define ENABLE_TOPO_DEFINES
for non-numa systems.

This fix has been tested on the above mentioned dual core, dual socket
system.

Signed-off-by: Vaidyanathan Srinivasan 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

Add commentary about the new "asmlinkage_protect()" macro

2008-04-11T00:35:23+00:00

It's really a pretty ugly thing to need, and some day it will hopefully
be obviated by teaching gcc about the magic calling conventions for the
low-level system call code, but in the meantime we can at least add big
honking comments about why we need these insane and strange macros.

I took my comments from my version of the macro, but I ended up deciding
to just pick Roland's version of the actual code instead (with his
prettier syntax that uses vararg macros).  Thus the previous two commits
that actually implement it.

Signed-off-by: Linus Torvalds

asmlinkage_protect replaces prevent_tail_call

2008-04-11T00:28:26+00:00

The prevent_tail_call() macro works around the problem of the compiler
clobbering argument words on the stack, which for asmlinkage functions
is the caller's (user's) struct pt_regs.  The tail/sibling-call
optimization is not the only way that the compiler can decide to use
stack argument words as scratch space, which we have to prevent.
Other optimizations can do it too.

Until we have new compiler support to make "asmlinkage" binding on the
compiler's own use of the stack argument frame, we have work around all
the manifestations of this issue that crop up.

More cases seem to be prevented by also keeping the incoming argument
variables live at the end of the function.  This makes their original
stack slots attractive places to leave those variables, so the compiler
tends not clobber them for something else.  It's still no guarantee, but
it handles some observed cases that prevent_tail_call() did not.

Signed-off-by: Roland McGrath 
Signed-off-by: Linus Torvalds

x86: fix 64-bit asm NOPS for CONFIG_GENERIC_CPU

2008-04-07T19:09:14+00:00

ASM_NOP's for 64-bit kernel with CONFIG_GENERIC_CPU is broken
with the recent x86 nops merge. They were using GENERIC_NOPS
which will truncate the upper 32bits of %rsi, because of the missing
64bit rex prefix.

For now, fall back ASM NOPS for generic cpu to K8 NOPS, similar
to the code before the wrong x86 nop merge.

This should resolve the crash seen by Ingo on a test-system:

BUG: unable to handle kernel paging request at 00000000d80d8ee8
IP: [] save_i387_ia32+0x61/0xd8
PGD b8e0067 PUD 51490067 PMD 0
Oops: 0000 [1] SMP
CPU 2
Modules linked in:
Pid: 3871, comm: distcc Not tainted 2.6.25-rc7-sched-devel.git-x86-latest.git #359
RIP: 0010:[]  [] save_i387_ia32+0x61/0xd8
RSP: 0000:ffff81003abd3cb8  EFLAGS: 00010246
RAX: ffff810082e93400 RBX: 00000000ffc37f84 RCX: ffff8100d80d8ee0
RDX: 0000000000000000 RSI: 00000000d80d8ee0 RDI: ffff810082e93400
RBP: 00000000ffc37fdc R08: 00000000ffc37f88 R09: 0000000000000008
R10: ffff81003abd2000 R11: 0000000000000000 R12: ffff810082e93400
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff81011fb12dc0(0063) knlGS:00000000f7f1a6c0
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000d80d8ee8 CR3: 0000000076922000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process distcc (pid: 3871, threadinfo ffff81003abd2000, task ffff8100d80d8ee0)
Stack:  ffff8100bb670380 ffffffff8026de50 0000000000000118 0000000000000002
 0000000000000002 ffff81003abd3e68 ffff81003abd3ed8 ffff81003abd3de8
 ffff81003abd3d18 ffffffff80229785 ffff8100d80d8ee0 ffff810001041280
Call Trace:
 [] ? __generic_file_aio_write_nolock+0x343/0x377
 [] ? update_curr+0x54/0x64
 [] ? ia32_setup_sigcontext+0x125/0x1d2
 [] ? ia32_setup_frame+0x73/0x1a5
 [] ? do_notify_resume+0x1aa/0x7db
 [] ? getnstimeofday+0x31/0x85
 [] ? ktime_get_ts+0x17/0x48
 [] ? ktime_get+0xc/0x41
 [] ? hrtimer_nanosleep+0x75/0xd5
 [] ? hrtimer_wakeup+0x0/0x21
 [] ? int_signal+0x12/0x17
 [] ? dummy_file_free_security+0x0/0x1

Code: a6 08 05 00 00 f6 40 14 01 74 34 4c 89 e7 48 0f ae 07 48 8b 86 08 05 00 00 80 78 02 00 79 02 db e2 90 8d b4 26 00 00 00 00 89 f6 <48> 8b 46 08 83 60 14 fe 0f 20 c0 48 83 c8 08 0f 22 c0 eb 07 c6 

Signed-off-by: Suresh Siddha 
Signed-off-by: Ingo Molnar

x86: fix breakage of vSMP irq operations

2008-04-04T16:36:46+00:00

25-rc* stopped working with CONFIG_X86_VSMP on vSMP machines.

Looks like the vsmp irq ops got accidentally removed during merge of x86_64
pvops in 2.6.25. -- commit 6abcd98ffafbff81f0bfd7ee1d129e634af13245 removed
vsmp irq ops.

Tested with both CONFIG_X86_VSMP and without CONFIG_X86_VSMP, on vSMP and non
vSMP x86_64 machines.

Please apply.

Signed-off-by: Ravikiran Thirumalai 
Signed-off-by: Ingo Molnar