<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/x86/kernel, branch v3.4.23</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>x86, fpu: Avoid FPU lazy restore after suspend</title>
<updated>2012-12-10T18:59:39+00:00</updated>
<author>
<name>Vincent Palatin</name>
<email>vpalatin@chromium.org</email>
</author>
<published>2012-11-30T20:15:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1b9dd61a10bed126661645cbf2623965fbbdefb3'/>
<id>1b9dd61a10bed126661645cbf2623965fbbdefb3</id>
<content type='text'>
commit 644c154186386bb1fa6446bc5e037b9ed098db46 upstream.

When a cpu enters S3 state, the FPU state is lost.
After resuming for S3, if we try to lazy restore the FPU for a process running
on the same CPU, this will result in a corrupted FPU context.

Ensure that "fpu_owner_task" is properly invalided when (re-)initializing a CPU,
so nobody will try to lazy restore a state which doesn't exist in the hardware.

Tested with a 64-bit kernel on a 4-core Ivybridge CPU with eagerfpu=off,
by doing thousands of suspend/resume cycles with 4 processes doing FPU
operations running. Without the patch, a process is killed after a
few hundreds cycles by a SIGFPE.

Signed-off-by: Vincent Palatin &lt;vpalatin@chromium.org&gt;
Cc: Duncan Laurie &lt;dlaurie@chromium.org&gt;
Cc: Olof Johansson &lt;olofj@chromium.org&gt;
Link: http://lkml.kernel.org/r/1354306532-1014-1-git-send-email-vpalatin@chromium.org
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 644c154186386bb1fa6446bc5e037b9ed098db46 upstream.

When a cpu enters S3 state, the FPU state is lost.
After resuming for S3, if we try to lazy restore the FPU for a process running
on the same CPU, this will result in a corrupted FPU context.

Ensure that "fpu_owner_task" is properly invalided when (re-)initializing a CPU,
so nobody will try to lazy restore a state which doesn't exist in the hardware.

Tested with a 64-bit kernel on a 4-core Ivybridge CPU with eagerfpu=off,
by doing thousands of suspend/resume cycles with 4 processes doing FPU
operations running. Without the patch, a process is killed after a
few hundreds cycles by a SIGFPE.

Signed-off-by: Vincent Palatin &lt;vpalatin@chromium.org&gt;
Cc: Duncan Laurie &lt;dlaurie@chromium.org&gt;
Cc: Olof Johansson &lt;olofj@chromium.org&gt;
Link: http://lkml.kernel.org/r/1354306532-1014-1-git-send-email-vpalatin@chromium.org
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86-32: Export kernel_stack_pointer() for modules</title>
<updated>2012-12-06T02:38:34+00:00</updated>
<author>
<name>H. Peter Anvin</name>
<email>hpa@linux.intel.com</email>
</author>
<published>2012-11-21T06:21:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4d064b9c790a24c65e878fe0faba3490e8a7b342'/>
<id>4d064b9c790a24c65e878fe0faba3490e8a7b342</id>
<content type='text'>
commit cb57a2b4cff7edf2a4e32c0163200e9434807e0a upstream.

Modules, in particular oprofile (and possibly other similar tools)
need kernel_stack_pointer(), so export it using EXPORT_SYMBOL_GPL().

Cc: Yang Wei &lt;wei.yang@windriver.com&gt;
Cc: Robert Richter &lt;robert.richter@amd.com&gt;
Cc: Jun Zhang &lt;jun.zhang@intel.com&gt;
Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Robert Richter &lt;rric@kernel.org&gt;
Cc: Herton Ronaldo Krzesinski &lt;herton.krzesinski@canonical.com&gt;
Cc: Philip Müller &lt;philm@manjaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cb57a2b4cff7edf2a4e32c0163200e9434807e0a upstream.

Modules, in particular oprofile (and possibly other similar tools)
need kernel_stack_pointer(), so export it using EXPORT_SYMBOL_GPL().

Cc: Yang Wei &lt;wei.yang@windriver.com&gt;
Cc: Robert Richter &lt;robert.richter@amd.com&gt;
Cc: Jun Zhang &lt;jun.zhang@intel.com&gt;
Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Robert Richter &lt;rric@kernel.org&gt;
Cc: Herton Ronaldo Krzesinski &lt;herton.krzesinski@canonical.com&gt;
Cc: Philip Müller &lt;philm@manjaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86, microcode, AMD: Add support for family 16h processors</title>
<updated>2012-12-03T19:46:38+00:00</updated>
<author>
<name>Boris Ostrovsky</name>
<email>boris.ostrovsky@amd.com</email>
</author>
<published>2012-11-15T18:41:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=82c0abae22f37f93655b8adfa304e207f2ffbfa3'/>
<id>82c0abae22f37f93655b8adfa304e207f2ffbfa3</id>
<content type='text'>
commit 36c46ca4f322a7bf89aad5462a3a1f61713edce7 upstream.

