07 Mar, 2015
36 commits
-
commit 1b43d7125f3b6f7d46e72da64f65f3187a83b66b upstream.
pmc_dbgfs_unregister() will be called when pmc->dbgfs_dir is unconditionally
NULL on error path in pmc_dbgfs_register(). To prevent this we move the
assignment to where is should be.Fixes: f855911c1f48 (x86/pmc_atom: Expose PMC device state and platform sleep state)
Reported-by: Thomas Gleixner
Signed-off-by: Andy Shevchenko
Cc: Aubrey Li
Cc: Rafael J. Wysocki
Cc: Kumar P. Mahesh
Link: http://lkml.kernel.org/r/1421253575-22509-2-git-send-email-andriy.shevchenko@linux.intel.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 1ea76fbadd667b19c4fa4466f3a3b55a505e83d9 upstream.
Commit b568b8601f05 ("Treat SCI interrupt as normal GSI interrupt")
accidently removes support of legacy PIC interrupt when fixing a
regression for Xen, which causes a nasty regression on HP/Compaq
nc6000 where we fail to register the ACPI interrupt, and thus
lose eg. thermal notifications leading a potentially overheated
machine.So reintroduce support of legacy PIC based ACPI SCI interrupt.
Reported-by: Ville Syrjälä
Tested-by: Ville Syrjälä
Signed-off-by: Jiang Liu
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Pavel Machek
Cc: H. Peter Anvin
Cc: Len Brown
Cc: Linus Torvalds
Cc: Rafael J. Wysocki
Cc: Sander Eikelenboom
Cc: linux-pm@vger.kernel.org
Link: http://lkml.kernel.org/r/1424052673-22974-1-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 4e7c22d447bb6d7e37bfe39ff658486ae78e8d77 upstream.
The issue is that the stack for processes is not properly randomized on
64 bit architectures due to an integer overflow.The affected function is randomize_stack_top() in file
"fs/binfmt_elf.c":static unsigned long randomize_stack_top(unsigned long stack_top)
{
unsigned int random_variable = 0;if ((current->flags & PF_RANDOMIZE) &&
!(current->personality & ADDR_NO_RANDOMIZE)) {
random_variable = get_random_int() & STACK_RND_MASK;
random_variable <<
Signed-off-by: Ismael Ripoll
[ Rebased, fixed 80 char bugs, cleaned up commit message, added test example and CVE ]
Signed-off-by: Kees Cook
Cc: Linus Torvalds
Cc: Andrew Morton
Cc: Al Viro
Fixes: CVE-2015-1593
Link: http://lkml.kernel.org/r/20150214173350.GA18393@www.outflux.net
Signed-off-by: Borislav Petkov
Signed-off-by: Greg Kroah-Hartman -
commit 96738c69a7fcdbf0d7c9df0c8a27660011e82a7b upstream.
Andy pointed out that if an NMI or MCE is received while we're in the
middle of an EFI mixed mode call a triple fault will occur. This can
happen, for example, when issuing an EFI mixed mode call while running
perf.The reason for the triple fault is that we execute the mixed mode call
in 32-bit mode with paging disabled but with 64-bit kernel IDT handlers
installed throughout the call.At Andy's suggestion, stop playing the games we currently do at runtime,
such as disabling paging and installing a 32-bit GDT for __KERNEL_CS. We
can simply switch to the __KERNEL32_CS descriptor before invoking
firmware services, and run in compatibility mode. This way, if an
NMI/MCE does occur the kernel IDT handler will execute correctly, since
it'll jump to __KERNEL_CS automatically.However, this change is only possible post-ExitBootServices(). Before
then the firmware "owns" the machine and expects for its 32-bit IDT
handlers to be left intact to service interrupts, etc.So, we now need to distinguish between early boot and runtime
invocations of EFI services. During early boot, we need to restore the
GDT that the firmware expects to be present. We can only jump to the
__KERNEL32_CS code segment for mixed mode calls after ExitBootServices()
has been invoked.A liberal sprinkling of comments in the thunking code should make the
differences in early and late environments more apparent.Reported-by: Andy Lutomirski
Tested-by: Borislav Petkov
Signed-off-by: Matt Fleming
Signed-off-by: Greg Kroah-Hartman -
commit c2996cb29bfb73927a79dc96e598a718e843f01a upstream.
The KSTK_EIP() and KSTK_ESP() macros should return the user program
counter (PC) and stack pointer (A0StP) of the given task. These are used
to determine which VMA corresponds to the user stack in
/proc//maps, and for the user PC & A0StP in /proc//stat.However for Meta the PC & A0StP from the task's kernel context are used,
resulting in broken output. For example in following /proc//maps
output, the 3afff000-3b021000 VMA should be described as the stack:# cat /proc/self/maps
...
100b0000-100b1000 rwxp 00000000 00:00 0 [heap]
3afff000-3b021000 rwxp 00000000 00:00 0And in the following /proc//stat output, the PC is in kernel code
(1074234964 = 0x40078654) and the A0StP is in the kernel heap
(1335981392 = 0x4fa17550):# cat /proc/self/stat
51 (cat) R ... 1335981392 1074234964 ...Fix the definitions of KSTK_EIP() and KSTK_ESP() to use
task_pt_regs(tsk)->ctx rather than (tsk)->thread.kernel_context. This
gets the registers from the user context stored after the thread info at
the base of the kernel stack, which is from the last entry into the
kernel from userland, regardless of where in the kernel the task may
have been interrupted, which results in the following more correct
/proc//maps output:# cat /proc/self/maps
...
0800b000-08070000 r-xp 00000000 00:02 207 /lib/libuClibc-0.9.34-git.so
...
100b0000-100b1000 rwxp 00000000 00:00 0 [heap]
3afff000-3b021000 rwxp 00000000 00:00 0 [stack]And /proc//stat now correctly reports the PC in libuClibc
(134320308 = 0x80190b4) and the A0StP in the [stack] region (989864576 =
0x3b002280):# cat /proc/self/stat
51 (cat) R ... 989864576 134320308 ...Reported-by: Alexey Brodkin
Reported-by: Vineet Gupta
Signed-off-by: James Hogan
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 9d42d48a342aee208c1154696196497fdc556bbf upstream.
The native (64-bit) sigval_t union contains sival_int (32-bit) and
sival_ptr (64-bit). When a compat application invokes a syscall that
takes a sigval_t value (as part of a larger structure, e.g.
compat_sys_mq_notify, compat_sys_timer_create), the compat_sigval_t
union is converted to the native sigval_t with sival_int overlapping
with either the least or the most significant half of sival_ptr,
depending on endianness. When the corresponding signal is delivered to a
compat application, on big endian the current (compat_uptr_t)sival_ptr
cast always returns 0 since sival_int corresponds to the top part of
sival_ptr. This patch fixes copy_siginfo_to_user32() so that sival_int
is copied to the compat_siginfo_t structure.Reported-by: Bamvor Jian Zhang
Tested-by: Bamvor Jian Zhang
Signed-off-by: Catalin Marinas
Signed-off-by: Greg Kroah-Hartman -
commit a52d209336f8fc7483a8c7f4a8a7d2a8e1692a6c upstream.
Since the removal of CONFIG_REGULATOR_DUMMY option, the touchscreen stopped
working. This patch enables the "replacement" for REGULATOR_DUMMY and
allows the touchscreen to work even though there is no regulator for "vcc".Signed-off-by: Martin Vajnar
Signed-off-by: Robert Jarzmik
Signed-off-by: Greg Kroah-Hartman -
commit 428d53be5e7468769d4e7899cca06ed5f783a6e1 upstream.
We have to delete the allocated interrupt info if __inject_vm() fails.
Otherwise user space can keep flooding kvm with floating interrupts and
provoke more and more memory leaks.Reported-by: Dominik Dingel
Reviewed-by: Dominik Dingel
Signed-off-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
Signed-off-by: Greg Kroah-Hartman -
commit 8e2207cdd087ebb031e9118d1fd0902c6533a5e5 upstream.
If a vm with no VCPUs is created, the injection of a floating irq
leads to an endless loop in the kernel.Let's skip the search for a destination VCPU for a floating irq if no
VCPUs were created.Reviewed-by: Dominik Dingel
Reviewed-by: Cornelia Huck
Signed-off-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
Signed-off-by: Greg Kroah-Hartman -
commit 0ac96caf0f9381088c673a16d910b1d329670edf upstream.
The hrtimer that handles the wait with enabled timer interrupts
should not be disturbed by changes of the host time.This patch changes our hrtimer to be based on a monotonic clock.
Signed-off-by: David Hildenbrand
Acked-by: Cornelia Huck
Signed-off-by: Christian Borntraeger
Signed-off-by: Greg Kroah-Hartman -
commit 2d00f759427bb3ed963b60f570830e9eca7e1c69 upstream.
Patch 0759d0681cae ("KVM: s390: cleanup handle_wait by reusing
kvm_vcpu_block") changed the way pending guest clock comparator
interrupts are detected. It was assumed that as soon as the hrtimer
wakes up, the condition for the guest ckc is satisfied.This is however only true as long as adjclock() doesn't speed
up the monotonic clock. Reason is that the hrtimer is based on
CLOCK_MONOTONIC, the guest clock comparator detection is based
on the raw TOD clock. If CLOCK_MONOTONIC runs faster than the
TOD clock, the hrtimer wakes the target VCPU up too early and
the target VCPU will not detect any pending interrupts, therefore
going back to sleep. It will never be woken up again because the
hrtimer has finished. The VCPU is stuck.As a quick fix, we have to forward the hrtimer until the guest
clock comparator is really due, to guarantee properly timed wake
ups.As the hrtimer callback might be triggered on another cpu, we
have to make sure that the timer is really stopped and not currently
executing the callback on another cpu. This can happen if the vcpu
thread is scheduled onto another physical cpu, but the timer base
is not migrated. So lets use hrtimer_cancel instead of try_to_cancel.A proper fix might be to introduce a RAW based hrtimer.
Reported-by: Christian Borntraeger
Signed-off-by: David Hildenbrand
Acked-by: Cornelia Huck
Signed-off-by: Christian Borntraeger
Signed-off-by: Greg Kroah-Hartman -
commit ed4cbc81addbc076b016c5b979fd1a02f0897f0a upstream.
activate_mm() and switch_mm() call get_new_mmu_context() which in turn
can enable the HTW before the entryhi is changed with the new ASID.
Since the latter will enable the HTW in local_flush_tlb_all(),
then there is a small timing window where the HTW is running with the
new ASID but with an old pgd since the TLBMISS_HANDLER_SETUP_PGD
hasn't assigned a new one yet. In order to prevent that, we introduce a
simple htw counter to avoid starting HTW accidentally due to nested
htw_{start,stop}() sequences. Moreover, since various IPI calls can
enforce TLB flushing operations on a different core, such an operation
may interrupt another htw_{stop,start} in progress leading inconsistent
updates of the htw_seq variable. In order to avoid that, we disable the
interrupts whenever we update that variable.Signed-off-by: Markos Chandras
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9118/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit 06f34e1c28f3608b0ce5b310e41102d3fe7b65a1 upstream.
We used to calculate page address differently in 2 cases:
1. In virt_to_page(x) we do
--->8---
mem_map + (x - CONFIG_LINUX_LINK_BASE) >> PAGE_SHIFT
--->8---2. In in pte_page(x) we do
--->8---
mem_map + (pte_val(x) - PAGE_OFFSET) >> PAGE_SHIFT
--->8---That leads to problems in case PAGE_OFFSET != CONFIG_LINUX_LINK_BASE -
different pages will be selected depending on where and how we calculate
page address.In particular in the STAR 9000853582 when gdb attempted to read memory
of another process it got improper page in get_user_pages() because this
is exactly one of the places where we search for a page by pte_page().The fix is trivial - we need to calculate page address similarly in both
cases.Signed-off-by: Alexey Brodkin
Signed-off-by: Vineet Gupta
Signed-off-by: Greg Kroah-Hartman -
commit 165235180ff61f0012ea68a299e46daec43dcaa7 upstream.
mvebu_armada375_smp_wa_init is only used on armada 375 but is defined
for all mvebu machines. As it calls a function that is only provided
sometimes, this can result in a link error:arch/arm/mach-mvebu/built-in.o: In function `mvebu_armada375_smp_wa_init':
:(.text+0x228): undefined reference to `mvebu_setup_boot_addr_wa'To solve this, we can just change the existing #ifdef around the
function to also check for Armada375 SMP platforms.Signed-off-by: Arnd Bergmann
Fixes: 305969fb6292 ("ARM: mvebu: use the common function for Armada 375 SMP workaround")
Cc: Andrew Lunn
Cc: Jason Cooper
Cc: Gregory Clement
Signed-off-by: Greg Kroah-Hartman -
commit 95fcedb027a27f32bf2434f9271635c380e57fb5 upstream.
The vexpress tc2 power management code calls mcpm_loopback, which
is only available if ARM_CPU_SUSPEND is enabled, otherwise we
get a link error:arch/arm/mach-vexpress/built-in.o: In function `tc2_pm_init':
arch/arm/mach-vexpress/tc2_pm.c:389: undefined reference to `mcpm_loopback'This explicitly selects ARM_CPU_SUSPEND like other platforms that
need it.Signed-off-by: Arnd Bergmann
Fixes: 3592d7e002438 ("ARM: 8082/1: TC2: test the MCPM loopback during boot")
Acked-by: Nicolas Pitre
Acked-by: Liviu Dudau
Cc: Kevin Hilman
Cc: Sudeep Holla
Cc: Lorenzo Pieralisi
Signed-off-by: Greg Kroah-Hartman -
commit ff34cae5b4fc7a84113d7c7e8611ba87a7c31dba upstream.
A recent cleanup rearranged the Kconfig file for mach-bcm and
accidentally dropped the dependency on ARCH_MULTI_V7, which
makes it possible to now build the two mobile SoC platforms
on an ARMv6-only kernel, resulting in a log of Kconfig
warnings likewarning: ARCH_BCM_MOBILE selects ARM_ERRATA_775420 which has unmet direct dependencies (CPU_V7)
and which of course cannot work on any machine.
This puts back the dependencies as before.
Signed-off-by: Arnd Bergmann
Fixes: 64e74aa788f99 ("ARM: mach-bcm: ARCH_BCM_MOBILE: remove one level of menu from Kconfig")
Acked-by: Florian Fainelli
Acked-by: Scott Branden
Signed-off-by: Greg Kroah-Hartman -
commit a1ad3b94a7661b643fef2efbc6fc217bd148f462 upstream.
The automatic CPU power state machine for B15 CPUs does not work
reliably as-is. This patch implements a manual sequence in software to
replace it.This was tested successfully with over 10,000 hotplug cycles of
something like this:echo 0 > /sys/devices/system/cpu/cpu1/online
echo 1 > /sys/devices/system/cpu/cpu1/onlinewhereas the existing sequence often locks up after a few hundred cycles.
Fixes: 62639c2f5332 ("ARM: brcmstb: reintroduce SMP support")
Acked-by: Gregory Fong
Signed-off-by: Brian Norris
Signed-off-by: Florian Fainelli
Signed-off-by: Greg Kroah-Hartman -
commit baad2dc49c5d970ea881d92981a1b76c94a7b7a1 upstream.
Add regulator_has_full_constraints() call to spitz board file to let
regulator core know that we do not have any additional regulators left.
This lets it substitute unprovided regulators with dummy ones.This fixes the following warnings that can be seen on spitz if
regulators are enabled:ads7846 spi2.0: unable to get regulator: -517
spi spi2.0: Driver ads7846 requests probe deferralSigned-off-by: Dmitry Eremin-Solenikov
Acked-by: Mark Brown
Signed-off-by: Robert Jarzmik
Signed-off-by: Greg Kroah-Hartman -
commit 9bc78f32c2e430aebf6def965b316aa95e37a20c upstream.
Add regulator_has_full_constraints() call to poodle board file to let
regulator core know that we do not have any additional regulators left.
This lets it substitute unprovided regulators with dummy ones.This fixes the following warnings that can be seen on poodle if
regulators are enabled:ads7846 spi1.0: unable to get regulator: -517
spi spi1.0: Driver ads7846 requests probe deferral
wm8731 0-001b: Failed to get supply 'AVDD': -517
wm8731 0-001b: Failed to request supplies: -517
wm8731 0-001b: ASoC: failed to probe component -517Signed-off-by: Dmitry Eremin-Solenikov
Acked-by: Mark Brown
Signed-off-by: Robert Jarzmik
Signed-off-by: Greg Kroah-Hartman -
commit 271e80176aae4e5b481f4bb92df9768c6075bbca upstream.
Add regulator_has_full_constraints() call to corgi board file to let
regulator core know that we do not have any additional regulators left.
This lets it substitute unprovided regulators with dummy ones.This fixes the following warnings that can be seen on corgi if
regulators are enabled:ads7846 spi1.0: unable to get regulator: -517
spi spi1.0: Driver ads7846 requests probe deferral
wm8731 0-001b: Failed to get supply 'AVDD': -517
wm8731 0-001b: Failed to request supplies: -517
wm8731 0-001b: ASoC: failed to probe component -517
corgi-audio corgi-audio: ASoC: failed to instantiate card -517Signed-off-by: Dmitry Eremin-Solenikov
Acked-by: Mark Brown
Signed-off-by: Robert Jarzmik
Signed-off-by: Greg Kroah-Hartman -
commit 91117a20245b59f70b563523edbf998a62fc6383 upstream.
The 'pfn' returned by axonram was completely bogus, and has been since
2008.Signed-off-by: Matthew Wilcox
Reviewed-by: Jan Kara
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 9df11828d9b5665ddef81e45f83dd5376a8cd620 upstream.
The L2 cache properties were completely off with respect to what the
hardware is configured for. Fix the cache-size, cache-line-size and
cache-sets to reflect the L2 cache controller we have: 512KB, 16 ways
and 32 bytes per cache-line.Fixes: 46d4bca0445a0 ("ARM: BCM63XX: add BCM63138 minimal Device Tree")
Signed-off-by: Florian Fainelli
Signed-off-by: Greg Kroah-Hartman -
commit 67fd14b3eca63b14429350e9eadc5fab709a8821 upstream.
Fixes: http://bugs.elinux.org/issues/127
the bb.org community was seeing random reboots before this change.
Signed-off-by: Robert Nelson
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit de47699d005996b41cea590c6098078ac12058be upstream.
Commit 58ecb23f64ee ("ARM: tegra: add missing unit addresses to DT") added
unit address and changed reg base for GR3D and DSI host1x modules, but these
addresses belongs to GR2D and TVO modules respectively. Fix it by changing
modules unit and reg base addresses to proper ones.Signed-off-by: Dmitry Osipenko
Fixes: 58ecb23f64ee (ARM: tegra: add missing unit addresses to DT)
Reviewed-by: Alexandre Courbot
Signed-off-by: Thierry Reding
Signed-off-by: Greg Kroah-Hartman -
commit 1c7e36bfc3e2fb2df5e2d1989a4b6fb9055a0f9b upstream.
With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset()
with DEBUG_LL' we moved from parsing cmdline to identify uart used
for earlycon to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.On DRA7 UART3 hwmod doesn't have this flag enabled, and atleast on
BeagleBoard-X15, where we use UART3 for console, boot fails with
DEBUG_LL enabled. Enable DEBUG_OMAP4UART3_FLAGS for UART3 hwmod.For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig.
Fixes: 90020c7b2c5e ("ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data")
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
Signed-off-by: Lokesh Vutla
Signed-off-by: Paul Walmsley
Signed-off-by: Greg Kroah-Hartman -
commit e461894dc2ce7778ccde1c3483c9b15a85a7fc5f upstream.
StrongARM core uses RCSR SMR bit to tell to bootloader that it was reset
by entering the sleep mode. After we have resumed, there is little point
in having that bit enabled. Moreover, if this bit is set before reboot,
the bootloader can become confused. Thus clear the SMR bit on resume
just before clearing the scratchpad (resume address) register.Signed-off-by: Dmitry Eremin-Solenikov
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit cbef8478bee55775ac312a574aad48af7bb9cf9f upstream.
Migrating hugepages and hwpoisoned hugepages are considered as non-present
hugepages, and they are referenced via migration entries and hwpoison
entries in their page table slots.This behavior causes race condition because pmd_huge() doesn't tell
non-huge pages from migrating/hwpoisoned hugepages. follow_page_mask() is
one example where the kernel would call follow_page_pte() for such
hugepage while this function is supposed to handle only normal pages.To avoid this, this patch makes pmd_huge() return true when pmd_none() is
true *and* pmd_present() is false. We don't have to worry about mixing up
non-present pmd entry with normal pmd (pointing to leaf level pte entry)
because pmd_present() is true in normal pmd.The same race condition could happen in (x86-specific) gup_pmd_range(),
where this patch simply adds pmd_present() check instead of pmd_huge().
This is because gup_pmd_range() is fast path. If we have non-present
hugepage in this function, we will go into gup_huge_pmd(), then return 0
at flag mask check, and finally fall back to the slow path.Fixes: 290408d4a2 ("hugetlb: hugepage migration core")
Signed-off-by: Naoya Horiguchi
Cc: Hugh Dickins
Cc: James Hogan
Cc: David Rientjes
Cc: Mel Gorman
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Rik van Riel
Cc: Andrea Arcangeli
Cc: Luiz Capitulino
Cc: Nishanth Aravamudan
Cc: Lee Schermerhorn
Cc: Steve Capper
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit ca5d25642e212f73492d332d95dc90ef46a0e8dc upstream.
Export the _save_msa asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make use of it when it is built as a module.This fixes the following build error when CONFIG_KVM=m and
CONFIG_CPU_HAS_MSA=y due to commit f798217dfd03 ("KVM: MIPS: Don't leak
FPU/DSP to guest"):ERROR: "_save_msa" [arch/mips/kvm/kvm.ko] undefined!
Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest)
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Ralf Baechle
Cc: Paul Burton
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9261/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit 3ce465e04bfd8de9956d515d6e9587faac3375dc upstream.
Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make use of it when it is built as a module.This fixes the following build error when CONFIG_KVM=m due to commit
f798217dfd03 ("KVM: MIPS: Don't leak FPU/DSP to guest"):ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined!
Signed-off-by: James Hogan
Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest)
Cc: Paolo Bonzini
Cc: Ralf Baechle
Cc: Paul Burton
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9260/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit fde3538a8a711aedf1173ecb2d45aed868f51c97 upstream.
Whenever we modify a page table entry, we need to ensure that the HTW
will not fetch a stable entry. And for that to happen we need to ensure
that HTW is stopped before we modify the said entry otherwise the HTW
may already be in the process of reading that entry and fetching the
old information. As a result of which, we replace the htw_reset() calls
with htw_{stop,start} in more appropriate places. This also removes the
remaining users of htw_reset() and as a result we drop that macroSigned-off-by: Markos Chandras
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9116/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit 461d1597ffad7a826f8aaa63ab0727c37b632e34 upstream.
When we use htw_{start,stop}() outside of htw_reset(), we need
to ensure that c0 changes have been propagated properly before
we attempt to continue with subsequence memory operations.Signed-off-by: Markos Chandras
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9114/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit 98a833c1fa4de0695830f77b2d13fd86693da298 upstream.
The "add" instruction is actually a macro in binutils and depending on
the size of the immediate it can expand to an "addi" instruction.
However, the "addi" instruction traps on overflows which is not
something we want on address calculation.Link: http://www.linux-mips.org/archives/linux-mips/2015-01/msg00121.html
Cc: Paul Burton
Cc: Maciej W. Rozycki
Signed-off-by: Markos Chandras
Signed-off-by: Greg Kroah-Hartman -
commit acac4108df6029c03195513ead7073bbb0cb9718 upstream.
The "addi" instruction will trap on overflows which is not something
we need in this code, so we replace that with "addiu".Link: http://www.linux-mips.org/archives/linux-mips/2015-01/msg00430.html
Cc: Maciej W. Rozycki
Cc: Paul Burton
Signed-off-by: Markos Chandras
Signed-off-by: Greg Kroah-Hartman -
commit 69e4e63ec816a7e22cc3aa14bc7ef4ac734d370c upstream.
The current code uses bits 0-6 of the sys_cpupll register to calculate
core clock speed. However this is only valid on Au1300, on all earlier
models the hardware only uses bits 0-5 to generate core clock.This fixes clock calculation on the MTX1 (Au1500), where bit 6 of cpupll
is set as well, which ultimately lead the code to calculate a bogus cpu
core clock and also uart base clock down the line.Signed-off-by: Manuel Lauss
Reported-by: John Crispin
Tested-by: Bruno Randolf
Cc: Linux-MIPS
Patchwork: https://patchwork.linux-mips.org/patch/9279/
Signed-off-by: Ralf Baechle
Signed-off-by: Greg Kroah-Hartman -
commit f798217dfd038af981a18bbe4bc57027a08bb182 upstream.
The FPU and DSP are enabled via the CP0 Status CU1 and MX bits by
kvm_mips_set_c0_status() on a guest exit, presumably in case there is
active state that needs saving if pre-emption occurs. However neither of
these bits are cleared again when returning to the guest.This effectively gives the guest access to the FPU/DSP hardware after
the first guest exit even though it is not aware of its presence,
allowing FP instructions in guest user code to intermittently actually
execute instead of trapping into the guest OS for emulation. It will
then read & manipulate the hardware FP registers which technically
belong to the user process (e.g. QEMU), or are stale from another user
process. It can also crash the guest OS by causing an FP exception, for
which a guest exception handler won't have been registered.First lets save and disable the FPU (and MSA) state with lose_fpu(1)
before entering the guest. This simplifies the problem, especially for
when guest FPU/MSA support is added in the future, and prevents FR=1 FPU
state being live when the FR bit gets cleared for the guest, which
according to the architecture causes the contents of the FPU and vector
registers to become UNPREDICTABLE.We can then safely remove the enabling of the FPU in
kvm_mips_set_c0_status(), since there should never be any active FPU or
MSA state to save at pre-emption, which should plug the FPU leak.DSP state is always live rather than being lazily restored, so for that
it is simpler to just clear the MX bit again when re-entering the guest.Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Ralf Baechle
Cc: Sanjay Lal
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit c4c6f2cad9e1d4cc076bc183c3689cc9e7019c75 upstream.
Ensure any hardware page table walker (HTW) is disabled while in KVM
guest mode, as KVM doesn't yet set up hardware page table walking for
guest mappings so the wrong mappings would get loaded, resulting in the
guest hanging or crashing once it reaches userland.The HTW is disabled and re-enabled around the call to
__kvm_mips_vcpu_run() which does the initial switch into guest mode and
the final switch out of guest context. Additionally it is enabled for
the duration of guest exits (i.e. kvm_mips_handle_exit()), getting
disabled again before returning back to guest or host.In all cases the HTW is only disabled in normal kernel mode while
interrupts are disabled, so that the HTW doesn't get left disabled if
the process is preempted.Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Ralf Baechle
Cc: Markos Chandras
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman
09 Feb, 2015
2 commits
-
Pull nios2 fix from Ley Foon Tan:
"This fixes incorrect behavior of some user programs"* tag 'nios2-fixes-v3.19-final' of git://git.rocketboards.org/linux-socfpga-next:
nios2: fix unhandled signals -
Follow other architectures for user fault handling.
Signed-off-by: Chung-Ling Tang
Acked-by: Ley Foon Tan
07 Feb, 2015
2 commits
-
….kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull timer and x86 fix from Ingo Molnar:
"A CLOCK_TAI early expiry fix and an x86 microcode driver oops fix"* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
hrtimer: Fix incorrect tai offset calculation for non high-res timer systems* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, microcode: Return error from driver init code when loader is disabled -
Pull sound fixes from Takashi Iwai:
"Hopefully the final pull request for 3.19: this ended up with a
slightly higher volume than wished, but I put them all as they are
either stable or 3.19 regression fixes.Most of commits are from ASoC, and have been stewed for a while in
linux-next. The only change in the common code is the regression
fixes for ASoC AC97 stuff wrt device registrations. The rest are
device-specific, mostly small fixes in various ASoC drivers and ak411x
on ice1724 boards"* tag 'sound-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ASoC: Intel: fix sst firmware path for cht-bsw-rt5672
ARM: dts: Fix I2S1, I2S2 compatible for exynos4 SoCs
ASoC: sgtl5000: add delay before first I2C access
MAINTAINERS: ASoC: add maintainer for Intel BDW/HSW ASoC driver
ASoC: atmel_ssc_dai: fix the setting for DSP mode
ASoC: sgtl5000: Use shift mask when setting codec mode
ASoC: tlv320aic3x: Fix data delay configuration
ALSA: ak411x: Fix stall in work callback
ASoC: Intel: Used lock version to update shim registers
ASoC: wm8731: init mutex in i2c init path
ASoC: atmel_ssc_dai: fix start event for I2S mode
ASoC: rt5640: Add RT5642 ACPI ID for Intel Baytrail
ASoC: wm97xx: Reset AC'97 device before registering it
ASoC: Add support for allocating AC'97 device before registering it