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

avr32: handle NULL as a valid clock object

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

commit 5c02a4206538da12c040b51778d310df84c6bf6c upstream.

Since NULL is used as valid clock object on optional clocks we have to handle
this case in avr32 implementation as well.

Fixes: e1824dfe0d8e (net: macb: Adjust tx_clk when link speed changes)
Signed-off-by: Andy Shevchenko 
Acked-by: Hans-Christian Egtvedt 
Signed-off-by: Greg Kroah-Hartman

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

ARC: Make ARC bitops "safer" (add anti-optimization)

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

commit 80f420842ff42ad61f84584716d74ef635f13892 upstream.

ARCompact/ARCv2 ISA provide that any instructions which deals with
bitpos/count operand ASL, LSL, BSET, BCLR, BMSK .... will only consider
lower 5 bits. i.e. auto-clamp the pos to 0-31.

ARC Linux bitops exploited this fact by NOT explicitly masking out upper
bits for @nr operand in general, saving a bunch of AND/BMSK instructions
in generated code around bitops.

While this micro-optimization has worked well over years it is NOT safe
as shifting a number with a value, greater than native size is
"undefined" per "C" spec.

So as it turns outm EZChip ran into this eventually, in their massive
muti-core SMP build with 64 cpus. There was a test_bit() inside a loop
from 63 to 0 and gcc was weirdly optimizing away the first iteration
(so it was really adhering to standard by implementing undefined behaviour
vs. removing all the iterations which were phony i.e. (1 << [63..32])

| for i = 63 to 0
|    X = ( 1 << i )
|    if X == 0
|       continue

So fix the code to do the explicit masking at the expense of generating
additional instructions. Fortunately, this can be mitigated to a large
extent as gcc has SHIFT_COUNT_TRUNCATED which allows combiner to fold
masking into shift operation itself. It is currently not enabled in ARC
gcc backend, but could be done after a bit of testing.

Fixes STAR 9000866918 ("unsafe "undefined behavior" code in kernel")

Reported-by: Noam Camus 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: Reduce bitops lines of code using macros

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

commit 04e2eee4b02edcafce96c9c37b31b1a3318291a4 upstream.

No semantical changes !

Acked-by: Peter Zijlstra (Intel) 
Signed-off-by: Vineet Gupta 
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

arm64/efi: map the entire UEFI vendor string before reading it

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

commit f91b1feada0b6f0a4d33648155b3ded2c4e0707e upstream.

At boot, the UTF-16 UEFI vendor string is copied from the system
table into a char array with a size of 100 bytes. However, this
size of 100 bytes is also used for memremapping() the source,
which may not be sufficient if the vendor string exceeds 50
UTF-16 characters, and the placement of the vendor string inside
a 4 KB page happens to leave the end unmapped.

So use the correct '100 * sizeof(efi_char16_t)' for the size of
the mapping.

Signed-off-by: Ard Biesheuvel 
Fixes: f84d02755f5a ("arm64: add EFI runtime services")
Signed-off-by: Catalin Marinas 
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

tile: use free_bootmem_late() for initrd

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

commit 3f81d2447b37ac697b3c600039f2c6b628c06e21 upstream.

We were previously using free_bootmem() and just getting lucky
that nothing too bad happened.

Signed-off-by: Chris Metcalf 
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