linux-toradex.git/arch/x86, branch v4.1.5

perf/x86/intel/cqm: Return cached counter value from IRQ context

2015-08-10T19:21:58+00:00

commit 2c534c0da0a68418693e10ce1c4146e085f39518 upstream.

Peter reported the following potential crash which I was able to
reproduce with his test program,

[  148.765788] ------------[ cut here ]------------
[  148.765796] WARNING: CPU: 34 PID: 2840 at kernel/smp.c:417 smp_call_function_many+0xb6/0x260()
[  148.765797] Modules linked in:
[  148.765800] CPU: 34 PID: 2840 Comm: perf Not tainted 4.2.0-rc1+ #4
[  148.765803]  ffffffff81cdc398 ffff88085f105950 ffffffff818bdfd5 0000000000000007
[  148.765805]  0000000000000000 ffff88085f105990 ffffffff810e413a 0000000000000000
[  148.765807]  ffffffff82301080 0000000000000022 ffffffff8107f640 ffffffff8107f640
[  148.765809] Call Trace:
[  148.765810]    [] dump_stack+0x45/0x57
[  148.765818]  [] warn_slowpath_common+0x8a/0xc0
[  148.765822]  [] ? intel_cqm_stable+0x60/0x60
[  148.765824]  [] ? intel_cqm_stable+0x60/0x60
[  148.765825]  [] warn_slowpath_null+0x1a/0x20
[  148.765827]  [] smp_call_function_many+0xb6/0x260
[  148.765829]  [] ? intel_cqm_stable+0x60/0x60
[  148.765831]  [] on_each_cpu_mask+0x28/0x60
[  148.765832]  [] intel_cqm_event_count+0x7f/0xe0
[  148.765836]  [] perf_output_read+0x2a5/0x400
[  148.765839]  [] perf_output_sample+0x31a/0x590
[  148.765840]  [] ? perf_prepare_sample+0x26d/0x380
[  148.765841]  [] perf_event_output+0x47/0x60
[  148.765843]  [] __perf_event_overflow+0x215/0x240
[  148.765844]  [] perf_event_overflow+0x14/0x20
[  148.765847]  [] intel_pmu_handle_irq+0x1d4/0x440
[  148.765849]  [] ? __perf_event_task_sched_in+0x36/0xa0
[  148.765853]  [] ? vunmap_page_range+0x19d/0x2f0
[  148.765854]  [] ? unmap_kernel_range_noflush+0x11/0x20
[  148.765859]  [] ? ghes_copy_tofrom_phys+0x11e/0x2a0
[  148.765863]  [] ? native_apic_msr_write+0x2b/0x30
[  148.765865]  [] ? x2apic_send_IPI_self+0x1d/0x20
[  148.765869]  [] ? arch_irq_work_raise+0x35/0x40
[  148.765872]  [] ? irq_work_queue+0x66/0x80
[  148.765875]  [] perf_event_nmi_handler+0x26/0x40
[  148.765877]  [] nmi_handle+0x79/0x100
[  148.765879]  [] default_do_nmi+0x42/0x100
[  148.765880]  [] do_nmi+0x83/0xb0
[  148.765884]  [] end_repeat_nmi+0x1e/0x2e
[  148.765886]  [] ? __perf_event_task_sched_in+0x36/0xa0
[  148.765888]  [] ? __perf_event_task_sched_in+0x36/0xa0
[  148.765890]  [] ? __perf_event_task_sched_in+0x36/0xa0
[  148.765891]  <>  [] finish_task_switch+0x156/0x210
[  148.765898]  [] __schedule+0x341/0x920
[  148.765899]  [] schedule+0x37/0x80
[  148.765903]  [] ? do_page_fault+0x2f/0x80
[  148.765905]  [] schedule_user+0x1a/0x50
[  148.765907]  [] retint_careful+0x14/0x32
[  148.765908] ---[ end trace e33ff2be78e14901 ]---

The CQM task events are not safe to be called from within interrupt
context because they require performing an IPI to read the counter value
on all sockets. And performing IPIs from within IRQ context is a
"no-no".

Make do with the last read counter value currently event in
event->count when we're invoked in this context.

Reported-by: Peter Zijlstra 
Signed-off-by: Matt Fleming 
Cc: Thomas Gleixner 
Cc: Vikas Shivappa 
Cc: Kanaka Juvva 
Cc: Will Auld 
Link: http://lkml.kernel.org/r/1437490509-15373-1-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

