- 18 7月, 2014 18 次提交
-
-
由 Shawn Guo 提交于
Add revision info for PL310_ERRATA_588369 and PL310_ERRATA_727915 to help people understand if they need to enable the errata for their hardware. Signed-off-by: NShawn Guo <shawn.guo@freescale.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Shawn Guo 提交于
Since pj4b suspend/resume routines are implemented based on generic ARMv7 ones, instead of hard-coding cpu_pj4b_suspend_size, we should have it be cpu_v7_suspend_size plus pj4b specific bytes. Otherwise, if cpu_v7_suspend_size gets updated alone, the pj4b suspend/resume will likely be broken. While at it, fix the comments in cpu_pj4b_do_resume, as we're restoring CP15 registers rather than saving in there. Signed-off-by: NShawn Guo <shawn.guo@freescale.com> Acked-by: NGregory CLEMENT <gregory.clement@free-electrons.com> Tested-by: NGregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Mark Rutland 提交于
Commit 78d7530a ("ARM: Clean up linker script using new linker script macros.") modified the arm kernel linker script to use the STABS_DEBUG macro, but left a .comment section definition. As STABS_DEBUG defines the .comment section in an identical way, the second section definition is redundant and can be removed. This patch removes the redundant .comment section definition. Signed-off-by: NMark Rutland <mark.rutland@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nikolay Borisov 提交于
Use the newly introduced API so that FP is correctly referenced from either R7/R11 based on whether we are running in THUMB2 mode or not. Signed-off-by: NNikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: NWill Deacon <will.deacon@arm.com> Acked-by: NRobert Richter <rric@kernel.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nikolay Borisov 提交于
Use the newly-introduced frame_pointer macro to extract the correct FP based on whether we are in THUMB2 mode or not. Signed-off-by: NNikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nikolay Borisov 提交于
Make the unwind code use the correct API so that the frame pointer is extracted from the correct register. Signed-off-by: NNikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nikolay Borisov 提交于
Make use of the arm_get_current_stackframe api so that the frame pointer is correctly referenced in THUMB2 mode Signed-off-by: NNikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nikolay Borisov 提交于
Make the perf backend use the API so that it correctly references the FP when in THUMB2 mode Signed-off-by: NNikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nikolay Borisov 提交于
Currently there are numerous places where "struct pt_regs" are used to populate "struct stackframe", however all of those location do not consider the situation where the kernel might be compiled in THUMB2 mode, in which case the framepointer member of pt_regs become ARM_r7 instead of ARM_fp (r11). Document this idiosyncracy in the definition of "struct stackframe" The easiest solution is to introduce a new function (in the spirit of https://groups.google.com/forum/#!topic/linux.kernel/dA2YuUcSpZ4) which would hide the complexity of initializing the stackframe struct from pt_regs. Also implement a macro frame_pointer(regs) that would return the correct register so that we can use it in cases where we just require the frame pointer and not a whole struct stackframe Signed-off-by: NNikolay Borisov <Nikolay.Borisov@arm.com> Acked-by: NWill Deacon <will.deacon@arm.com> Acked-by: NRobert Richter <rric@kernel.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nicolas Pitre 提交于
With patch #8067/1 ("zImage: ensure header in LE format for BE8 kernels") applied, it is no longer possible to determine the endianness of a compiled kernel image. This normally shouldn't matter to the boot environment, except for those cases where the selection of a ramdisk or root filesystem with a matching endianness has to be automated. Let's add a flag to the zImage header indicating the actual endianness. Four bytes from offset 0x30 can be interpreted as follows: 04 03 02 01 big endian kernel 01 02 03 04 little endian kernel Anything else should be interpreted as "unknown", in which case it is most likely that patch #8067/1 was not applied either and the zImage magic number at offset 0x24 could be used instead to determine endianness. No zImage before this patch ever produced 0x01020304 nor 0x04030201 at offset 0x30 so there is no confusion possible. Signed-off-by: NNicolas Pitre <nico@linaro.org> Acked-by: NKevin Hilman <khilman@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Save and report (via the procfs file) the last kernel unaligned fault location. This allows us to trivially inspect where the last fault happened for cases which we don't expect to occur. Since we expect the kernel to generate misalignment faults (due to the networking layer), even when warnings are enabled, we don't log them for the kernel. Tested-by: NTony Lindgren <tony@atomide.com> Acked-by: NCatalin Marinas <catalin.marinas@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
ARMv6 and greater introduced a new instruction ("bx") which can be used to return from function calls. Recent CPUs perform better when the "bx lr" instruction is used rather than the "mov pc, lr" instruction, and this sequence is strongly recommended to be used by the ARM architecture manual (section A.4.1.1). We provide a new macro "ret" with all its variants for the condition code which will resolve to the appropriate instruction. Rather than doing this piecemeal, and miss some instances, change all the "mov pc" instances to use the new macro, with the exception of the "movs" instruction and the kprobes code. This allows us to detect the "mov pc, lr" case and fix it up - and also gives us the possibility of deploying this for other registers depending on the CPU selection. Reported-by: NWill Deacon <will.deacon@arm.com> Tested-by: Stephen Warren <swarren@nvidia.com> # Tegra Jetson TK1 Tested-by: Robert Jarzmik <robert.jarzmik@free.fr> # mioa701_bootresume.S Tested-by: Andrew Lunn <andrew@lunn.ch> # Kirkwood Tested-by: NShawn Guo <shawn.guo@freescale.com> Tested-by: Tony Lindgren <tony@atomide.com> # OMAPs Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> # Armada XP, 375, 385 Acked-by: Sekhar Nori <nsekhar@ti.com> # DaVinci Acked-by: Christoffer Dall <christoffer.dall@linaro.org> # kvm/hyp Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com> # PXA3xx Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> # Xen Tested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> # ARMv7M Tested-by: Simon Horman <horms+renesas@verge.net.au> # Shmobile Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
Ensure that platform maintainers check the CPU part number in the right manner: the CPU part number is meaningless without also checking the CPU implement(e|o)r (choose your preferred spelling!) Provide an interface which returns both the implementer and part number together, and update the definitions to include the implementer. Mark the old function as being deprecated... indeed, using the old function with the definitions will now always evaluate as false, so people must update their un-merged code to the new function. While this could be avoided by adding new definitions, we'd also have to create new names for them which would be awkward. Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Krzysztof Kozlowski 提交于
Building of EXYNOS5420_MCPM with disabled SUSPEND fails: arch/arm/mach-exynos/built-in.o: In function `exynos_mcpm_init': arch/arm/mach-exynos/mcpm-exynos.c:361: undefined reference to `mcpm_loopback' The exynos_mcpm_init() in mcp-exynos.c calls mcpm_loopback() which depends on cpu_suspend function (ARM_CPU_SUSPEND). Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nicolas Pitre 提交于
The Chromebook firmware doesn't enable the CCI for the boot cpu, and arguably it shouldn't have to either. Let's have the kernel handle the CCI on its own for the boot CPU the same way it does it for secondary CPUs by using the MCPM loopback. This allows to boot all 8 cores on exynos5420-peach-pit, exynos5800-peach-pi and ARM Chromebook 2. Signed-off-by: NNicolas Pitre <nico@linaro.org> Tested-by: NTushar Behera <tushar.b@samsung.com> Reviewed-by: NKevin Hilman <khilman@linaro.org> Tested-by: NKevin Hilman <khilman@linaro.org> Tested-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nicolas Pitre 提交于
This is not strictly needed on TC2 but still a good idea to exercise that code. Signed-off-by: Nnicolas Pitre <nico@linaro.org> Reviewed-by: NKevin Hilman <khilman@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nicolas Pitre 提交于
The kernel already has the responsibility to handle resources such as the CCI when hotplugging CPUs, during the booting of secondary CPUs, and when resuming from suspend/idle. It would be more coherent and less confusing if the CCI for the boot CPU (or cluster) was also initialized by the kernel rather than expecting the firmware/bootloader to do it and only in that case. After all, the kernel has all the necessary code already and the bootloader shouldn't have to care at all. The CCI may be turned on only when the cache is off. Leveraging the CPU suspend code to loop back through the low-level MCPM entry point is all that is needed to properly turn on the CCI from the kernel by using the same code as during secondary boot. Let's provide a generic MCPM loopback function that can be invoked by backend initialization code to set things (CCI or similar) on the boot CPU just as it is done for the other CPUs. Signed-off-by: NNicolas Pitre <nico@linaro.org> Reviewed-by: NKevin Hilman <khilman@linaro.org> Tested-by: NKevin Hilman <khilman@linaro.org> Tested-by: NDoug Anderson <dianders@chromium.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Arnd Bergmann 提交于
After applying patch: "ARM: 8078/1: get rid of hardcoded assumptions about kernel stack size" following build failure happens on iop13xx platform: In file included from include/linux/srcu.h:33:0, from include/linux/notifier.h:15, from include/linux/reboot.h:5, from arch/arm/mach-iop13xx/include/mach/iop13xx.h:6, from arch/arm/mach-iop13xx/include/mach/hardware.h:14, from arch/arm/mach-iop13xx/include/mach/memory.h:4, from arch/arm/include/asm/memory.h:24, from arch/arm/include/asm/page.h:163, from arch/arm/include/asm/thread_info.h:17, from include/linux/thread_info.h:54, from include/asm-generic/preempt.h:4, from arch/arm/include/generated/asm/preempt.h:1, from include/linux/preempt.h:18, from include/linux/spinlock.h:50, from include/linux/seqlock.h:35, from include/linux/time.h:5, from include/uapi/linux/timex.h:56, from include/linux/timex.h:56, from include/linux/sched.h:19, from arch/arm/kernel/asm-offsets.c:13: include/linux/rcupdate.h: In function '__rcu_read_lock': >> include/linux/rcupdate.h:220:2: error: implicit declaration of function 'preempt_disable' [-Werror=implicit-function-declaration] preempt_disable(); The problem here is recursive header inclusion which could be avoided by removing linux/reboot.h from mach/iop13xxx.h. linux/reboot.h in include/mach/iop13xx.h is needed only for enum reboot_mode, so header it could be replaced with a enum declaration. Whatever patch "ARM: 8078/1: get rid of hardcoded assumptions about kernel stack size" does, I think it's good to avoid unnecessary header inclusion here in any case. Reported-by: Nkbuild test robot <fengguang.wu@intel.com> Reported-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 01 7月, 2014 4 次提交
-
-
由 Andrey Ryabinin 提交于
Changing kernel stack size on arm is not as simple as it should be: 1) THREAD_SIZE macro doesn't respect PAGE_SIZE and THREAD_SIZE_ORDER 2) stack size is hardcoded in get_thread_info macro This patch fixes it by calculating THREAD_SIZE and thread_info address taking into account PAGE_SIZE and THREAD_SIZE_ORDER. Now changing stack size becomes simply changing THREAD_SIZE_ORDER. Signed-off-by: NAndrey Ryabinin <a.ryabinin@samsung.com> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
As we are now using the C preprocessor, we do not need to use sed to edit constants in this file, and then pass the resulting file through the C preprocessor. Instead, rely solely on the C preprocessor to rewrite TEXT_START and BSS_ADDR. Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nicolas Pitre 提交于
All known BE8-capable systems have LE bootloaders, so we need to ensure that the magic number and image start/end values are in little endian format. [ben.dooks@codethink.co.uk: from nico's original email on this subject] [taras.kondratiuk@linaro.org: removed lds.S->lds rule, added target to extra-y] Signed-off-by: NNicolas Pitre <nico@fluxnic.net> Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk> Signed-off-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Russell King 提交于
The legacy OMAP DMA API is now deprecated; all remaining users should now convert over ASAP to using the DMA engine API instead of the OMAP private API. Acked-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 30 6月, 2014 4 次提交
-
-
由 Linus Torvalds 提交于
-
git://ftp.arm.linux.org.uk/~rmk/linux-arm由 Linus Torvalds 提交于
Pull ARM fixes from Russell King: "Another round of ARM fixes. The largest change here is the L2 changes to work around problems for the Armada 37x/380 devices, where most of the size comes down to comments rather than code. The other significant fix here is for the ptrace code, to ensure that rewritten syscalls work as intended. This was pointed out by Kees Cook, but Will Deacon reworked the patch to be more elegant. The remainder are fairly trivial changes" * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: ARM: 8087/1: ptrace: reload syscall number after secure_computing() check ARM: 8086/1: Set memblock limit for nommu ARM: 8085/1: sa1100: collie: add top boot mtd partition ARM: 8084/1: sa1100: collie: revert back to cfi_probe ARM: 8080/1: mcpm.h: remove unused variable declaration ARM: 8076/1: mm: add support for HW coherent systems in PL310 cache
-
由 Randy Dunlap 提交于
Note that I don't maintain Documentation/ABI/, Documentation/devicetree/, or the language translation files. Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Dan Carpenter 提交于
These days most people use git to send patches so I have added a section about that. Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 29 6月, 2014 9 次提交
-
-
由 Will Deacon 提交于
On the syscall tracing path, we call out to secure_computing() to allow seccomp to check the syscall number being attempted. As part of this, a SIGTRAP may be sent to the tracer and the syscall could be re-written by a subsequent SET_SYSCALL ptrace request. Unfortunately, this new syscall is ignored by the current code unless TIF_SYSCALL_TRACE is also set on the current thread. This patch slightly reworks the enter path of the syscall tracing code so that we always reload the syscall number from current_thread_info()->syscall after the potential ptrace traps. Acked-by: NKees Cook <keescook@chromium.org> Tested-by: NKees Cook <keescook@chromium.org> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Laura Abbott 提交于
Commit 1c2f87c2 (ARM: 8025/1: Get rid of meminfo) changed find_limits to use memblock_get_current_limit for calculating the max_low pfn. nommu targets never actually set a limit on memblock though which means memblock_get_current_limit will just return the default value. Set the memblock_limit to be the end of DDR to make sure bounds are calculated correctly. Signed-off-by: NLaura Abbott <lauraa@codeaurora.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Andrea Adami 提交于
The CFI mapping is now perfect so we can expose the top block, read only. There isn't much to read, though, just the sharpsl_params values. Signed-off-by: NAndrea Adami <andrea.adami@gmail.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Andrea Adami 提交于
Reverts commit d26b17ed ARM: sa1100: collie.c: fall back to jedec_probe flash detection Unfortunately the detection was challenged on the defective unit used for tests: one of the NOR chips did not respond to the CFI query. Moreover that bad device needed extra delays on erase-suspend/resume cycles. Tested personally on 3 different units and with feedback of two other users. Signed-off-by: NAndrea Adami <andrea.adami@gmail.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nicolas Pitre 提交于
The sync_phys variable has been replaced by link time computation in mcpm_head.S before the code was submitted upstream. Signed-off-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Thomas Petazzoni 提交于
When a PL310 cache is used on a system that provides hardware coherency, the outer cache sync operation is useless, and can be skipped. Moreover, on some systems, it is harmful as it causes deadlocks between the Marvell coherency mechanism, the Marvell PCIe controller and the Cortex-A9. To avoid this, this commit introduces a new Device Tree property 'arm,io-coherent' for the L2 cache controller node, valid only for the PL310 cache. It identifies the usage of the PL310 cache in an I/O coherent configuration. Internally, it makes the driver disable the outer cache sync operation. Note that technically speaking, a fully coherent system wouldn't require any of the other .outer_cache operations. However, in practice, when booting secondary CPUs, these are not yet coherent, and therefore a set of cache maintenance operations are necessary at this point. This explains why we keep the other .outer_cache operations and only ->sync is disabled. While in theory any write to a PL310 register could cause the deadlock, in practice, disabling ->sync is sufficient to workaround the deadlock, since the other cache maintenance operations are only used in very specific situations. Contrary to previous versions of this patch, this new version does not simply NULL-ify the ->sync member, because the l2c_init_data structures are now 'const' and therefore cannot be modified, which is a good thing. Therefore, this patch introduces a separate l2c_init_data instance, called of_l2c310_coherent_data. Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi由 Linus Torvalds 提交于
Pull spi fixes from Mark Brown: "A few driver specific fixes, the biggest one being a fix for the newly added Qualcomm SPI controller driver to make it not use its internal chip select due to hardware bugs, replacing it with GPIOs" * tag 'spi-v3.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: qup: Remove chip select function spi: qup: Fix order of spi_register_master spi: sh-sci: fix use-after-free in sh_sci_spi_remove() spi/pxa2xx: fix incorrect SW mode chipselect setting for BayTrail LPSS SPI
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator由 Linus Torvalds 提交于
Pull regulator fixes from Mark Brown: "Several driver specific fixes here, the palmas fixes being especially important for a range of boards - the recent updates to support new devices have introduced several regressions" * tag 'regulator-v3.16-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: tps65218: Correct the the config register for LDO1 regulator: tps65218: Add the missing of_node assignment in probe regulator: palmas: fix typo in enable_reg calculation regulator: bcm590xx: fix vbus name regulator: palmas: Fix SMPS enable/disable/is_enabled
-
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending由 Linus Torvalds 提交于
Pull SCSI target fixes from Nicholas Bellinger: "Mostly minor fixes this time around. The highlights include: - iscsi-target CHAP authentication fixes to enforce explicit key values (Tejas Vaykole + rahul.rane) - fix a long-standing OOPs in target-core when a alua configfs attribute is accessed after port symlink has been removed. (Sebastian Herbszt) - fix a v3.10.y iscsi-target regression causing the login reject status class/detail to be ignored (Christoph Vu-Brugier) - fix a v3.10.y iscsi-target regression to avoid rejecting an existing ITT during Data-Out when data-direction is wrong (Santosh Kulkarni + Arshad Hussain) - fix a iscsi-target related shutdown deadlock on UP kernels (Mikulas Patocka) - fix a v3.16-rc1 build issue with vhost-scsi + !CONFIG_NET (MST)" * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending: iscsi-target: fix iscsit_del_np deadlock on unload iovec: move memcpy_from/toiovecend to lib/iovec.c iscsi-target: Avoid rejecting incorrect ITT for Data-Out tcm_loop: Fix memory leak in tcm_loop_submission_work error path iscsi-target: Explicily clear login response PDU in exception path target: Fix left-over se_lun->lun_sep pointer OOPs iscsi-target; Enforce 1024 byte maximum for CHAP_C key value iscsi-target: Convert chap_server_compute_md5 to use kstrtoul
-
- 28 6月, 2014 5 次提交
-
-
由 Mark Brown 提交于
-
由 Mark Brown 提交于
Merge remote-tracking branches 'regulator/fix/bcm590xx', 'regulator/fix/palmas' and 'regulator/fix/tps65218' into regulator-linus
-
由 Mikulas Patocka 提交于
On uniprocessor preemptible kernel, target core deadlocks on unload. The following events happen: * iscsit_del_np is called * it calls send_sig(SIGINT, np->np_thread, 1); * the scheduler switches to the np_thread * the np_thread is woken up, it sees that kthread_should_stop() returns false, so it doesn't terminate * the np_thread clears signals with flush_signals(current); and goes back to sleep in iscsit_accept_np * the scheduler switches back to iscsit_del_np * iscsit_del_np calls kthread_stop(np->np_thread); * the np_thread is waiting in iscsit_accept_np and it doesn't respond to kthread_stop The deadlock could be resolved if the administrator sends SIGINT signal to the np_thread with killall -INT iscsi_np The reproducible deadlock was introduced in commit db6077fd, but the thread-stopping code was racy even before. This patch fixes the problem. Using kthread_should_stop to stop the np_thread is unreliable, so we test np_thread_state instead. If np_thread_state equals ISCSI_NP_THREAD_SHUTDOWN, the thread exits. Signed-off-by: NMikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu由 Linus Torvalds 提交于
Pull IOMMU fixes from Joerg Roedel: - fix VT-d regression with handling multiple RMRR entries per device - fix a small race that was left in the mmu_notifier handling in the AMD IOMMUv2 driver * tag 'iommu-fixes-v3.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/amd: Fix small race between invalidate_range_end/start iommu/vt-d: fix bug in handling multiple RMRRs for the same PCI device
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip由 Linus Torvalds 提交于
Pull x86 fixes from Peter Anvin: "A pile of fixes related to the VDSO, EFI and 32-bit badsys handling. It turns out that removing the section headers from the VDSO breaks gdb, so this puts back most of them. A very simple typo broke rt_sigreturn on some versions of glibc, with obviously disastrous results. The rest is pretty much fixes for the corresponding fallout. The EFI fixes fixes an arithmetic overflow on 32-bit systems and quiets some build warnings. Finally, when invoking an invalid system call number on x86-32, we bypass a bunch of handling, which can make the audit code oops" * 'x86/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi-pstore: Fix an overflow on 32-bit builds x86/vdso: Error out in vdso2c if DT_RELA is present x86/vdso: Move DISABLE_BRANCH_PROFILING into the vdso makefile x86_32, signal: Fix vdso rt_sigreturn x86_32, entry: Do syscall exit work on badsys (CVE-2014-4508) x86/vdso: Create .build-id links for unstripped vdso files x86/vdso: Remove some redundant in-memory section headers x86/vdso: Improve the fake section headers x86/vdso2c: Use better macros for ELF bitness x86/vdso: Discard the __bug_table section efi: Fix compiler warnings (unused, const, type)
-