kernel/linux.git/arch, branch v3.16.61

x86/apic: Fix build failure with X86_IO_APIC disabled

2018-11-20T18:06:03+00:00

My backport of commit 2e63ad4bd5dd "x86/apic: Do not init irq remapping if ioapic is disabled" added an unconditional use of skip_ioapic_setup. Enabling X86_LOCAL_APIC but not X86_IO_APIC results in a build failure. This configuration was made impossible by commit b1da1e715d4f "x86/Kconfig: Simplify X86_IO_APIC dependencies", but that seems to depend on additional changes that aren't suitable for stable. The function that was changed, enable_IR_x2apic(), is only used in 64-bit configurations where CONFIG_X86_IO_APIC is always enabled. So extend the #ifdef CONFIG_X86_64 section to include this function. Signed-off-by: Ben Hutchings

MIPS: asmmacro: Ensure 64-bit FP registers are used with MSA

2018-11-20T18:06:02+00:00

commit 2bd7bc254ab1f45269db6dd7957d63b713817408 upstream. This silences warnings like the following one when building with the latest binutils: arch/mips/kernel/genex.S: Assembler messages: arch/mips/kernel/genex.S:438: Warning: the `msa' extension requires 64-bit FPRs [ralf@linux-mips.org: Markos says binutils 2.25 and some 2.24 snapshots are affected.] Signed-off-by: Markos Chandras Reviewed-by: James Hogan Cc: Paul Burton Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9745/ Signed-off-by: Ralf Baechle Signed-off-by: Ben Hutchings

arm64: use linux/types.h in kvm.h

2018-11-20T18:06:02+00:00

commit d19279154b3fff9adff96b54d1a77dfb8f01e3da upstream. We should always use linux/types.h instead of asm/types.h for consistency, and Kbuild actually warns about it: ./usr/include/asm/kvm.h:35: include of is preferred over This patch does as Kbuild asks us. Signed-off-by: Arnd Bergmann Signed-off-by: Catalin Marinas Signed-off-by: Ben Hutchings

MIPS: asm: compiler: Add new macros to set ISA and arch asm annotations

2018-11-20T18:06:01+00:00

commit be5136988e25ae0dc8379fcb937efc63d87aba9e upstream. There are certain places where the code uses .set mips32 or .set mips64 or .set arch=r4000. In preparation of MIPS R6 support, and in order to use as less #ifdefs as possible, we define new macros to set similar annotations for MIPS R6. Signed-off-by: Markos Chandras [bwh: Backported to 3.16: We don't support MIPS R6 but I have applied a commit that uses MIPS_ISA_LEVEL_RAW. Add the R2 definitions only.] Signed-off-by: Ben Hutchings

KVM: x86: fix escape of guest dr6 to the host

2018-11-20T18:06:00+00:00

commit efdab992813fb2ed825745625b83c05032e9cda2 upstream. syzkaller reported: WARNING: CPU: 0 PID: 12927 at arch/x86/kernel/traps.c:780 do_debug+0x222/0x250 CPU: 0 PID: 12927 Comm: syz-executor Tainted: G OE 4.15.0-rc2+ #16 RIP: 0010:do_debug+0x222/0x250 Call Trace: <#DB> debug+0x3e/0x70 RIP: 0010:copy_user_enhanced_fast_string+0x10/0x20 _copy_from_user+0x5b/0x90 SyS_timer_create+0x33/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The testcase sets a watchpoint (with perf_event_open) on a buffer that is passed to timer_create() as the struct sigevent argument. In timer_create(), copy_from_user()'s rep movsb triggers the BP. The testcase also sets the debug registers for the guest. However, KVM only restores host debug registers when the host has active watchpoints, which triggers a race condition when running the testcase with multiple threads. The guest's DR6.BS bit can escape to the host before another thread invokes timer_create(), and do_debug() complains. The fix is to respect do_debug()'s dr6 invariant when leaving KVM. Reported-by: Dmitry Vyukov Cc: Paolo Bonzini Cc: Radim Krčmář Cc: David Hildenbrand Cc: Dmitry Vyukov Reviewed-by: David Hildenbrand Signed-off-by: Wanpeng Li Signed-off-by: Paolo Bonzini Signed-off-by: Radim Krčmář [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings

x86/MCE: Remove min interval polling limitation

2018-11-20T18:05:43+00:00

commit fbdb328c6bae0a7c78d75734a738b66b86dffc96 upstream. commit b3b7c4795c ("x86/MCE: Serialize sysfs changes") introduced a min interval limitation when setting the check interval for polled MCEs. However, the logic is that 0 disables polling for corrected MCEs, see Documentation/x86/x86_64/machinecheck. The limitation prevents disabling. Remove this limitation and allow the value 0 to disable polling again. Fixes: b3b7c4795c ("x86/MCE: Serialize sysfs changes") Signed-off-by: Dewet Thibaut Signed-off-by: Alexander Sverdlin [ Massage commit message. ] Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Cc: Tony Luck Cc: linux-edac Link: http://lkml.kernel.org/r/20180716084927.24869-1-alexander.sverdlin@nokia.com Signed-off-by: Ben Hutchings

x86/apm: Don't access __preempt_count with zeroed fs

2018-11-20T18:05:43+00:00

commit 6f6060a5c9cc76fdbc22748264e6aa3779ec2427 upstream. APM_DO_POP_SEGS does not restore fs/gs which were zeroed by APM_DO_ZERO_SEGS. Trying to access __preempt_count with zeroed fs doesn't really work. Move the ibrs call outside the APM_DO_SAVE_SEGS/APM_DO_RESTORE_SEGS invocations so that fs is actually restored before calling preempt_enable(). Fixes the following sort of oopses: [ 0.313581] general protection fault: 0000 [#1] PREEMPT SMP [ 0.313803] Modules linked in: [ 0.314040] CPU: 0 PID: 268 Comm: kapmd Not tainted 4.16.0-rc1-triton-bisect-00090-gdd84441a7971 #19 [ 0.316161] EIP: __apm_bios_call_simple+0xc8/0x170 [ 0.316161] EFLAGS: 00210016 CPU: 0 [ 0.316161] EAX: 00000102 EBX: 00000000 ECX: 00000102 EDX: 00000000 [ 0.316161] ESI: 0000530e EDI: dea95f64 EBP: dea95f18 ESP: dea95ef0 [ 0.316161] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 0.316161] CR0: 80050033 CR2: 00000000 CR3: 015d3000 CR4: 000006d0 [ 0.316161] Call Trace: [ 0.316161] ? cpumask_weight.constprop.15+0x20/0x20 [ 0.316161] on_cpu0+0x44/0x70 [ 0.316161] apm+0x54e/0x720 [ 0.316161] ? __switch_to_asm+0x26/0x40 [ 0.316161] ? __schedule+0x17d/0x590 [ 0.316161] kthread+0xc0/0xf0 [ 0.316161] ? proc_apm_show+0x150/0x150 [ 0.316161] ? kthread_create_worker_on_cpu+0x20/0x20 [ 0.316161] ret_from_fork+0x2e/0x38 [ 0.316161] Code: da 8e c2 8e e2 8e ea 57 55 2e ff 1d e0 bb 5d b1 0f 92 c3 5d 5f 07 1f 89 47 0c 90 8d b4 26 00 00 00 00 90 8d b4 26 00 00 00 00 90 <64> ff 0d 84 16 5c b1 74 7f 8b 45 dc 8e e0 8b 45 d8 8e e8 8b 45 [ 0.316161] EIP: __apm_bios_call_simple+0xc8/0x170 SS:ESP: 0068:dea95ef0 [ 0.316161] ---[ end trace 656253db2deaa12c ]--- Fixes: dd84441a7971 ("x86/speculation: Use IBRS if available before calling into firmware") Signed-off-by: Ville Syrjälä Signed-off-by: Thomas Gleixner Cc: David Woodhouse Cc: "H. Peter Anvin" Cc: x86@kernel.org Cc: David Woodhouse Cc: "H. Peter Anvin" Link: https://lkml.kernel.org/r/20180709133534.5963-1-ville.syrjala@linux.intel.com Signed-off-by: Ben Hutchings

MIPS: Fix off-by-one in pci_resource_to_user()

2018-11-20T18:05:42+00:00

commit 38c0a74fe06da3be133cae3fb7bde6a9438e698b upstream. The MIPS implementation of pci_resource_to_user() introduced in v3.12 by commit 4c2924b725fb ("MIPS: PCI: Use pci_resource_to_user to map pci memory space properly") incorrectly sets *end to the address of the byte after the resource, rather than the last byte of the resource. This results in userland seeing resources as a byte larger than they actually are, for example a 32 byte BAR will be reported by a tool such as lspci as being 33 bytes in size: Region 2: I/O ports at 1000 [disabled] [size=33] Correct this by subtracting one from the calculated end address, reporting the correct address to userland. Signed-off-by: Paul Burton Reported-by: Rui Wang Fixes: 4c2924b725fb ("MIPS: PCI: Use pci_resource_to_user to map pci memory space properly") Cc: James Hogan Cc: Ralf Baechle Cc: Wolfgang Grandegger Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/19829/ [bwh: Backported to 3.16: adjust filename] Signed-off-by: Ben Hutchings

ARC: mm: allow mprotect to make stack mappings executable

2018-11-20T18:05:39+00:00

commit 93312b6da4df31e4102ce5420e6217135a16c7ea upstream. mprotect(EXEC) was failing for stack mappings as default vm flags was missing MAYEXEC. This was triggered by glibc test suite nptl/tst-execstack testcase What is surprising is that despite running LTP for years on, we didn't catch this issue as it lacks a directed test case. gcc dejagnu tests with nested functions also requiring exec stack work fine though because they rely on the GNU_STACK segment spit out by compiler and handled in kernel elf loader. This glibc case is different as the stack is non exec to begin with and a dlopen of shared lib with GNU_STACK segment triggers the exec stack proceedings using a mprotect(PROT_EXEC) which was broken. Signed-off-by: Vineet Gupta Signed-off-by: Ben Hutchings

ARC: Fix CONFIG_SWAP

2018-11-20T18:05:38+00:00

commit 6e3761145a9ba3ce267c330b6bff51cf6a057b06 upstream. swap was broken on ARC due to silly copy-paste issue. We encode offset from swapcache page in __swp_entry() as (off << 13) but were not decoding back in __swp_offset() as (off >> 13) - it was still (off << 13). This finally fixes swap usage on ARC. | # mkswap /dev/sda2 | | # swapon -a -e /dev/sda2 | Adding 500728k swap on /dev/sda2. Priority:-2 extents:1 across:500728k | | # free | total used free shared buffers cached | Mem: 765104 13456 751648 4736 8 4736 | -/+ buffers/cache: 8712 756392 | Swap: 500728 0 500728 Signed-off-by: Alexey Brodkin Signed-off-by: Vineet Gupta Signed-off-by: Ben Hutchings