x86/efi: Use all 64 bit of efi_memmap in setup_e820()

2015-08-10T19:21:57+00:00

commit 7cc03e48965453b5df1cce5062c826189b04b960 upstream.

The efi_info structure stores low 32 bits of memory map
in efi_memmap and high 32 bits in efi_memmap_hi.

While constructing pointer in the setup_e820(), need
to take into account all 64 bit of the pointer.

It is because on 64bit machine the function
efi_get_memory_map() may return full 64bit pointer and before
the patch that pointer was truncated.

The issue is triggered on Parallles virtual machine and
fixed with this patch.

Signed-off-by: Dmitry Skorodumov 
Cc: Denis V. Lunev 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

efi: Check for NULL efi kernel parameters

2015-08-10T19:21:57+00:00

commit 9115c7589b11349a1c3099758b4bded579ff69e0 upstream.

Even though it is documented how to specifiy efi parameters, it is
possible to cause a kernel panic due to a dereference of a NULL pointer when
parsing such parameters if "efi" alone is given:

PANIC: early exception 0e rip 10:ffffffff812fb361 error 0 cr2 0
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0-rc1+ #450
[ 0.000000]  ffffffff81fe20a9 ffffffff81e03d50 ffffffff8184bb0f 00000000000003f8
[ 0.000000]  0000000000000000 ffffffff81e03e08 ffffffff81f371a1 64656c62616e6520
[ 0.000000]  0000000000000069 000000000000005f 0000000000000000 0000000000000000
[ 0.000000] Call Trace:
[ 0.000000]  [] dump_stack+0x45/0x57
[ 0.000000]  [] early_idt_handler_common+0x81/0xae
[ 0.000000]  [] ? parse_option_str+0x11/0x90
[ 0.000000]  [] arch_parse_efi_cmdline+0x15/0x42
[ 0.000000]  [] do_early_param+0x50/0x8a
[ 0.000000]  [] parse_args+0x1e3/0x400
[ 0.000000]  [] parse_early_options+0x24/0x28
[ 0.000000]  [] ? loglevel+0x31/0x31
[ 0.000000]  [] parse_early_param+0x31/0x3d
[ 0.000000]  [] setup_arch+0x2de/0xc08
[ 0.000000]  [] ? vprintk_default+0x1a/0x20
[ 0.000000]  [] start_kernel+0x90/0x423
[ 0.000000]  [] x86_64_start_reservations+0x2a/0x2c
[ 0.000000]  [] x86_64_start_kernel+0xeb/0xef
[ 0.000000] RIP 0xffffffff81ba2efc

This panic is not reproducible with "efi=" as this will result in a non-NULL
zero-length string.

Thus, verify that the pointer to the parameter string is not NULL. This is
consistent with other parameter-parsing functions which check for NULL pointers.

Signed-off-by: Ricardo Neri 
Cc: Dave Young 
Signed-off-by: Matt Fleming 
Signed-off-by: Greg Kroah-Hartman

x86/mm: Add parenthesis for TLB tracepoint size calculation

2015-08-10T19:21:57+00:00

commit bbc03778b9954a2ec93baed63718e4df0192f130 upstream.

flush_tlb_info->flush_start/end are both normal virtual
addresses.  When calculating 'nr_pages' (only used for the
tracepoint), I neglected to put parenthesis in.

Thanks to David Koufaty for pointing this out.

Signed-off-by: Dave Hansen 
Cc: Andrew Morton 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: dave@sr71.net
Link: http://lkml.kernel.org/r/20150720230153.9E834081@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86, perf: Fix static_key bug in load_mm_cr4()

2015-08-10T19:21:54+00:00

commit a833581e372a4adae2319d8dc379493edbc444e9 upstream.

Mikulas reported his K6-3 not booting. This is because the
static_key API confusion struck and bit Andy, this wants to be
static_key_false().

Reported-by: Mikulas Patocka 
Tested-by: Mikulas Patocka 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Andrea Arcangeli 
Cc: Andy Lutomirski 
Cc: Arnaldo Carvalho de Melo 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Paul Mackerras 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Valdis Kletnieks 
Cc: Vince Weaver 
Cc: hillf.zj 
Fixes: a66734297f78 ("perf/x86: Add /sys/devices/cpu/rdpmc=2 to allow rdpmc for all tasks")
Link: http://lkml.kernel.org/r/20150709172338.GC19282@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/kasan: Fix boot crash on AMD processors

2015-08-10T19:21:52+00:00

