24 Oct, 2013
3 commits
-
In latest UEFI spec(by now it is 2.4) memory error definition
for CPER (UEFI 2.4 Appendix N Common Platform Error Record)
adds some new fields. These fields help people to locate
memory error to an actual DIMM location.Original-author: Tony Luck
Signed-off-by: Chen, Gong
Reviewed-by: Borislav Petkov
Reviewed-by: Mauro Carvalho Chehab
Acked-by: Naveen N. Rao
Signed-off-by: Tony Luck -
This patch adds a new interface to decode memory device (type 17)
to help error reporting on DIMMs.Original-author: Tony Luck
Signed-off-by: Chen, Gong
Acked-by: Naveen N. Rao
Acked-by: Borislav Petkov
Reviewed-by: Mauro Carvalho Chehab
Signed-off-by: Tony Luck -
This H/W error log driver (a.k.a eMCA driver) is implemented based on
http://www.intel.com/content/www/us/en/architecture-and-technology/enhanced-mca-logging-xeon-paper.htmlAfter errors are captured, more detailed platform specific information
can be got via this new enhanced H/W error log driver. Most notably we
can track memory errors back to the DIMM slot silk screen label.Signed-off-by: Chen, Gong
Signed-off-by: Tony Luck
19 Oct, 2013
1 commit
-
Pull x86 fixes from Ingo Molnar:
"Two fixlets:- fix a (rare-config) build bug
- fix a next-gen SGI/UV hw/firmware enumeration bug"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86: Update UV3 hub revision ID
x86/microcode: Correct Kconfig dependencies
16 Oct, 2013
4 commits
-
Pull device tree fixes and reverts from Grant Likely:
"One bug fix and three reverts. The reverts back out the slightly
controversial feeding the entire device tree into the random pool and
the reserved-memory binding which isn't fully baked yet. Expect the
reserved-memory patches at least to resurface for v3.13.The bug fixes removes a scary but harmless warning on SPARC that was
introduced in the v3.12 merge window. v3.13 will contain a proper fix
that makes the new code work on SPARC.On the plus side, the diffstat looks *awesome*. I love removing lines
of code"* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux:
Revert "drivers: of: add initialization code for dma reserved memory"
Revert "ARM: init: add support for reserved memory defined by device tree"
Revert "of: Feed entire flattened device tree into the random pool"
of: fix unnecessary warning on missing /cpus node -
Pull DMA-mapping fix from Marek Szyprowski:
"A bugfix for the IOMMU-based implementation of dma-mapping subsystem
for ARM architecture"* 'fixes-for-v3.12' of git://git.linaro.org/people/mszyprowski/linux-dma-mapping:
ARM: dma-mapping: Always pass proper prot flags to iommu_map() -
Pull kvm fix from Gleb Natapov.
* git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: Enable pvspinlock after jump_label_init() to avoid VM hang -
Pull Xen fixes from Stefano Stabellini:
"A small fix for Xen on x86_32 and a build fix for xen-tpmfront on
arm64"* tag 'stable/for-linus-3.12-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen: Fix possible user space selector corruption
tpm: xen-tpmfront: fix missing declaration of xen_domain
15 Oct, 2013
4 commits
-
We use jump label to enable pv-spinlock. With the changes in (442e0973e927
Merge branch 'x86/jumplabel'), the jump label behaviour has changed
that would result in eventual hang of the VM since we would end up in a
situation where slow path locks would halt the vcpus but we will not be
able to wakeup the vcpu by lock releaser using unlock kick.Similar problem in Xen and more detailed description is available in
a945928ea270 (xen: Do not enable spinlocks before jump_label_init()
has executed)This patch splits kvm_spinlock_init to separate jump label changes with
pvops patching and also make jump label enabling after jump_label_init().Signed-off-by: Raghavendra K T
Reviewed-by: Paolo Bonzini
Reviewed-by: Steven Rostedt
Signed-off-by: Gleb Natapov -
This reverts commit 10bcdfb8ba24760f715f0a700c3812747eddddf5. There is
no consensus on the bindings for the reserved memory, so the code for
handing it will be reverted.Signed-off-by: Marek Szyprowski
Signed-off-by: Grant Likely -
The UV3 hub revision ID is different than expected. The first
revision was supposed to start at 1 but instead will start at 0.Signed-off-by: Russ Anderson
Cc: # v3.9, v3.10, v3.11
Link: http://lkml.kernel.org/r/20131014161733.GA6274@sgi.com
Signed-off-by: Ingo Molnar -
Pull ARM fixes from Russell King:
"Some more ARM fixes, nothing particularly major here. The biggest
change is to fix the SMP_ON_UP code so that it works with TI's Aegis
cores"* 'fixes' of git://git.linaro.org/people/rmk/linux-arm:
ARM: 7851/1: check for number of arguments in syscall_get/set_arguments()
ARM: 7846/1: Update SMP_ON_UP code to detect A9MPCore with 1 CPU devices
ARM: 7845/1: sharpsl_param.c: fix invalid memory access for pxa devices
ARM: 7843/1: drop asm/types.h from generic-y
ARM: 7842/1: MCPM: don't explode if invoked without being initialized first
14 Oct, 2013
5 commits
-
I have a randconfig here which has enabled only
CONFIG_MICROCODE=y
CONFIG_MICROCODE_OLD_INTERFACE=ywith both
# CONFIG_MICROCODE_INTEL is not set
# CONFIG_MICROCODE_AMD is not setoff. Which makes building the microcode functionality a little
pointless. Don't do that in such cases then.Signed-off-by: Borislav Petkov
Link: http://lkml.kernel.org/r/1381682189-14470-1-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar -
In ftrace_syscall_enter(),
syscall_get_arguments(..., 0, n, ...)
if (i == 0) { ...; n--;}
memcpy(..., n * sizeof(args[0]));
If 'number of arguments(n)' is zero and 'argument index(i)' is also zero in
syscall_get_arguments(), none of arguments should be copied by memcpy().
Otherwise 'n--' can be a big positive number and unexpected amount of data
will be copied. Tracing system calls which take no argument, say sync(void),
may hit this case and eventually make the system corrupted.
This patch fixes the issue both in syscall_get_arguments() and
syscall_set_arguments().Cc:
Acked-by: Will Deacon
Signed-off-by: AKASHI Takahiro
Signed-off-by: Will Deacon
Signed-off-by: Russell King -
Pull ARM SoC fixes from Olof Johansson:
"A small batch of fixes this week, mostly OMAP related. Nothing stands
out as particularly controversial.Also a fix for a 3.12-rc1 timer regression for Exynos platforms,
including the Chromebooks"* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: exynos: dts: Update 5250 arch timer node with clock frequency
ARM: OMAP2: RX-51: Add missing max_current to rx51_lp5523_led_config
ARM: mach-omap2: board-generic: fix undefined symbol
ARM: dts: Fix pinctrl mask for omap3
ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
ARM: OMAP2: gpmc-onenand: fix sync mode setup with DT -
Without the "clock-frequency" property in arch timer node, could able
to see the below crash dump.[] (unwind_backtrace+0x0/0xf4) from [] (show_stack+0x10/0x14)
[] (show_stack+0x10/0x14) from [] (dump_stack+0x7c/0xb0)
[] (dump_stack+0x7c/0xb0) from [] (Ldiv0_64+0x8/0x18)
[] (Ldiv0_64+0x8/0x18) from [] (clockevents_config.part.2+0x1c/0x74)
[] (clockevents_config.part.2+0x1c/0x74) from [] (clockevents_config_and_register+0x20/0x2c)
[] (clockevents_config_and_register+0x20/0x2c) from [] (arch_timer_setup+0xa8/0x134)
[] (arch_timer_setup+0xa8/0x134) from [] (arch_timer_init+0x1f4/0x24c)
[] (arch_timer_init+0x1f4/0x24c) from [] (clocksource_of_init+0x34/0x58)
[] (clocksource_of_init+0x34/0x58) from [] (time_init+0x20/0x2c)
[] (time_init+0x20/0x2c) from [] (start_kernel+0x1e0/0x39c)THis is because the Exynos u-boot, for example on the Chromebooks, doesn't set
up the CNTFRQ register as expected by arch_timer. Instead, we have to specify
the frequency in the device tree like this.Signed-off-by: Yuvaraj Kumar C D
[olof: Changed subject, added comment, elaborated on commit message]
Signed-off-by: Olof Johansson -
…kernel/git/tmlind/linux-omap into fixes
From Tony Lindgren:
Few fixes for omap3 related hangs and errors that people have
noticed now that people are actually using the device tree
based booting for omap3.Also one regression fix for timer compile for dra7xx when
omap5 is not selected, and a LED regression fix for n900.* tag 'fixes-against-v3.12-rc3-take2' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2: RX-51: Add missing max_current to rx51_lp5523_led_config
ARM: mach-omap2: board-generic: fix undefined symbol
ARM: dts: Fix pinctrl mask for omap3
ARM: OMAP3: Fix hardware detection for omap3630 when booted with device tree
ARM: OMAP2: gpmc-onenand: fix sync mode setup with DTSigned-off-by: Olof Johansson <olof@lixom.net>
13 Oct, 2013
10 commits
-
Signed-off-by: Helge Deller
-
The attached change defers the initialization of the variables tsk, mm
and flags until they are needed. As a result, the code won't crash if a
kernel probe is done with a corrupt context and the code will be better
optimized.Signed-off-by: John David Anglin
Signed-off-by: Helge Deller -
Running an "echo t > /proc/sysrq-trigger" crashes the parisc kernel. The
problem is, that in print_worker_info() we try to read the workqueue info via
the probe_kernel_read() functions which use pagefault_disable() to avoid
crashes like this:
probe_kernel_read(&pwq, &worker->current_pwq, sizeof(pwq));
probe_kernel_read(&wq, &pwq->wq, sizeof(wq));
probe_kernel_read(name, wq->name, sizeof(name) - 1);The problem here is, that the first probe_kernel_read(&pwq) might return zero
in pwq and as such the following probe_kernel_reads() try to access contents of
the page zero which is read protected and generate a kernel segfault.With this patch we fix the interruption handler to call parisc_terminate()
directly only if pagefault_disable() was not called (in which case
preempt_count()==0). Otherwise we hand over to the pagefault handler which
will try to look up the faulting address in the fixup tables.Signed-off-by: Helge Deller
Cc: # v3.0+
Signed-off-by: John David Anglin
Signed-off-by: Helge Deller -
Signed-off-by: Helge Deller
-
Signed-off-by: Helge Deller
-
Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
similar to smp_call_function_single()" has unified the way to handle
single and multiple cross-CPU function calls. Now only one interrupt
is needed for architecture specific code to support generic SMP function
call interfaces, so kill the redundant single function call interrupt.Signed-off-by: Jiang Liu
Cc: Jiang Liu
Signed-off-by: Helge Deller -
ERROR: "flush_cache_page" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined!
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Helge Deller -
Pull gcc "asm goto" miscompilation workaround from Ingo Molnar:
"This is the fix for the GCC miscompilation discussed in the following
lkml thread:[x86] BUG: unable to handle kernel paging request at 00740060
The bug in GCC has been fixed by Jakub and the fix will be part of the
GCC 4.8.2 release expected to be released next week - so the quirk's
version test checks for miscompilation bug -
Pull x86 fixes from Ingo Molnar:
"A build fix and a reboot quirk"* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/reboot: Add reboot quirk for Dell Latitude E5410
x86, build, pci: Fix PCI_MSI build on !SMP -
Pull ARC fix from Vineet Gupta:
"Fix for broken gdb 'jump'"* tag 'arc-fixes-for-3.12-part3' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
ARC: Ignore ptrace SETREGSET request for synthetic register "stop_pc"
12 Oct, 2013
2 commits
-
ARCompact TRAP_S insn used for breakpoints, commits before exception is
taken (updating architectural PC). So ptregs->ret contains next-PC and
not the breakpoint PC itself. This is different from other restartable
exceptions such as TLB Miss where ptregs->ret has exact faulting PC.
gdb needs to know exact-PC hence ARC ptrace GETREGSET provides for
@stop_pc which returns ptregs->ret vs. EFA depending on the
situation.However, writing stop_pc (SETREGSET request), which updates ptregs->ret
doesn't makes sense stop_pc doesn't always correspond to that reg as
described above.This was not an issue so far since user_regs->ret / user_regs->stop_pc
had same value and both writing to ptregs->ret was OK, needless, but NOT
broken, hence not observed.With gdb "jump", they diverge, and user_regs->ret updating ptregs is
overwritten immediately with stop_pc, which this patch fixes.Reported-by: Anton Kolesov
Signed-off-by: Vineet Gupta -
Pull MIPS fix from Ralf Baechle:
"Just one fix. The stack protector was loading the value of the canary
instead of its address"* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: stack protector: Fix per-task canary switch
11 Oct, 2013
3 commits
-
Fengguang Wu, Oleg Nesterov and Peter Zijlstra tracked down
a kernel crash to a GCC bug: GCC miscompiles certain 'asm goto'
constructs, as outlined here:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58670
Implement a workaround suggested by Jakub Jelinek.
Reported-and-tested-by: Fengguang Wu
Reported-by: Oleg Nesterov
Reported-by: Peter Zijlstra
Suggested-by: Jakub Jelinek
Reviewed-by: Richard Henderson
Cc: Linus Torvalds
Cc: Andrew Morton
Cc:
Signed-off-by: Ingo Molnar -
Pull kbuild fix from Michal Marek:
"Here is an ARM Makefile fix that you even acked. After nobody wanted
to take it, it ended up in the kbuild tree"* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
arm, kbuild: make "make install" not depend on vmlinux -
Pull kvm fixes from Paolo Bonzini:
"Fixes for 3.12-rc5: two old PPC bugs and one new (3.12-rc2) x86 bug"* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
kvm: ppc: booke: check range page invalidation progress on page setup
KVM: PPC: Book3S HV: Fix typo in saving DSCR
KVM: nVMX: fix shadow on EPT
10 Oct, 2013
4 commits
-
Due to the way kernel is initialized under Xen is possible that the
ring1 selector used by the kernel for the boot cpu end up to be copied
to userspace leading to segmentation fault in the userspace.Xen code in the kernel initialize no-boot cpus with correct selectors (ds
and es set to __USER_DS) but the boot one keep the ring1 (passed by Xen).
On task context switch (switch_to) we assume that ds, es and cs already
point to __USER_DS and __KERNEL_CSso these selector are not changed.If processor is an Intel that support sysenter instruction sysenter/sysexit
is used so ds and es are not restored switching back from kernel to
userspace. In the case the selectors point to a ring1 instead of __USER_DS
the userspace code will crash on first memory access attempt (to be
precise Xen on the emulated iret used to do sysexit will detect and set ds
and es to zero which lead to GPF anyway).Now if an userspace process call kernel using sysenter and get rescheduled
(for me it happen on a specific init calling wait4) could happen that the
ring1 selector is set to ds and es.This is quite hard to detect cause after a while these selectors are fixed
(__USER_DS seems sticky).Bisecting the code commit 7076aada1040de4ed79a5977dbabdb5e5ea5e249 appears
to be the first one that have this issue.Signed-off-by: Frediano Ziglio
Signed-off-by: Stefano Stabellini
Reviewed-by: Andrew Cooper -
When the MM code is invalidating a range of pages, it calls the KVM
kvm_mmu_notifier_invalidate_range_start() notifier function, which calls
kvm_unmap_hva_range(), which arranges to flush all the TLBs for guest pages.
However, the Linux PTEs for the range being flushed are still valid at
that point. We are not supposed to establish any new references to pages
in the range until the ...range_end() notifier gets called.
The PPC-specific KVM code doesn't get any explicit notification of that;
instead, we are supposed to use mmu_notifier_retry() to test whether we
are or have been inside a range flush notifier pair while we have been
referencing a page.This patch calls the mmu_notifier_retry() while mapping the guest
page to ensure we are not referencing a page when in range invalidation.This call is inside a region locked with kvm->mmu_lock, which is the
same lock that is called by the KVM MMU notifier functions, thus
ensuring that no new notification can proceed while we are in the
locked region.Signed-off-by: Bharat Bhushan
Acked-by: Alexander Graf
[Backported to 3.12 - Paolo]
Reviewed-by: Bharat Bhushan
Signed-off-by: Paolo Bonzini -
This fixes a typo in the code that saves the guest DSCR (Data Stream
Control Register) into the kvm_vcpu_arch struct on guest exit. The
effect of the typo was that the DSCR value was saved in the wrong place,
so changes to the DSCR by the guest didn't persist across guest exit
and entry, and some host kernel memory got corrupted.Cc: stable@vger.kernel.org [v3.1+]
Signed-off-by: Paul Mackerras
Acked-by: Alexander Graf
Signed-off-by: Paolo Bonzini -
72f857950f6f19 broke shadow on EPT. This patch reverts it and fixes PAE
on nEPT (which reverted commit fixed) in other way.Shadow on EPT is now broken because while L1 builds shadow page table
for L2 (which is PAE while L2 is in real mode) it never loads L2's
GUEST_PDPTR[0-3]. They do not need to be loaded because without nested
virtualization HW does this during guest entry if EPT is disabled,
but in our case L0 emulates L2's vmentry while EPT is enables, so we
cannot rely on vmcs12->guest_pdptr[0-3] to contain up-to-date values
and need to re-read PDPTEs from L2 memory. This is what kvm_set_cr3()
is doing, but by clearing cache bits during L2 vmentry we drop values
that kvm_set_cr3() read from memory.So why the same code does not work for PAE on nEPT? kvm_set_cr3()
reads pdptes into vcpu->arch.walk_mmu->pdptrs[]. walk_mmu points to
vcpu->arch.nested_mmu while nested guest is running, but ept_load_pdptrs()
uses vcpu->arch.mmu which contain incorrect values. Fix that by using
walk_mmu in ept_(load|save)_pdptrs.Signed-off-by: Gleb Natapov
Reviewed-by: Paolo Bonzini
Tested-by: Paolo Bonzini
Signed-off-by: Paolo Bonzini
09 Oct, 2013
4 commits
-
File drivers/leds/leds-lp55xx-common.c refuse to change led_current sysfs
attribute if value is higher than max_current specified in board file. By default
global C variables are zero, so changing always failed. This patch adding missing
max_current and setting it to max safe value 100 (10 mA).It is unclear which commit exactly caused this regression as the lp5523
driver was broken and was hiding the platform data breakage. Now
the driver is fixed so this should be fixed as well.Signed-off-by: Pali Rohár
Signed-off-by: Joerg Reisenweber
[tony@atomide.com: updated comments to describe regression]
Signed-off-by: Tony Lindgren -
Since dra7 reuses the function 'omap5_realtime_timer_init' in
arch/arm/mach-omap2/board-generic.c as timer init function, it has to be
built for this SoC as well.Signed-off-by: Simon Barth
Signed-off-by: Tony Lindgren -
The wake-up interrupt bit is available on omap3/4/5 processors
unlike what we claim. Without fixing it we cannot use it on
omap3 and the system configured for wake-up events will just
hang on wake-up.Cc: Grygorii Strashko
Cc: Benoît Cousson
Cc: devicetree@vger.kernel.org
Signed-off-by: Tony Lindgren -
SoC family definitions at the moment are reactive to board needs
as a result, beagle-xm would matchup with ti,omap3 which invokes
omap3430_init_early instead of omap3630_init_early. Obviously, this is
the wrong behavior.With clock node dts conversion, we get the following warnings before
system hangs as a result and 3630 based platforms fails to boot
(uart4 clocks are only present in OMAP3630 and not present in
OMAP3430):...
omap_hwmod: uart4: cannot clk_get main_clk uart4_fck
omap_hwmod: uart4: cannot _init_clocksWARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2434
_init+0x6c/0x80()
omap_hwmod: uart4: couldn't init clocks
...WARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: timer12: enabled state can only be entered from
initialized, idle, or disabled state
...WARNING: CPU: 0 PID: 46 at arch/arm/mach-omap2/omap_hwmod.c:2224
_idle+0xd4/0xf8()
omap_hwmod: timer12: idle state can only be entered from enabled stateWARNING: CPU: 0 PID: 1 at arch/arm/mach-omap2/omap_hwmod.c:2126
_enable+0x254/0x280()
omap_hwmod: uart4: enabled state can only be entered from
initialized, idle, or disabled stateSo, add specific compatiblity for 3630 to allow match for Beagle-XM
platform.Signed-off-by: Nishanth Menon
[tony@atomide.com: left out ti,omap343x, updated comments]
Signed-off-by: Tony Lindgren