Add valid patch size for family 16h processors.

[ hpa: promoting to urgent/stable since it is hw enabling and trivial ]

Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@amd.com&gt;
Acked-by: Andreas Herrmann &lt;herrmann.der.user@googlemail.com&gt;
Link: http://lkml.kernel.org/r/1353004910-2204-1-git-send-email-boris.ostrovsky@amd.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 36c46ca4f322a7bf89aad5462a3a1f61713edce7 upstream.

Add valid patch size for family 16h processors.

[ hpa: promoting to urgent/stable since it is hw enabling and trivial ]

Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@amd.com&gt;
Acked-by: Andreas Herrmann &lt;herrmann.der.user@googlemail.com&gt;
Link: http://lkml.kernel.org/r/1353004910-2204-1-git-send-email-boris.ostrovsky@amd.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86-32: Fix invalid stack address while in softirq</title>
<updated>2012-12-03T19:46:37+00:00</updated>
<author>
<name>Robert Richter</name>
<email>robert.richter@amd.com</email>
</author>
<published>2012-09-03T18:54:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9d4f96299744ee7b8e2c4ad30ee915f1671e9fba'/>
<id>9d4f96299744ee7b8e2c4ad30ee915f1671e9fba</id>
<content type='text'>
commit 1022623842cb72ee4d0dbf02f6937f38c92c3f41 upstream.

In 32 bit the stack address provided by kernel_stack_pointer() may
point to an invalid range causing NULL pointer access or page faults
while in NMI (see trace below). This happens if called in softirq
context and if the stack is empty. The address at &amp;regs-&gt;sp is then
out of range.

Fixing this by checking if regs and &amp;regs-&gt;sp are in the same stack
context. Otherwise return the previous stack pointer stored in struct
thread_info. If that address is invalid too, return address of regs.

 BUG: unable to handle kernel NULL pointer dereference at 0000000a
 IP: [&lt;c1004237&gt;] print_context_stack+0x6e/0x8d
 *pde = 00000000
 Oops: 0000 [#1] SMP
 Modules linked in:
 Pid: 4434, comm: perl Not tainted 3.6.0-rc3-oprofile-i386-standard-g4411a05 #4 Hewlett-Packard HP xw9400 Workstation/0A1Ch
 EIP: 0060:[&lt;c1004237&gt;] EFLAGS: 00010093 CPU: 0
 EIP is at print_context_stack+0x6e/0x8d
 EAX: ffffe000 EBX: 0000000a ECX: f4435f94 EDX: 0000000a
 ESI: f4435f94 EDI: f4435f94 EBP: f5409ec0 ESP: f5409ea0
  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
 CR0: 8005003b CR2: 0000000a CR3: 34ac9000 CR4: 000007d0
 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
 DR6: ffff0ff0 DR7: 00000400
 Process perl (pid: 4434, ti=f5408000 task=f5637850 task.ti=f4434000)
 Stack:
  000003e8 ffffe000 00001ffc f4e39b00 00000000 0000000a f4435f94 c155198c
  f5409ef0 c1003723 c155198c f5409f04 00000000 f5409edc 00000000 00000000
  f5409ee8 f4435f94 f5409fc4 00000001 f5409f1c c12dce1c 00000000 c155198c
 Call Trace:
  [&lt;c1003723&gt;] dump_trace+0x7b/0xa1
  [&lt;c12dce1c&gt;] x86_backtrace+0x40/0x88
  [&lt;c12db712&gt;] ? oprofile_add_sample+0x56/0x84
  [&lt;c12db731&gt;] oprofile_add_sample+0x75/0x84
  [&lt;c12ddb5b&gt;] op_amd_check_ctrs+0x46/0x260
  [&lt;c12dd40d&gt;] profile_exceptions_notify+0x23/0x4c
  [&lt;c1395034&gt;] nmi_handle+0x31/0x4a
  [&lt;c1029dc5&gt;] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [&lt;c13950ed&gt;] do_nmi+0xa0/0x2ff
  [&lt;c1029dc5&gt;] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [&lt;c13949e5&gt;] nmi_stack_correct+0x28/0x2d
  [&lt;c1029dc5&gt;] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [&lt;c1003603&gt;] ? do_softirq+0x4b/0x7f
  &lt;IRQ&gt;
  [&lt;c102a06f&gt;] irq_exit+0x35/0x5b
  [&lt;c1018f56&gt;] smp_apic_timer_interrupt+0x6c/0x7a
  [&lt;c1394746&gt;] apic_timer_interrupt+0x2a/0x30
 Code: 89 fe eb 08 31 c9 8b 45 0c ff 55 ec 83 c3 04 83 7d 10 00 74 0c 3b 5d 10 73 26 3b 5d e4 73 0c eb 1f 3b 5d f0 76 1a 3b 5d e8 73 15 &lt;8b&gt; 13 89 d0 89 55 e0 e8 ad 42 03 00 85 c0 8b 55 e0 75 a6 eb cc
 EIP: [&lt;c1004237&gt;] print_context_stack+0x6e/0x8d SS:ESP 0068:f5409ea0
 CR2: 000000000000000a
 ---[ end trace 62afee3481b00012 ]---
 Kernel panic - not syncing: Fatal exception in interrupt

V2:
* add comments to kernel_stack_pointer()
* always return a valid stack address by falling back to the address
  of regs

Reported-by: Yang Wei &lt;wei.yang@windriver.com&gt;
Signed-off-by: Robert Richter &lt;robert.richter@amd.com&gt;
Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Jun Zhang &lt;jun.zhang@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1022623842cb72ee4d0dbf02f6937f38c92c3f41 upstream.

In 32 bit the stack address provided by kernel_stack_pointer() may
point to an invalid range causing NULL pointer access or page faults
while in NMI (see trace below). This happens if called in softirq
context and if the stack is empty. The address at &amp;regs-&gt;sp is then
out of range.

Fixing this by checking if regs and &amp;regs-&gt;sp are in the same stack
context. Otherwise return the previous stack pointer stored in struct
thread_info. If that address is invalid too, return address of regs.

 BUG: unable to handle kernel NULL pointer dereference at 0000000a
 IP: [&lt;c1004237&gt;] print_context_stack+0x6e/0x8d
 *pde = 00000000
 Oops: 0000 [#1] SMP
 Modules linked in:
 Pid: 4434, comm: perl Not tainted 3.6.0-rc3-oprofile-i386-standard-g4411a05 #4 Hewlett-Packard HP xw9400 Workstation/0A1Ch
 EIP: 0060:[&lt;c1004237&gt;] EFLAGS: 00010093 CPU: 0
 EIP is at print_context_stack+0x6e/0x8d
 EAX: ffffe000 EBX: 0000000a ECX: f4435f94 EDX: 0000000a
 ESI: f4435f94 EDI: f4435f94 EBP: f5409ec0 ESP: f5409ea0
  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
 CR0: 8005003b CR2: 0000000a CR3: 34ac9000 CR4: 000007d0
 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
 DR6: ffff0ff0 DR7: 00000400
 Process perl (pid: 4434, ti=f5408000 task=f5637850 task.ti=f4434000)
 Stack:
  000003e8 ffffe000 00001ffc f4e39b00 00000000 0000000a f4435f94 c155198c
  f5409ef0 c1003723 c155198c f5409f04 00000000 f5409edc 00000000 00000000
  f5409ee8 f4435f94 f5409fc4 00000001 f5409f1c c12dce1c 00000000 c155198c
 Call Trace:
  [&lt;c1003723&gt;] dump_trace+0x7b/0xa1
  [&lt;c12dce1c&gt;] x86_backtrace+0x40/0x88
  [&lt;c12db712&gt;] ? oprofile_add_sample+0x56/0x84
  [&lt;c12db731&gt;] oprofile_add_sample+0x75/0x84
  [&lt;c12ddb5b&gt;] op_amd_check_ctrs+0x46/0x260
  [&lt;c12dd40d&gt;] profile_exceptions_notify+0x23/0x4c
  [&lt;c1395034&gt;] nmi_handle+0x31/0x4a
  [&lt;c1029dc5&gt;] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [&lt;c13950ed&gt;] do_nmi+0xa0/0x2ff
  [&lt;c1029dc5&gt;] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [&lt;c13949e5&gt;] nmi_stack_correct+0x28/0x2d
  [&lt;c1029dc5&gt;] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [&lt;c1003603&gt;] ? do_softirq+0x4b/0x7f
  &lt;IRQ&gt;
  [&lt;c102a06f&gt;] irq_exit+0x35/0x5b
  [&lt;c1018f56&gt;] smp_apic_timer_interrupt+0x6c/0x7a
  [&lt;c1394746&gt;] apic_timer_interrupt+0x2a/0x30
 Code: 89 fe eb 08 31 c9 8b 45 0c ff 55 ec 83 c3 04 83 7d 10 00 74 0c 3b 5d 10 73 26 3b 5d e4 73 0c eb 1f 3b 5d f0 76 1a 3b 5d e8 73 15 &lt;8b&gt; 13 89 d0 89 55 e0 e8 ad 42 03 00 85 c0 8b 55 e0 75 a6 eb cc
 EIP: [&lt;c1004237&gt;] print_context_stack+0x6e/0x8d SS:ESP 0068:f5409ea0
 CR2: 000000000000000a
 ---[ end trace 62afee3481b00012 ]---
 Kernel panic - not syncing: Fatal exception in interrupt

V2:
* add comments to kernel_stack_pointer()
* always return a valid stack address by falling back to the address
  of regs

Reported-by: Yang Wei &lt;wei.yang@windriver.com&gt;
Signed-off-by: Robert Richter &lt;robert.richter@amd.com&gt;
Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Jun Zhang &lt;jun.zhang@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86, mm: Use memblock memory loop instead of e820_RAM</title>
<updated>2012-10-31T17:03:19+00:00</updated>
<author>
<name>Yinghai Lu</name>
<email>yinghai@kernel.org</email>
</author>
<published>2012-10-22T23:35:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0187c24809c9590412c0112dab88f28621a961ed'/>
<id>0187c24809c9590412c0112dab88f28621a961ed</id>
<content type='text'>
commit 1f2ff682ac951ed82cc043cf140d2851084512df upstream.

We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time.

Also memblock has page aligned range for ram, so we could avoid mapping
partial pages.

Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin &lt;jacob.shin@amd.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1f2ff682ac951ed82cc043cf140d2851084512df upstream.

We need to handle E820_RAM and E820_RESERVED_KERNEL at the same time.

Also memblock has page aligned range for ram, so we could avoid mapping
partial pages.

Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin &lt;jacob.shin@amd.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86: efi: Turn off efi_enabled after setup on mixed fw/kernel</title>
<updated>2012-10-31T17:03:19+00:00</updated>
<author>
<name>Olof Johansson</name>
<email>olof@lixom.net</email>
</author>
<published>2012-10-24T17:00:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=775dc1a3fd51abc6e459aa92e049fd3687b66c2f'/>
<id>775dc1a3fd51abc6e459aa92e049fd3687b66c2f</id>
<content type='text'>
commit 5189c2a7c7769ee9d037d76c1a7b8550ccf3481c upstream.

When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off
efi_enabled once setup is done. Beyond setup, it is normally used to
determine if runtime services are available and we will have none.

This will resolve issues stemming from efivars modprobe panicking on a
32/64-bit setup, as well as some reboot issues on similar setups.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45991

Reported-by: Marko Kohtala &lt;marko.kohtala@gmail.com&gt;
Reported-by: Maxim Kammerer &lt;mk@dee.su&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Acked-by: Maarten Lankhorst &lt;maarten.lankhorst@canonical.com&gt;
Cc: Matthew Garrett &lt;mjg@redhat.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5189c2a7c7769ee9d037d76c1a7b8550ccf3481c upstream.

When 32-bit EFI is used with 64-bit kernel (or vice versa), turn off
efi_enabled once setup is done. Beyond setup, it is normally used to
determine if runtime services are available and we will have none.

This will resolve issues stemming from efivars modprobe panicking on a
32/64-bit setup, as well as some reboot issues on similar setups.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45991

Reported-by: Marko Kohtala &lt;marko.kohtala@gmail.com&gt;
Reported-by: Maxim Kammerer &lt;mk@dee.su&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Acked-by: Maarten Lankhorst &lt;maarten.lankhorst@canonical.com&gt;
Cc: Matthew Garrett &lt;mjg@redhat.com&gt;
Signed-off-by: Matt Fleming &lt;matt.fleming@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86, mm: Trim memory in memblock to be page aligned</title>
<updated>2012-10-31T17:02:56+00:00</updated>
<author>
<name>Yinghai Lu</name>
<email>yinghai@kernel.org</email>
</author>
<published>2012-10-22T23:35:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=368845fde9e704288f370df57988767aab6042b4'/>
<id>368845fde9e704288f370df57988767aab6042b4</id>
<content type='text'>
commit 6ede1fd3cb404c0016de6ac529df46d561bd558b upstream.

We will not map partial pages, so need to make sure memblock
allocation will not allocate those bytes out.

Also we will use for_each_mem_pfn_range() to loop to map memory
range to keep them consistent.

Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin &lt;jacob.shin@amd.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6ede1fd3cb404c0016de6ac529df46d561bd558b upstream.

We will not map partial pages, so need to make sure memblock
allocation will not allocate those bytes out.

Also we will use for_each_mem_pfn_range() to loop to map memory
range to keep them consistent.

Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Link: http://lkml.kernel.org/r/CAE9FiQVZirvaBMFYRfXMmWEcHbKSicQEHz4VAwUv0xFCk51ZNw@mail.gmail.com
Acked-by: Jacob Shin &lt;jacob.shin@amd.com&gt;
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/x86: don't corrupt %eip when returning from a signal handler</title>
<updated>2012-10-28T17:14:13+00:00</updated>
<author>
<name>David Vrabel</name>
<email>david.vrabel@citrix.com</email>
</author>
<published>2012-10-19T16:29:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cf32a3a3e7b9a449e3b51bc8114d623d52fa9c5f'/>
<id>cf32a3a3e7b9a449e3b51bc8114d623d52fa9c5f</id>
<content type='text'>
commit a349e23d1cf746f8bdc603dcc61fae9ee4a695f6 upstream.

In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
/and/ the process has a pending signal then %eip (and %eax) are
corrupted when returning to the main process after handling the
signal.  The application may then crash with SIGSEGV or a SIGILL or it
may have subtly incorrect behaviour (depending on what instruction it
returned to).

The occurs because handle_signal() is incorrectly thinking that there
is a system call that needs to restarted so it adjusts %eip and %eax
to re-execute the system call instruction (even though user space had
not done a system call).

If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
(-516) then handle_signal() only corrupted %eax (by setting it to
-EINTR).  This may cause the application to crash or have incorrect
behaviour.

handle_signal() assumes that regs-&gt;orig_ax &gt;= 0 means a system call so
any kernel entry point that is not for a system call must push a
negative value for orig_ax.  For example, for physical interrupts on
bare metal the inverse of the vector is pushed and page_fault() sets
regs-&gt;orig_ax to -1, overwriting the hardware provided error code.

xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
instead of -1.

Classic Xen kernels pushed %eax which works as %eax cannot be both
non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
other non-system call entry points and avoids some of the tests in
handle_signal().

There were similar bugs in xen_failsafe_callback() of both 32 and
64-bit guests. If the fault was corrected and the normal return path
was used then 0 was incorrectly pushed as the value for orig_ax.

Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Acked-by: Jan Beulich &lt;JBeulich@suse.com&gt;
Acked-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a349e23d1cf746f8bdc603dcc61fae9ee4a695f6 upstream.

In 32 bit guests, if a userspace process has %eax == -ERESTARTSYS
(-512) or -ERESTARTNOINTR (-513) when it is interrupted by an event
/and/ the process has a pending signal then %eip (and %eax) are
corrupted when returning to the main process after handling the
signal.  The application may then crash with SIGSEGV or a SIGILL or it
may have subtly incorrect behaviour (depending on what instruction it
returned to).

The occurs because handle_signal() is incorrectly thinking that there
is a system call that needs to restarted so it adjusts %eip and %eax
to re-execute the system call instruction (even though user space had
not done a system call).

If %eax == -514 (-ERESTARTNOHAND (-514) or -ERESTART_RESTARTBLOCK
(-516) then handle_signal() only corrupted %eax (by setting it to
-EINTR).  This may cause the application to crash or have incorrect
behaviour.

handle_signal() assumes that regs-&gt;orig_ax &gt;= 0 means a system call so
any kernel entry point that is not for a system call must push a
negative value for orig_ax.  For example, for physical interrupts on
bare metal the inverse of the vector is pushed and page_fault() sets
regs-&gt;orig_ax to -1, overwriting the hardware provided error code.

xen_hypervisor_callback() was incorrectly pushing 0 for orig_ax
instead of -1.

Classic Xen kernels pushed %eax which works as %eax cannot be both
non-negative and -RESTARTSYS (etc.), but using -1 is consistent with
other non-system call entry points and avoids some of the tests in
handle_signal().

There were similar bugs in xen_failsafe_callback() of both 32 and
64-bit guests. If the fault was corrected and the normal return path
was used then 0 was incorrectly pushed as the value for orig_ax.

Signed-off-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Acked-by: Jan Beulich &lt;JBeulich@suse.com&gt;
Acked-by: Ian Campbell &lt;ian.campbell@citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping.</title>
<updated>2012-10-28T17:14:13+00:00</updated>
<author>
<name>Jacob Shin</name>
<email>jacob.shin@amd.com</email>
</author>
<published>2011-10-20T21:15:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=efd5fa0c1a1d1b46846ea6e8d1a783d0d8a6a721'/>
<id>efd5fa0c1a1d1b46846ea6e8d1a783d0d8a6a721</id>
<content type='text'>
commit 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a upstream.

On systems with very large memory (1 TB in our case), BIOS may report a
reserved region or a hole in the E820 map, even above the 4 GB range. Exclude
these from the direct mapping.

[ hpa: this should be done not just for &gt; 4 GB but for everything above the legacy
  region (1 MB), at the very least.  That, however, turns out to require significant
  restructuring.  That work is well underway, but is not suitable for rc/stable. ]

Signed-off-by: Jacob Shin &lt;jacob.shin@amd.com&gt;
Link: http://lkml.kernel.org/r/1319145326-13902-1-git-send-email-jacob.shin@amd.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a upstream.

On systems with very large memory (1 TB in our case), BIOS may report a
reserved region or a hole in the E820 map, even above the 4 GB range. Exclude
these from the direct mapping.

[ hpa: this should be done not just for &gt; 4 GB but for everything above the legacy
  region (1 MB), at the very least.  That, however, turns out to require significant
  restructuring.  That work is well underway, but is not suitable for rc/stable. ]

Signed-off-by: Jacob Shin &lt;jacob.shin@amd.com&gt;
Link: http://lkml.kernel.org/r/1319145326-13902-1-git-send-email-jacob.shin@amd.com
Signed-off-by: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>x86/alternatives: Fix p6 nops on non-modular kernels</title>
<updated>2012-10-07T15:32:29+00:00</updated>
<author>
<name>Avi Kivity</name>
<email>avi@redhat.com</email>
</author>
<published>2012-08-22T10:03:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4a3bb116ee8ab2f912fdb6d2af40028b15825151'/>
<id>4a3bb116ee8ab2f912fdb6d2af40028b15825151</id>
<content type='text'>
commit cb09cad44f07044d9810f18f6f9a6a6f3771f979 upstream.

Probably a leftover from the early days of self-patching, p6nops
are marked __initconst_or_module, which causes them to be
discarded in a non-modular kernel.  If something later triggers
patching, it will overwrite kernel code with garbage.

Reported-by: Tomas Racek &lt;tracek@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
Cc: Michael Tokarev &lt;mjt@tls.msk.ru&gt;
Cc: Borislav Petkov &lt;borislav.petkov@amd.com&gt;
Cc: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Cc: qemu-devel@nongnu.org
Cc: Anthony Liguori &lt;anthony@codemonkey.ws&gt;
Cc: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Alan Cox &lt;alan@lxorguk.ukuu.org.uk&gt;
Cc: Alan Cox &lt;alan@linux.intel.com&gt;
Link: http://lkml.kernel.org/r/5034AE84.90708@redhat.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Ben Jencks &lt;ben@bjencks.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit cb09cad44f07044d9810f18f6f9a6a6f3771f979 upstream.

Probably a leftover from the early days of self-patching, p6nops
are marked __initconst_or_module, which causes them to be
discarded in a non-modular kernel.  If something later triggers
patching, it will overwrite kernel code with garbage.

Reported-by: Tomas Racek &lt;tracek@redhat.com&gt;
Signed-off-by: Avi Kivity &lt;avi@redhat.com&gt;
Cc: Michael Tokarev &lt;mjt@tls.msk.ru&gt;
Cc: Borislav Petkov &lt;borislav.petkov@amd.com&gt;
Cc: Marcelo Tosatti &lt;mtosatti@redhat.com&gt;
Cc: qemu-devel@nongnu.org
Cc: Anthony Liguori &lt;anthony@codemonkey.ws&gt;
Cc: H. Peter Anvin &lt;hpa@linux.intel.com&gt;
Cc: Alan Cox &lt;alan@lxorguk.ukuu.org.uk&gt;
Cc: Alan Cox &lt;alan@linux.intel.com&gt;
Link: http://lkml.kernel.org/r/5034AE84.90708@redhat.com
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Ben Jencks &lt;ben@bjencks.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