commit d4f86beacc21d538dc41e1fc75a22e084f547edf upstream.

While populating zero shadow wrong bits in upper level page
tables used. __PAGE_KERNEL_RO that was used for pgd/pud/pmd has
_PAGE_BIT_GLOBAL set. Global bit is present only in the lowest
level of the page translation hierarchy (ptes), and it should be
zero in upper levels.

This bug seems doesn't cause any troubles on Intel cpus, while
on AMDs it cause kernel crash on boot.

Use _KERNPG_TABLE bits for pgds/puds/pmds to fix this.

Reported-by: Borislav Petkov 
Signed-off-by: Andrey Ryabinin 
Cc: Alexander Popov 
Cc: Alexander Potapenko 
Cc: Andrey Konovalov 
Cc: Dmitry Vyukov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1435828178-10975-5-git-send-email-a.ryabinin@samsung.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/kasan: Flush TLBs after switching CR3

2015-08-10T19:21:52+00:00

commit 241d2c54c62fa0939fc9a9512b48ac3434e90a89 upstream.

load_cr3() doesn't cause tlb_flush if PGE enabled.

This may cause tons of false positive reports spamming the
kernel to death.

To fix this __flush_tlb_all() should be called explicitly
after CR3 changed.

Signed-off-by: Andrey Ryabinin 
Cc: Alexander Popov 
Cc: Alexander Potapenko 
Cc: Andrey Konovalov 
Cc: Borislav Petkov 
Cc: Dmitry Vyukov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1435828178-10975-4-git-send-email-a.ryabinin@samsung.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/kasan: Fix KASAN shadow region page tables

2015-08-10T19:21:52+00:00

commit 5d5aa3cfca5cf74cd928daf3674642e6004328d1 upstream.

Currently KASAN shadow region page tables created without
respect of physical offset (phys_base). This causes kernel halt
when phys_base is not zero.

So let's initialize KASAN shadow region page tables in
kasan_early_init() using __pa_nodebug() which considers
phys_base.

This patch also separates x86_64_start_kernel() from KASAN low
level details by moving kasan_map_early_shadow(init_level4_pgt)
into kasan_early_init().

Remove the comment before clear_bss() which stopped bringing
much profit to the code readability. Otherwise describing all
the new order dependencies would be too verbose.

Signed-off-by: Alexander Popov 
Signed-off-by: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Andrey Konovalov 
Cc: Borislav Petkov 
Cc: Dmitry Vyukov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1435828178-10975-3-git-send-email-a.ryabinin@samsung.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/init: Clear 'init_level4_pgt' earlier

2015-08-10T19:21:52+00:00

commit d0f77d4d04b222a817925d33ba3589b190bfa863 upstream.

Currently x86_64_start_kernel() has two KASAN related
function calls. The first call maps shadow to early_level4_pgt,
the second maps shadow to init_level4_pgt.

If we move clear_page(init_level4_pgt) earlier, we could hide
KASAN low level detail from generic x86_64 initialization code.
The next patch will do it.

Signed-off-by: Andrey Ryabinin 
Cc: Alexander Popov 
Cc: Alexander Potapenko 
Cc: Andrey Konovalov 
Cc: Borislav Petkov 
Cc: Dmitry Vyukov 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1435828178-10975-2-git-send-email-a.ryabinin@samsung.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86/mpx: Do not set ->vm_ops on MPX VMAs

2015-08-03T16:29:19+00:00

commit a89652769470d12cd484ee3d3f7bde0742be8d96 upstream.

MPX setups private anonymous mapping, but uses vma->vm_ops too.
This can confuse core VM, as it relies on vm->vm_ops to
distinguish file VMAs from anonymous.

As result we will get SIGBUS, because handle_pte_fault() thinks
it's file VMA without vm_ops->fault and it doesn't know how to
handle the situation properly.

Let's fix that by not setting ->vm_ops.

We don't really need ->vm_ops here: MPX VMA can be detected with
VM_MPX flag. And vma_merge() will not merge MPX VMA with non-MPX
VMA, because ->vm_flags won't match.

The only thing left is name of VMA. I'm not sure if it's part of
ABI, or we can just drop it. The patch keep it by providing
arch_vma_name() on x86.

Signed-off-by: Kirill A. Shutemov 
Signed-off-by: Dave Hansen 
Cc: Andy Lutomirski 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: dave@sr71.net
Link: http://lkml.kernel.org/r/20150720212958.305CC3E9@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman