- 28 5月, 2014 2 次提交
-
-
由 Srivatsa S. Bhat 提交于
If we try to perform a kexec when the machine is in ST (Single-Threaded) mode (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we get the following messages during boot: [ 0.089866] POWER8 performance monitor hardware support registered [ 0.089985] power8-pmu: PMAO restore workaround active. [ 5.095419] Processor 1 is stuck. [ 10.097933] Processor 2 is stuck. [ 15.100480] Processor 3 is stuck. [ 20.102982] Processor 4 is stuck. [ 25.105489] Processor 5 is stuck. [ 30.108005] Processor 6 is stuck. [ 35.110518] Processor 7 is stuck. [ 40.113369] Processor 9 is stuck. [ 45.115879] Processor 10 is stuck. [ 50.118389] Processor 11 is stuck. [ 55.120904] Processor 12 is stuck. [ 60.123425] Processor 13 is stuck. [ 65.125970] Processor 14 is stuck. [ 70.128495] Processor 15 is stuck. [ 75.131316] Processor 17 is stuck. Note that only the sibling threads are stuck, while the primary threads (0, 8, 16 etc) boot just fine. Looking closer at the previous step of kexec, we observe that kexec tries to wakeup (bring online) the sibling threads of all the cores, before performing kexec: [ 9464.131231] Starting new kernel [ 9464.148507] kexec: Waking offline cpu 1. [ 9464.148552] kexec: Waking offline cpu 2. [ 9464.148600] kexec: Waking offline cpu 3. [ 9464.148636] kexec: Waking offline cpu 4. [ 9464.148671] kexec: Waking offline cpu 5. [ 9464.148708] kexec: Waking offline cpu 6. [ 9464.148743] kexec: Waking offline cpu 7. [ 9464.148779] kexec: Waking offline cpu 9. [ 9464.148815] kexec: Waking offline cpu 10. [ 9464.148851] kexec: Waking offline cpu 11. [ 9464.148887] kexec: Waking offline cpu 12. [ 9464.148922] kexec: Waking offline cpu 13. [ 9464.148958] kexec: Waking offline cpu 14. [ 9464.148994] kexec: Waking offline cpu 15. [ 9464.149030] kexec: Waking offline cpu 17. Instrumenting this piece of code revealed that the cpu_up() operation actually fails with -EBUSY. Thus, only the primary threads of all the cores are online during kexec, and hence this is a sure-shot receipe for disaster, as explained in commit e8e5c215 (powerpc/kexec: Fix orphaned offline CPUs across kexec), as well as in the comment above wake_offline_cpus(). It turns out that cpu_up() was returning -EBUSY because the variable 'cpu_hotplug_disabled' was set to 1; and this disabling of CPU hotplug was done by migrate_to_reboot_cpu() inside kernel_kexec(). Now, migrate_to_reboot_cpu() was originally written with the assumption that any further code will not need to perform CPU hotplug, since we are anyway in the reboot path. However, kexec is clearly not such a case, since we depend on onlining CPUs, atleast on powerpc. So re-enable cpu-hotplug after returning from migrate_to_reboot_cpu() in the kexec path, to fix this regression in kexec on powerpc. Also, wrap the cpu_up() in powerpc kexec code within a WARN_ON(), so that we can catch such issues more easily in the future. Fixes: c97102ba (kexec: migrate to reboot cpu) Cc: stable@vger.kernel.org Signed-off-by: NSrivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
由 Guenter Roeck 提交于
With binutils 2.24, various 64 bit builds fail with relocation errors such as arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x165ee): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o arch/powerpc/kernel/built-in.o: In function `exc_debug_crit_book3e': (.text+0x16602): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o The assembler maintainer says: I changed the ABI, something that had to be done but unfortunately happens to break the booke kernel code. When building up a 64-bit value with lis, ori, shl, oris, ori or similar sequences, you now should use @high and @higha in place of @h and @ha. @h and @ha (and their associated relocs R_PPC64_ADDR16_HI and R_PPC64_ADDR16_HA) now report overflow if the value is out of 32-bit signed range. ie. @h and @ha assume you're building a 32-bit value. This is needed to report out-of-range -mcmodel=medium toc pointer offsets in @toc@h and @toc@ha expressions, and for consistency I did the same for all other @h and @ha relocs. Replacing @h with @high in one strategic location fixes the relocation errors. This has to be done conditionally since the assembler either supports @h or @high but not both. Cc: <stable@vger.kernel.org> Signed-off-by: NGuenter Roeck <linux@roeck-us.net> Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 24 5月, 2014 2 次提交
-
-
由 Alexandre Courbot 提交于
The setup_max_cpus variable is only defined if CONFIG_SMP is set. Add a preprocessor condition to avoid the following compilation error if CONFIG_SMP is not set: arch/arm/include/asm/trusted_foundations.h: In function 'register_trusted_foundations': arch/arm/include/asm/trusted_foundations.h:57:2: error: 'setup_max_cpus' undeclared (first use in this function) Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com> Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk> Acked-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Linus Torvalds 提交于
The 'renameat2()' system call was incorrectly added as a ENTRY_COMP() in the parisc system call table by commit 18e480aa ("parisc: add renameat2 syscall"). That causes a link-time error due to there not being any compat version of that system call: arch/parisc/kernel/built-in.o: In function `sys_call_table': (.rodata+0xad0): undefined reference to `compat_sys_renameat2' make: *** [vmlinux] Error 1 Easily fixed by marking the system call as being the same for compat as for native by using ENTRY_SAME() instead of ENTRY_COMP(). Reported-by: NGuenter Roeck <linux@roeck-us.net> Acked-by: NMiklos Szeredi <miklos@szeredi.hu> Acked-by: NHelge Deller <deller@gmx.de> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 23 5月, 2014 1 次提交
-
-
由 Alexandre Belloni 提交于
Use the hexadecimal values for the triggers to match what is done for the device tree. This also fixes compilation issues as the defines have been moved elsewhere. Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
-
- 22 5月, 2014 3 次提交
-
-
由 Thomas Petazzoni 提交于
Due a copy/paste error, the 'reg' values for the third PCIe interface on Armada 380, and the third and fourth PCIe interfaces on Armada 385 are wrong: they are equal to the one of the second PCIe interface. This patch fixes this by using the appropriate 'reg' values for those PCIe interfaces. Without this fix, the third and fourth PCIe interfaces are unusable on those platforms. Reported-by: NNadav Haklai <nadavh@marvell.com> Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Link: https://lkml.kernel.org/r/1400597008-4148-1-git-send-email-thomas.petazzoni@free-electrons.com Fixes: 0d3d96ab ("ARM: mvebu: add Device Tree description of the Armada 380/385 SoCs") Signed-off-by: NJason Cooper <jason@lakedaemon.net>
-
由 Emil Goode 提交于
If we fail to allocate struct platform_device pdev we dereference it after the goto label err. This bug was found using coccinelle. Fixes: afa77ef3 (ARM: mx3: dynamically allocate "ipu-core" devices) Signed-off-by: NEmil Goode <emilgoode@gmail.com> Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: <stable@vger.kernel.org> Signed-off-by: NShawn Guo <shawn.guo@freescale.com> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
由 Toralf Förster 提交于
found by cppcheck Signed-off-by: NToralf Förster <toralf.foerster@gmx.de> Acked-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 20 5月, 2014 7 次提交
-
-
由 Miklos Szeredi 提交于
Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz> Acked-by: NTony Luck <tony.luck@intel.com>
-
由 Miklos Szeredi 提交于
Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz> Acked-by: NHelge Deller <deller@gmx.de>
-
由 Miklos Szeredi 提交于
Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz> Acked-by: NGeert Uytterhoeven <geert@linux-m68k.org>
-
由 Santosh Shilimkar 提交于
On OMAP4 panda board, there have been several bug reports about boot hang and lock-ups with CPU_IDLE enabled. The root cause of the issue is missing interrupts while in idle state. Commit cb7094e8 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag} moved the broadcast notifiers to common code for right reasons but on OMAP4 which suffers from a nasty ROM code bug with GIC, commit ff999b8a {ARM: OMAP4460: Workaround for ROM bug ..}, we loose interrupts which leads to issues like lock-up, hangs etc. Patch reverts commit cb7094 {cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag} and 54769d65 {cpuidle: OMAP4: remove timer broadcast initialization} to avoid the issue. With this change, OMAP4 panda boards, the mentioned issues are getting fixed. We no longer loose interrupts which was the cause of the regression. Fixes: cb7094e8 (cpuidle / omap4 : use CPUIDLE_FLAG_TIMER_STOP flag) Fixes: ff999b8a (cpuidle: OMAP4: remove timer broadcast initialization) Cc: stable@vger.kernel.org # v3.9+ Cc: Roger Quadros <rogerq@ti.com> Cc: Kevin Hilman <khilman@linaro.org> Cc: Tony Lindgren <tony@atomide.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Reported-tested-by: NRoger Quadros <rogerq@ti.com> Reported-tested-by: NKevin Hilman <khilman@linaro.org> Tested-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Sachin Kamat 提交于
LDO4 regulator was getting disabled preventing the system from going into low power states. Keep it always on to fix it. Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Sachin Kamat 提交于
Updated as per the user manual. Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Beomho Seo 提交于
This patch fixed incorrect compatible for ak8975 magnetic sensor. ak8975 magnetic sensor use compatible "ak8975" or "asahi-kasei,ak8975" In this patch, use "asahi-kasei,ak8975" according to dt bindings document. Signed-off-by: NBeomho Seo <beomho.seo@samsung.com> Signed-off-by: NMyungJoo Ham <myungjoo.ham@samsung.com> Reviewed-by: NTomasz Figa <t.figa@samsung.com> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
- 18 5月, 2014 1 次提交
-
-
由 David S. Miller 提交于
This is the prevent previous stores from overlapping the block stores done by the memcpy loop. Based upon a glibc patch by Jose E. Marchesi Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 17 5月, 2014 3 次提交
-
-
由 Tony Lindgren 提交于
Commit 6ddeb6d8 (dmaengine: omap-dma: move IRQ handling to omap-dma) added support for handling interrupts in the omap dmaengine driver instead of the legacy driver. Because of different handling for interrupts this however caused omap3 to hang eventually after hitting off-idle. Any of the virtual 32 DMA channels can be assigned to any of the four DMA interrupts. So commit 6ddeb6d8 made the omap dmaengine driver to use the second DMA interrupt while keeping the legacy code still using the first DMA interrupt. This means we need to save and restore both IRQENABLE_L1 in addition to IRQENABLE_L0. As there is a chance that the DSP might be using IRQENABLE_L2 or IRQENABLE_L3 lines, let's not touch those until this has been confirmed. Let's just add a comment to the code for now. Fixes: 6ddeb6d8 (dmaengine: omap-dma: move IRQ handling to omap-dma) Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Roger Quadros 提交于
Commit c66d0391 broke NAND for non-DT boot on all OMAP2 and OMAP3 boards using board_nand_init(). Following error is seen at boot [ 0.154998] (null): Unsupported NAND ECC scheme selected For OMAP2 and OMAP3 platforms, the ecc_opt parameter in platform data must be set to OMAP_ECC_HAM1_CODE_HW to work properly. Tested on omap3-beagle c4. Fixes: c66d0391 (mtd: nand: omap: combine different flavours of 1-bit hamming ecc schemes) Cc: stable@vger.kernel.org # v3.12+ Signed-off-by: NRoger Quadros <rogerq@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Mark Salter 提交于
The following happens when trying to run a kvm guest on a kernel configured for 64k pages. This doesn't happen with 4k pages: BUG: failure at include/linux/mm.h:297/put_page_testzero()! Kernel panic - not syncing: BUG! CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF 3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1 Call trace: [<fffffe0000096034>] dump_backtrace+0x0/0x16c [<fffffe00000961b4>] show_stack+0x14/0x1c [<fffffe000066e648>] dump_stack+0x84/0xb0 [<fffffe0000668678>] panic+0xf4/0x220 [<fffffe000018ec78>] free_reserved_area+0x0/0x110 [<fffffe000018edd8>] free_pages+0x50/0x88 [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40 [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44 [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184 [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c [<fffffe00001edc1c>] __fput+0xb0/0x288 [<fffffe00001ede4c>] ____fput+0xc/0x14 [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c [<fffffe0000095c14>] do_notify_resume+0x54/0x58 In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page() on the stage2 pgd which leads to the BUG in put_page_testzero(). This happens because a pud_huge() test in unmap_range() returns true when it should always be false with 2-level pages tables used by 64k pages. This patch removes support for huge puds if 2-level pagetables are being used. Signed-off-by: NMark Salter <msalter@redhat.com> [catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check] Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com> Cc: <stable@vger.kernel.org> # v3.11+
-
- 16 5月, 2014 4 次提交
-
-
由 Leif Lindholm 提交于
A few platforms lack a 'device_type = "memory"' for their memory nodes, relying on an old ppc quirk in order to discover its memory. Add the missing data so that all parsing code can find memory nodes correctly. Signed-off-by: NLeif Lindholm <leif.lindholm@linaro.org> Cc: linux-mips@linux-mips.org Cc: devicetree@vger.kernel.org Cc: Mark Rutland <mark.rutland@arm.com> Cc: <stable@vger.kernel.org> Acked-by: NJohn Crispin <blogic@openwrt.org> Signed-off-by: NGrant Likely <grant.likely@linaro.org>
-
由 Leif Lindholm 提交于
The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for its memory node, relying on an old ppc quirk in order to discover its memory. Fix the data so that all parsing code can handle it correctly. Signed-off-by: NLeif Lindholm <leif.lindholm@linaro.org> Acked-by: NLee Jones <lee.jones@linaro.org> Acked-by: NLinus Walleij <linus.walleij@linaro.org> Cc: linux-arm-kernel@lists.infradead.org Cc: devicetree@vger.kernel.org Cc: Mark Rutland <mark.rutland@arm.com> Cc: <stable@vger.kernel.org> Signed-off-by: NGrant Likely <grant.likely@linaro.org>
-
由 John David Anglin 提交于
The attached change significantly improves the performance of the LWS-CAS code in syscall.S. This allows a number of packages to build (e.g., zeromq3, gtest and libxs) that previously failed because slow LWS-CAS performance under contention. In particular, interrupts taken while the lock was taken degraded performance significantly. The change does the following: 1) Disables interrupts around the CAS operation, and 2) Changes the loads and stores to use the ordered completer, "o", on PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is accepted on both PA 1.X and 2.0. The use of ordered loads and stores probably makes no difference on all existing hardware, but it seemed pedantically correct. In particular, the CAS operation must complete before LDCW lock is released. As written before, a processor could reorder the operations. I don't believe the period interrupts are disabled is long enough to significantly increase interrupt latency. For example, the TLB insert code is longer. Worst case is a memory fault in the CAS operation. Signed-off-by: NJohn David Anglin <dave.anglin@bell.net> Cc: stable@vger.kernel.org # 3.13+ Signed-off-by: NHelge Deller <deller@gmx.de>
-
由 Helge Deller 提交于
Ratelimit printing of userspace segfaults and make it runtime configurable via the /proc/sys/debug/exception-trace variable. This should resolve syslog from growing way too fast and thus prevents possible system service attacks. Signed-off-by: NHelge Deller <deller@gmx.de> Cc: stable@vger.kernel.org # 3.13+
-
- 15 5月, 2014 13 次提交
-
-
由 Linus Torvalds 提交于
Checkin: b3b42ac2 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels disabled 16-bit segments on 64-bit kernels due to an information leak. However, it does seem that people are genuinely using Wine to run old 16-bit Windows programs on Linux. A proper fix for this ("espfix64") is coming in the upcoming merge window, but as a temporary fix, create a sysctl to allow the administrator to re-enable support for 16-bit segments. It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If you hit this issue and care about your old Windows program more than you care about a kernel stack address information leak, you can do echo 1 > /proc/sys/abi/ldt16 as root (add it to your startup scripts), and you should be ok. The sysctl table is only added if you have COMPAT support enabled on x86-64, but I assume anybody who runs old windows binaries very much does that ;) Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com Cc: <stable@vger.kernel.org>
-
由 James Hogan 提交于
Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to 256MB, apparently in an attempt to prevent setup_arg_pages's STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is far too large for Meta's limited virtual address space and hits a BUG_ON (stack_top is usually 0x3ffff000). However the commit "metag: Reduce maximum stack size to 256MB" reduces the absolute stack size limit to a safe value for metag. This allows the default _STK_LIM_MAX override to be removed, bringing the default behaviour in line with all other architectures. Parisc in particular recently removed their override of _STK_LIMT_MAX in commit e0d8898d (parisc: remove _STK_LIM_MAX override) since it subtly affects stack allocation semantics in userland. Meta's uapi/asm/resource.h can now be removed and switch to using generic-y. Suggested-by: NHelge Deller <deller@gmx.de> Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Cc: linux-metag@vger.kernel.org Cc: John David Anglin <dave.anglin@bell.net>
-
由 Helge Deller 提交于
This patch affects only architectures where the stack grows upwards (currently parisc and metag only). On those do not hardcode the maximum initial stack size to 1GB for 32-bit processes, but make it configurable via a config option. The main problem with the hardcoded stack size is, that we have two memory regions which grow upwards: stack and heap. To keep most of the memory available for heap in a flexmap memory layout, it makes no sense to hard allocate up to 1GB of the memory for stack which can't be used as heap then. This patch makes the stack size for 32-bit processes configurable and uses 80MB as default value which has been in use during the last few years on parisc and which hasn't showed any problems yet. Signed-off-by: NHelge Deller <deller@gmx.de> Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: linux-parisc@vger.kernel.org Cc: linux-metag@vger.kernel.org Cc: John David Anglin <dave.anglin@bell.net>
-
由 James Hogan 提交于
Specify the maximum stack size for arches where the stack grows upward (parisc and metag) in asm/processor.h rather than hard coding in fs/exec.c so that metag can specify a smaller value of 256MB rather than 1GB. This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased beyond a safe value by root. E.g. when starting a process after running "ulimit -H -s unlimited" it will then attempt to use a stack size of the maximum 1GB which is far too big for metag's limited user virtual address space (stack_top is usually 0x3ffff000): BUG: failure at fs/exec.c:589/shift_arg_pages()! Signed-off-by: NJames Hogan <james.hogan@imgtec.com> Cc: Helge Deller <deller@gmx.de> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: linux-parisc@vger.kernel.org Cc: linux-metag@vger.kernel.org Cc: John David Anglin <dave.anglin@bell.net> Cc: stable@vger.kernel.org # only needed for >= v3.9 (arch/metag)
-
由 Mikulas Patocka 提交于
Volatile access doesn't really imply the compiler barrier. Volatile access is only ordered with respect to other volatile accesses, it isn't ordered with respect to general memory accesses. Gcc may reorder memory accesses around volatile access, as we can see in this simple example (if we compile it with optimization, both increments of *b will be collapsed to just one): void fn(volatile int *a, long *b) { (*b)++; *a = 10; (*b)++; } Consequently, we need the compiler barrier after a write to the volatile variable, to make sure that the compiler doesn't reorder the volatile write with something else. Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Acked-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
-
由 Heiko Carstens 提交于
This is the s390 variant of Alexei's JIT bug fix. (patch description below stolen from Alexei's patch) bpf_alloc_binary() adds 128 bytes of room to JITed program image and rounds it up to the nearest page size. If image size is close to page size (like 4000), it is rounded to two pages: round_up(4000 + 4 + 128) == 8192 then 'hole' is computed as 8192 - (4000 + 4) = 4188 If prandom_u32() % hole selects a number >= PAGE_SIZE - sizeof(*header) then kernel will crash during bpf_jit_free(): kernel BUG at arch/x86/mm/pageattr.c:887! Call Trace: [<ffffffff81037285>] change_page_attr_set_clr+0x135/0x460 [<ffffffff81694cc0>] ? _raw_spin_unlock_irq+0x30/0x50 [<ffffffff810378ff>] set_memory_rw+0x2f/0x40 [<ffffffffa01a0d8d>] bpf_jit_free_deferred+0x2d/0x60 [<ffffffff8106bf98>] process_one_work+0x1d8/0x6a0 [<ffffffff8106bf38>] ? process_one_work+0x178/0x6a0 [<ffffffff8106c90c>] worker_thread+0x11c/0x370 since bpf_jit_free() does: unsigned long addr = (unsigned long)fp->bpf_func & PAGE_MASK; struct bpf_binary_header *header = (void *)addr; to compute start address of 'bpf_binary_header' and header->pages will pass junk to: set_memory_rw(addr, header->pages); Fix it by making sure that &header->image[prandom_u32() % hole] and &header are in the same page. Fixes: aa2d2c73 ("s390/bpf,jit: address randomize and write protect jit code") Reported-by: NAlexei Starovoitov <ast@plumgrid.com> Cc: <stable@vger.kernel.org> # v3.11+ Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
由 Arun Kumar K 提交于
G2D power domain also controls the CMU block of G2D. Since clock registers can be accessed anytime for viewing clk_summary, it can cause a system crash if g2d power domain is disabled. Signed-off-by: NArun Kumar K <arun.kk@samsung.com> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Tushar Behera 提交于
MAU powerdomain provides clocks for Audio sub-system block. This block comprises of the I2S audio controller, audio DMA blocks and Audio sub-system clock registers. Right now, there is no way to hook up power-domains with clock providers. During late boot when this power-domain gets disabled, we get following external abort. Unhandled fault: imprecise external abort (0x1406) at 0x00000000 Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000007 Signed-off-by: NTushar Behera <tushar.behera@linaro.org> Tested-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Sachin Kamat 提交于
High speed I2C is used on Exynos5 based SoCs. Enable it. The MMC partition for Root filesystem cannot be mounted without this enabling HS-I2C and regulators on many boards are connected HS-I2C bus so the regulators don't come by default without this. Actually, we are not able to get arndale-octa board to boot and mount an MMC partition without this change. Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org> Tested-by: NJavi Merino <javi.merino@arm.com> [kgene.kim@samsung.com: modified description] Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Seungwon Jeon 提交于
This change places MDMA1 in disabled node for Exynos5420. If MDMA1 region is configured with secure mode, it makes the boot failure with the following on smdk5420 board. ("Unhandled fault: imprecise external abort (0x1406) at 0x00000000") Thus, arndale-octa board don't need to do the same thing anymore. Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com> Tested-by: NJavi Merino <javi.merino@arm.com> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Kyungmin Park 提交于
This patch fixes the offset of CPU boot address and changes the parameter of smc call for SMC_CMD_CPU1BOOT command on exynos4212. Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com> Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com> Reviewed-by: NTomasz Figa <t.figa@samsung.com> Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
-
由 Peter Ujfalusi 提交于
McPDM need to be configured to NO_IDLE mode when it is in used otherwise vital clocks will be gated which results 'slow motion' audio playback. Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com> Cc: <stable@kernel.org> Signed-off-by: NPaul Walmsley <paul@pwsan.com>
-
由 Steven J. Hill 提交于
Commit f4ae17aa [MIPS: mm: Use scratch for PGD when !CONFIG_MIPS_PGD_C0_CONTEXT] broke microMIPS kernel builds. This patch refactors that code similar to what was done for the 'clear_page' and 'copy_page' functions. Signed-off-by: NSteven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/6744/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
- 14 5月, 2014 3 次提交
-
-
由 Markos Chandras 提交于
A MIPS64 kernel may support ELF files for all 3 MIPS ABIs (O32, N32, N64). Furthermore, the AUDIT_ARCH_MIPS{,EL}64 token does not provide enough information about the ABI for the 64-bit process. As a result of which, userland needs to use complex seccomp filters to decide whether a syscall belongs to the o32 or n32 or n64 ABI. Therefore, a new arch token for MIPS64/n32 is added so it can be used by seccomp to explicitely set syscall filters for this ABI. Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com> Acked-by: NEric Paris <eparis@redhat.com> Acked-by: NPaul Moore <pmoore@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: linux-mips@linux-mips.org Link: http://sourceforge.net/p/libseccomp/mailman/message/32239040/ Patchwork: https://patchwork.linux-mips.org/patch/6818/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-
由 Anthony Iliopoulos 提交于
The invalidation is required in order to maintain proper semantics under CoW conditions. In scenarios where a process clones several threads, a thread operating on a core whose DTLB entry for a particular hugepage has not been invalidated, will be reading from the hugepage that belongs to the forked child process, even after hugetlb_cow(). The thread will not see the updated page as long as the stale DTLB entry remains cached, the thread attempts to write into the page, the child process exits, or the thread gets migrated to a different processor. Signed-off-by: NAnthony Iliopoulos <anthony.iliopoulos@huawei.com> Link: http://lkml.kernel.org/r/20140514092948.GA17391@server-36.huawei.corpSuggested-by: NShay Goikhman <shay.goikhman@huawei.com> Acked-by: NDave Hansen <dave.hansen@intel.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com> Cc: <stable@vger.kernel.org> # v2.6.16+ (!)
-
由 Alexei Starovoitov 提交于
bpf_alloc_binary() adds 128 bytes of room to JITed program image and rounds it up to the nearest page size. If image size is close to page size (like 4000), it is rounded to two pages: round_up(4000 + 4 + 128) == 8192 then 'hole' is computed as 8192 - (4000 + 4) = 4188 If prandom_u32() % hole selects a number >= PAGE_SIZE - sizeof(*header) then kernel will crash during bpf_jit_free(): kernel BUG at arch/x86/mm/pageattr.c:887! Call Trace: [<ffffffff81037285>] change_page_attr_set_clr+0x135/0x460 [<ffffffff81694cc0>] ? _raw_spin_unlock_irq+0x30/0x50 [<ffffffff810378ff>] set_memory_rw+0x2f/0x40 [<ffffffffa01a0d8d>] bpf_jit_free_deferred+0x2d/0x60 [<ffffffff8106bf98>] process_one_work+0x1d8/0x6a0 [<ffffffff8106bf38>] ? process_one_work+0x178/0x6a0 [<ffffffff8106c90c>] worker_thread+0x11c/0x370 since bpf_jit_free() does: unsigned long addr = (unsigned long)fp->bpf_func & PAGE_MASK; struct bpf_binary_header *header = (void *)addr; to compute start address of 'bpf_binary_header' and header->pages will pass junk to: set_memory_rw(addr, header->pages); Fix it by making sure that &header->image[prandom_u32() % hole] and &header are in the same page Fixes: 314beb9b ("x86: bpf_jit_comp: secure bpf jit against spraying attacks") Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com> Acked-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 13 5月, 2014 1 次提交
-
-
由 Ralf Baechle 提交于
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
-