- 01 5月, 2014 1 次提交
-
-
由 H. Peter Anvin 提交于
The IRET instruction, when returning to a 16-bit segment, only restores the bottom 16 bits of the user space stack pointer. This causes some 16-bit software to break, but it also leaks kernel state to user space. We have a software workaround for that ("espfix") for the 32-bit kernel, but it relies on a nonzero stack segment base which is not available in 64-bit mode. In checkin: b3b42ac2 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels we "solved" this by forbidding 16-bit segments on 64-bit kernels, with the logic that 16-bit support is crippled on 64-bit kernels anyway (no V86 support), but it turns out that people are doing stuff like running old Win16 binaries under Wine and expect it to work. This works around this by creating percpu "ministacks", each of which is mapped 2^16 times 64K apart. When we detect that the return SS is on the LDT, we copy the IRET frame to the ministack and use the relevant alias to return to userspace. The ministacks are mapped readonly, so if IRET faults we promote #GP to #DF which is an IST vector and thus has its own stack; we then do the fixup in the #DF handler. (Making #GP an IST exception would make the msr_safe functions unsafe in NMI/MC context, and quite possibly have other effects.) Special thanks to: - Andy Lutomirski, for the suggestion of using very small stack slots and copy (as opposed to map) the IRET frame there, and for the suggestion to mark them readonly and let the fault promote to #DF. - Konrad Wilk for paravirt fixup and testing. - Borislav Petkov for testing help and useful comments. Reported-by: NBrian Gerst <brgerst@gmail.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Andrew Lutomriski <amluto@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Dirk Hohndel <dirk@hohndel.org> Cc: Arjan van de Ven <arjan.van.de.ven@intel.com> Cc: comex <comexk@gmail.com> Cc: Alexander van Heukelum <heukelum@fastmail.fm> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com> Cc: <stable@vger.kernel.org> # consider after upstream merge
-
- 26 4月, 2014 3 次提交
-
-
由 Linus Torvalds 提交于
The mmu-gather operation 'tlb_flush_mmu()' has done two things: the actual tlb flush operation, and the batched freeing of the pages that the TLB entries pointed at. This splits the operation into separate phases, so that the forced batched flushing done by zap_pte_range() can now do the actual TLB flush while still holding the page table lock, but delay the batched freeing of all the pages to after the lock has been dropped. This in turn allows us to avoid a race condition between set_page_dirty() (as called by zap_pte_range() when it finds a dirty shared memory pte) and page_mkclean(): because we now flush all the dirty page data from the TLB's while holding the pte lock, page_mkclean() will be held up walking the (recently cleaned) page tables until after the TLB entries have been flushed from all CPU's. Reported-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Tested-by: NDave Hansen <dave.hansen@intel.com> Acked-by: NHugh Dickins <hughd@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Christian Borntraeger 提交于
commit 0b60f9ea (s390: use device_remove_file_self() instead of device_schedule_callback()) caused random memory corruption on my s390 box. Turns out that the last element of the ccwgroup structure is of dynamic size, so we must move the newly introduced work structure _before_ the zero length array. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> CC: Tejun Heo <tj@kernel.org> CC: Martin Schwidefsky <schwidefsky@de.ibm.com> CC: Heiko Carstens <heiko.carstens@de.ibm.com> CC: Sebastian Ott <sebott@linux.vnet.ibm.com> CC: Peter Oberparleiter <oberpar@linux.vnet.ibm.com> Acked-by: NTejun Heo <tj@kernel.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Chanho Min 提交于
Clock providers should be initialized before clocksource_of_init. If not, Clock source initialization can be fail to get the clock. Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NChanho Min <chanho.min@lge.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
- 25 4月, 2014 9 次提交
-
-
由 Leo Yan 提交于
ARM64 has defined the spinlock for init_mm's context, so need initialize the spinlock structure; otherwise during the suspend flow it will dump the info for spinlock's bad magic warning as below: [ 39.084394] Disabling non-boot CPUs ... [ 39.092871] BUG: spinlock bad magic on CPU#1, swapper/1/0 [ 39.092896] lock: init_mm+0x338/0x3e0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 [ 39.092907] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G O 3.10.33 #125 [ 39.092912] Call trace: [ 39.092927] [<ffffffc000087e64>] dump_backtrace+0x0/0x16c [ 39.092934] [<ffffffc000087fe0>] show_stack+0x10/0x1c [ 39.092947] [<ffffffc000765334>] dump_stack+0x1c/0x28 [ 39.092953] [<ffffffc0007653b8>] spin_dump+0x78/0x88 [ 39.092960] [<ffffffc0007653ec>] spin_bug+0x24/0x34 [ 39.092971] [<ffffffc000300a28>] do_raw_spin_lock+0x98/0x17c [ 39.092979] [<ffffffc00076cf08>] _raw_spin_lock_irqsave+0x4c/0x60 [ 39.092990] [<ffffffc000094044>] set_mm_context+0x1c/0x6c [ 39.092996] [<ffffffc0000941c8>] __new_context+0x94/0x10c [ 39.093007] [<ffffffc0000d63d4>] idle_task_exit+0x104/0x1b0 [ 39.093014] [<ffffffc00008d91c>] cpu_die+0x14/0x74 [ 39.093021] [<ffffffc000084f74>] arch_cpu_idle_dead+0x8/0x14 [ 39.093030] [<ffffffc0000e7f18>] cpu_startup_entry+0x1ec/0x258 [ 39.093036] [<ffffffc00008d810>] secondary_start_kernel+0x114/0x124 Signed-off-by: NLeo Yan <leoy@marvell.com> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Will Deacon 提交于
Sending a SIGTRAP to a user task after execution of a BRK instruction at EL0 is fundamental to the way in which software breakpoints work and doesn't deserve a warning to be logged in dmesg. Whilst the warning can be justified from EL1, do_debug_exception will already do the right thing, so simply remove the code altogether. Cc: Sandeepa Prabhu <sandeepa.prabhu@linaro.org> Reported-by: NKyrylo Tkachov <kyrylo.tkachov@arm.com> Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Steve Capper 提交于
When arm64 moved over to the core mmu_gather, it lost the logic to flush THP TLB entries (tlb_remove_pmd_tlb_entry was removed and the core implementation only signals that the mmu_gather needs a flush). This patch ensures that tlb_add_flush is called for THP TLB entries. Signed-off-by: NSteve Capper <steve.capper@linaro.org> Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Sebastian Hesselbarth 提交于
Some Marvell PJ4B CPUs also implement iWMMXt extensions. With a proper check for iWMMXt coprocessors now in place, enable it by default on PJ4B. While at it, also allow to manually select the corresponding Kconfig option. Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: NKevin Hilman <khilman@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Sebastian Hesselbarth 提交于
Commit fdb487f5 ("ARM: 8015/1: Add cpu_is_pj4 to distinguish PJ4 because it has some differences with V7") introduced a cpuid check for Marvell PJ4 processors to fix a regression caused by adding PJ4 based Marvell Dove into multi_v7. Unfortunately, this check is too narrow to catch PJ4 used on Dove itself and breaks iWMMXt support. This patch therefore relaxes the cpuid mask to match both PJ4 and PJ4B. Also, rework the given comment about PJ4/PJ4B modifications to be a little bit more specific about the differences. Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: NKevin Hilman <khilman@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Sebastian Hesselbarth 提交于
commit fdb487f5 ("ARM: 8015/1: Add cpu_is_pj4 to distinguish PJ4 because it has some differences with V7") introduced a fix for checking PJ4 cpuid to not use PJ4 specific coprocessor access on non-PJ4 platforms. Unfortunately, this in turn broke Marvell Armada 370/XP, both comprising Marvell PJ4B CPUs without iWMMXt extension. Instead of only checking for cpuid, which may not be sufficient to determine iWMMXt support, the presence of iWMMXt coprocessors can be checked by enabling and reading the Coprocessor ID register (wCID, register 0 of CP1). Therefore this adds an explicit check for the presence and correct wCID value, before enabling iWMMXt capabilities. As a bonus, also print the iWMMXt version of a detected coprocessor. This has been tested to properly detect iWMMXt presence/absence on: - PJ4, CPUID 0x560f5815, wCID 0x56052001: Marvell Dove, iWMMXt v2 - PJ4B, CPUID 0x561f5811: Marvell Armada 370, no iWMMXt - PJ4B, CPUID 0x562f5841, wCID 0x56052001: Marvell Armada 1500, iWMMXt v2 - PJ4B, CPUID 0x562f5842: Marvell Armada XP, no iWMMXt Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: NKevin Hilman <khilman@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Sebastian Hesselbarth 提交于
This fixes PJ4 coprocessor init to only expose iWMMXt capabilities, if the corresponding kernel support for iWMMXt is enabled. Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: NKevin Hilman <khilman@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Sebastian Hesselbarth 提交于
iwmmxt.S requires special treatment of coprocessor access registers for PJ4 and XScale-based CPUs. It only checks for CPU_PJ4 and drops down to XScale-based treatment on all other architectures. As some PJ4B also come with iWMMXt and also need PJ4 treatment, rework the corresponding preprocessor directives to explicitly check for supported architectures and fail on unsupported ones. Signed-off-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Tested-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com> Tested-by: NKevin Hilman <khilman@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Punit Agrawal 提交于
The SPC stores voltage in mV while the code assumes it was returning uV. Convert the returned voltage to uV before storing. Also fix the comment depicting voltage to uV. Signed-off-by: NPunit Agrawal <punit.agrawal@arm.com> Reviewed-by: NSudeep Holla <sudeep.holla@arm.com> Signed-off-by: NPawel Moll <pawel.moll@arm.com>
-
- 24 4月, 2014 8 次提交
-
-
由 Stephen Warren 提交于
Tegra124 only has 4 UARTs. Parts of the documentation hint at a fifth UART, but this appears to be left-over from earlier SoC documentation. Remove the non-existent DT node for UART5. Cc: <stable@vger.kernel.org> Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Paul Bolle 提交于
Commit a7cbe92c ("ARM: tegra: remove tegra EMC scaling driver") removed the only user of TEGRA_EMC_SCALING_ENABLE. Remove its Kconfig entry too. Signed-off-by: NPaul Bolle <pebolle@tiscali.nl> Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Domenico Andreoli 提交于
Few things were out of order: - removed ARCH_BCM2835 duplicate - shuffled ARCH_BCM_5301X, ARCH_U8500 and ARCH_U300 around so to keep the list sorted Cc: Arnd Bergmann <arnd@arndb.de> Cc: Olof Johansson <olof@lixom.net> Signed-by: NDomenico Andreoli <domenico.andreoli@linux.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Rob Herring 提交于
In commit ddb902cc (ARM: centralize common multi-platform kconfig options), CLKSRC_OF was removed from some platforms, but not added to ARCH_MULTIPLATFORM. Fix this. Reported-by: NLauri Hintsala <lauri.hintsala@bluegiga.com> Signed-off-by: NRob Herring <robh@kernel.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Alex Elder 提交于
I get a build warning because spear_clocksource_init() calls clocksource_mmio_init(), but it doesn't have an __init annotation. Fix that. Signed-off-by: NAlex Elder <elder@linaro.org> Acked-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Andrea Adami 提交于
hx4700 needs the same fix as in 9705e746 "ARM: pxa: fix various compilation problems" Fix build errors. Initial one is: /linux/arch/arm/mach-pxa/include/mach/hx4700.h:18:32: error: 'PXA_NR_BUILTIN_GPIO' undeclared here (not in a function) | #define HX4700_ASIC3_GPIO_BASE PXA_NR_BUILTIN_GPIO Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: NAndrea Adami <andrea.adami@gmail.com> Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
由 Heinrich Schuchardt 提交于
dcscb_allcpus_mask is an array of size 2. The index variable cluster has to be checked against this limit before accessing the array. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NPawel Moll <pawel.moll@arm.com>
-
由 Tony Lindgren 提交于
At least the smc91x driver expects the device to be at 0x300 offset from bus base address. This does not work currently for GPMC when booted in device tree mode as it attempts to remap the the allocated GPMC partition to the address configured by the device tree plus the device offset. Note that this works just fine when booted with legacy mode. Let's fix the issue by just ignoring any device specific offset while remapping. And let's make sure the remap address confirms to the GPMC 16MB minimum granularity as listed in the TRM for GPMC_CONFIG7 BASEADDRESS bits. Otherwise we can get something like this: omap-gpmc 6e000000.gpmc: cannot remap GPMC CS 1 to 0x01000300 Cc: Pekon Gupta <pekon@ti.com> Reviewed-by: NJavier Martinez Canillas <javier@dowhile0.org> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 23 4月, 2014 10 次提交
-
-
由 Ritesh Harjani 提交于
68efd7d2("arm: dma-mapping: remove order parameter from arm_iommu_create_mapping()") is causing kernel panic because it wrongly sets the value of mapping->size: Unable to handle kernel NULL pointer dereference at virtual address 000000a0 pgd = e7a84000 [000000a0] *pgd=00000000 ... PC is at bitmap_clear+0x48/0xd0 LR is at __iommu_remove_mapping+0x130/0x164 Fix it by correcting mapping->size value. Signed-off-by: NRitesh Harjani <ritesh.harjani@gmail.com> Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
-
由 Miklos Szeredi 提交于
Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz> [dropped arch/arm/include/asm/unistd.h changes --rmk] Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Miklos Szeredi 提交于
Wire up the renameat2 syscall for compat (AArch32) applications. Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Russell King 提交于
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Victor Kamensky 提交于
Fix e26a9e00 'ARM: Better virt_to_page() handling' replaced __pv_phys_offset with __pv_phys_pfn_offset. Also note that size of __pv_phys_offset was quad but size of __pv_phys_pfn_offset is word. Instruction that used to update __pv_phys_offset which address is in r6 had to update low word of __pv_phys_offset so it used #LOW_OFFSET macro for store offset. Now when size of __pv_phys_pfn_offset is word, no difference between little endian and big endian should exist - i.e no offset should be used when __pv_phys_pfn_offset is stored. Note that for little endian image proposed change is noop, since in little endian case #LOW_OFFSET is defined 0 anyway. Reported-by: NTaras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: NVictor Kamensky <victor.kamensky@linaro.org> Acked-by: NNicolas Pitre <nico@linaro.org> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Nicolas Pitre 提交于
The switcher should not depend on MAX_CLUSTER to determine ifit should be activated or not. In a multiplatform kernel binary it is possible to have dual-cluster and quad-cluster platforms configured in. In that case MAX_CLUSTER which is a build time limit should be 4 and that shouldn't prevent the switcher from working if the kernel is booted on a b.L dual-cluster system. In bL_switcher_halve_cpus() we already have a runtime validation check to make sure we're dealing with only two clusters, so booting on a quad cluster system will be caught and switcher activation aborted. However, the b.L switcher must ensure the MCPM layer is initialized on the booted hardware before doing anything. The mcpm_is_available() function is added to that effect. Signed-off-by: NNicolas Pitre <nico@linaro.org> Tested-by: NAbhilash Kesavan <kesavan.abhilash@gmail.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Liu Hua 提交于
For vmcore generated by LPAE enabled kernel, user space utility such as crash needs additional infomation to parse. So this patch add arch_crash_save_vmcoreinfo as what PAE enabled i386 linux does. Cc: <stable@vger.kernel.org> Reviewed-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NLiu Hua <sdu.liu@huawei.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Xiangyu Lu 提交于
In big-endian systems, "%1" get the most significant part of the value, cause the instruction to get the wrong result. When viewing ftrace record in big-endian ARM systems, we found that the timestamp errors: swapper-0 [001] 1325.970000: 0:120:R ==> [001] 16:120:R events/1 events/1-16 [001] 1325.970000: 16:120:S ==> [001] 0:120:R swapper swapper-0 [000] 1325.1000000: 0:120:R + [000] 15:120:R events/0 swapper-0 [000] 1325.1000000: 0:120:R ==> [000] 15:120:R events/0 swapper-0 [000] 1326.030000: 0:120:R + [000] 1150:120:R sshd swapper-0 [000] 1326.030000: 0:120:R ==> [000] 1150:120:R sshd When viewed ftrace records, it will call the do_div(n, base) function, which achieved arch/arm/include/asm/div64.h in. When n = 10000000, base = 1000000, in do_div(n, base) will execute "umull %Q0, %R0, %1, %Q2". Reviewed-by: NDave Martin <Dave.Martin@arm.com> Reviewed-by: NNicolas Pitre <nico@linaro.org> Cc: <stable@vger.kernel.org> # 2.6.20+ Signed-off-by: NAlex Wu <wuquanming@huawei.com> Signed-off-by: NXiangyu Lu <luxiangyu@huawei.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
由 Hanjun Guo 提交于
There is a duplicated Kconfig entry for "kernel/power/Kconfig" in menu "Power management options" and "CPU Power Management", remove the one from menu "CPU Power Management" suggested by Viresh. Signed-off-by: NHanjun Guo <hanjun.guo@linaro.org> Reviewed-by: NViresh Kumar <viresh.kumar@linaro.org> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Miklos Szeredi 提交于
This fixes commit 6290b53d (arm64: compat: Wire up new AArch32 syscalls) which did not update __NR_compat_syscalls accordingly. Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz> Cc: <stable@vger.kernel.org> # 3.14+ Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
- 22 4月, 2014 4 次提交
-
-
由 Jeff Layton 提交于
File-private locks have been merged into Linux for v3.15, and *now* people are commenting that the name and macro definitions for the new file-private locks suck. ...and I can't even disagree. The names and command macros do suck. We're going to have to live with these for a long time, so it's important that we be happy with the names before we're stuck with them. The consensus on the lists so far is that they should be rechristened as "open file description locks". The name isn't a big deal for the kernel, but the command macros are not visually distinct enough from the traditional POSIX lock macros. The glibc and documentation folks are recommending that we change them to look like F_OFD_{GETLK|SETLK|SETLKW}. That lessens the chance that a programmer will typo one of the commands wrong, and also makes it easier to spot this difference when reading code. This patch makes the following changes that I think are necessary before v3.15 ships: 1) rename the command macros to their new names. These end up in the uapi headers and so are part of the external-facing API. It turns out that glibc doesn't actually use the fcntl.h uapi header, but it's hard to be sure that something else won't. Changing it now is safest. 2) make the the /proc/locks output display these as type "OFDLCK" Cc: Michael Kerrisk <mtk.manpages@gmail.com> Cc: Christoph Hellwig <hch@infradead.org> Cc: Carlos O'Donell <carlos@redhat.com> Cc: Stefan Metzmacher <metze@samba.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Frank Filz <ffilzlnx@mindspring.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: NJeff Layton <jlayton@redhat.com>
-
由 Soren Brinkmann 提交于
Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com> Tested-by: NMichal Simek <michal.simek@xilinx.com> Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
-
由 Soren Brinkmann 提交于
Specify the 'clock-latency' property to avoid certain cpufreq governors from refusing to work with the following error: ondemand governor failed, too long transition latency of HW, fallback to performance governor Reported-by: NMike Looijmans <mike.looijmans@topic.nl> Signed-off-by: NSoren Brinkmann <soren.brinkmann@xilinx.com> Tested-by: NMike Looijmans <mike.looijmans@topic.nl> Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
-
由 Tony Lindgren 提交于
If gpmc_cs_remap() fails we will get an error because we are calling release_resource() on an uninitialized resource. Let's fix that by checking the resource flags. And while at it, let's also make gpmc_cs_delete_mem() use the res pointer that we already have to avoid confusion. Without this patch we can get the following error: omap-gpmc 6e000000.gpmc: cannot remap GPMC CS 1 to 0x01000300 Unable to handle kernel NULL pointer dereference at virtual address 00000018 ... (gpmc_cs_free+0x94/0xc8) (gpmc_probe_generic_child+0x178/0x1ec) (gpmc_probe_dt+0x1bc/0x2cc) (gpmc_probe+0x250/0x44c) (platform_drv_probe+0x3c/0x6c) (really_probe+0x74/0x208) (driver_probe_device+0x34/0x50) (bus_for_each_drv+0x60/0x8c) (device_attach+0x80/0xa4) (bus_probe_device+0x88/0xb0) (device_add+0x320/0x450) (of_platform_device_create_pdata+0x80/0x9c) (of_platform_bus_create+0xd0/0x170) (of_platform_bus_create+0x12c/0x170) (of_platform_populate+0x60/0x98) (pdata_quirks_init+0x30/0x48) (customize_machine+0x20/0x48) (do_one_initcall+0x2c/0x14c) (do_basic_setup+0x98/0xd8) (kernel_init_freeable+0x12c/0x1e0) (kernel_init+0x8/0xf0) (ret_from_fork+0x14/0x2c) Code: e1a04000 e59f0070 eb195136 e5942010 (e5923018) Cc: Pekon Gupta <pekon@ti.com> Reviewed-by: NJavier Martinez Canillas <javier@dowhile0.org> Signed-off-by: Ntony Lindgren <tony@atomide.com>
-
- 21 4月, 2014 3 次提交
-
-
由 Anton Ivanov 提交于
The reverse case of this race (you must msync before read) is well known. This is the not so common one. It can be triggered only on systems which do a lot of task switching and only at UML startup. If you are starting 200+ UMLs ~ 0.5% will always die without this fix. Signed-off-by: NAnton Ivanov <antivano@cisco.com> [rw: minor whitespace fixes] Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Anton Ivanov 提交于
UML does not handle sigpipe. As a result when running it under expect or redirecting the IO from the console to an external program it will crash if the program stops or exits. Signed-off-by: NAnton Ivanov <antivano@cisco.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
由 Tristan Schmelcher 提交于
Inferring the mount hierarchy correctly from /proc/mounts is hard when MS_MOVE may have been used, and the previous code did it wrongly. This change simplifies the logic to only require that /dev/shm be _on_ tmpfs (which can be checked trivially with statfs) rather than that it be a _mountpoint_ of tmpfs, since there isn't a compelling reason to be that strict. We also now check for tmpfs on whatever directory we ultimately use so that the user is better informed. This change also moves the more standard TMPDIR environment variable check ahead of the others. Applies to 3.12. Signed-off-by: NTristan Schmelcher <tschmelcher@google.com> Signed-off-by: NRichard Weinberger <richard@nod.at>
-
- 19 4月, 2014 2 次提交
-
-
由 Robert Nelson 提交于
BeagleBoard xM A/B has an inverted usb hub enable line vs the xM C Signed-off-by: NRobert Nelson <robertcnelson@gmail.com> [tony@atomide.com: updated for missing bracket] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kees Cook 提交于
The lkdtm module performs tests against executable memory ranges, so it needs to flush the icache for proper behaviors. Other architectures already export this, so do the same for MIPS. [akpm@linux-foundation.org: relocate export sites] Signed-off-by: NKees Cook <keescook@chromium.org> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Sanjay Lal <sanjayl@kymasys.com> Cc: John Crispin <blogic@openwrt.org> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-