- Dec 21, 2012
-
-
David Woodhouse authored
It is easy to waste a bunch of time when one takes a 32-bit .config from a test machine and try to build it on a faster 64-bit system, and its existing setting of CONFIG_64BIT=n gets *changed* to match the build host. Similarly, if one has an existing build tree it is easy to trash an entire build tree that way. This is because the default setting for $ARCH when discovered from 'uname' is one of the legacy pre-x86-merge values (i386 or x86_64), which effectively force the setting of CONFIG_64BIT to match. We should default to ARCH=x86 instead, finally completing the merge that we started so long ago. This patch preserves the behaviour of the legacy ARCH settings for commands such as: make ARCH=x86_64 randconfig make ARCH=i386 randconfig ... since making the value of CONFIG_64BIT actually random in that situation is not desirable. In time, perhaps we can retire this legacy use of the old ARCH= values. We already have a way to override values for *any* config option, using $KCONFIG_ALLCONFIG, so it could be argued that we don't necessarily need to keep ARCH={i386,x86_64} around as a special case just for overriding CONFIG_64BIT. We'd probably at least want to add a way to override config options from the command line ('make CONFIG_FOO=y oldconfig') before we talk about doing that though. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Link: http://lkml.kernel.org/r/1356040315.3198.51.camel@shinybook.infradead.org Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
- Dec 06, 2012
-
-
Dmitry Adamushko authored
The problem occurs [1] when a kernel-mode task returns from a system call with a pending signal. A real-life scenario is a child of 'khelper' returning from a failed kernel_execve() in ____call_usermodehelper() [ kernel/kmod.c ]. kernel_execve() fails due to a pending SIGKILL, which is the result of "kill -9 -1" (at least, busybox's init does it upon reboot). The loop is as follows: * syscall_exit_work: - work_pending: // start_of_the_loop - work_notifysig: - do_notify_resume() - do_signal() - if (!user_mode(regs)) return; - resume_userspace // TIF_SIGPENDING is still set - work_pending // so we call work_pending => goto // start_of_the_loop More information can be found in another LKML thread: http://www.serverphorums.com/read.php?12,457826 [1] The problem was also reproduced on !CONFIG_VM86 x86, and the following fix was accepted. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=29a2e2836ff9ea65a603c89df217f4198973a74f Signed-off-by:
Dmitry Adamushko <dmitry.adamushko@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/3571/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Broken since e05ea74fc56f347f872ef9946d27c53e8bf20864 (lmo) rsp. cea7e2df (kernel.org) [MIPS: Sort out CPU type to name translation.] These CPUs are no longer very popular to say the least ... Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Reported-by:
Murphy McCauley <murphy.mccauley@gmail.com>
-
Ralf Baechle authored
This needs to use the compat entry point or it's going to fail on big endian systems. Noticed by Al Viro. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
- Dec 05, 2012
-
-
Ralf Baechle authored
By using the native syscall entry point the kernel was also expecting 64-bit iovec structures. This is broken since ddd9e91b [preadv/ pwritev: MIPS: Add preadv(2) and pwritev(2) syscalls.] which originally added these two syscalls. I walked through piles of code, including libc and couldn't find anything that would have worked around the issue so this change the API to what it should always have been. Noticed and patch suggested by Al Viro. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
- Dec 04, 2012
-
-
David Daney authored
Problem: 1) Huge page mapping of anonymous memory is initially invalid. Will be faulted in by copy-on-write mechanism. 2) Userspace attempts store at the end of the huge mapping. 3) TLB Refill exception handler fill TLB with a normal (4K sized) invalid page at the end of the huge mapping virtual address range. 4) Userspace restarted, and re-attempts the store at the end of the huge mapping. 5) Page from #3 is invalid, we get a fault and go to the hugepage fault handler. This tries to map a huge page and calls huge_ptep_set_access_flags() to install the mapping. 6) We just call the generic ptep_set_access_flags() to set up the page tables, but the flush there assumes a normal (4K sized) page and only tries to flush the first part of the huge page virtual address out of the TLB, since the existing entry from step #3 doesn't conflict, nothing is flushed. 7) We attempt to load the mapping into the TLB, but because it conflicts with the entry from step #3, we get a Machine Check exception. The fix: Flush the entire rage covered by the huge page in huge_ptep_set_access_flags(), and remove the optimization in local_flush_tlb_range() so that the flush actually does the correct thing. Signed-off-by:
David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: Hillf Danton <dhillf@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/4661/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> (cherry picked from commit dd617f258cc39d36be26afee9912624a2d23112c)
-
David S. Miller authored
Newer versions of binutils mark '_end' as 'B' instead of 'A' for whatever reason. To be honest, the piggyback code doesn't actually care what kind of symbol _start and _end are, it just wants to find them and record the address. So remove the type from the match strings. Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Al Viro authored
In commit 9d73fc2d ("open*(2) compat fixes (s390, arm64)") I said: > > The usual rules for open()/openat()/open_by_handle_at() are > 1) native 32bit - don't force O_LARGEFILE in flags > 2) native 64bit - force O_LARGEFILE in flags > 3) compat on 64bit host - as for native 32bit > 4) native 32bit ABI for 64bit system (mips/n32, x86/x32) - as for native 64bit > > There are only two exceptions - s390 compat has open() forcing O_LARGEFILE and > arm64 compat has open_by_handle_at() doing the same thing. The same binaries > on native host (s390/31 and arm resp.) will *not* force O_LARGEFILE, so IMO > both are emulation bugs. Three exceptions, actually - parisc open() is another case like that. Native 32bit won't force O_LARGEFILE, the same binary on parisc64 will. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Dec 03, 2012
-
-
Al Viro authored
The usual rules for open()/openat()/open_by_handle_at() are 1) native 32bit - don't force O_LARGEFILE in flags 2) native 64bit - force O_LARGEFILE in flags 3) compat on 64bit host - as for native 32bit 4) native 32bit ABI for 64bit system (mips/n32, x86/x32) - as for native 64bit There are only two exceptions - s390 compat has open() forcing O_LARGEFILE and arm64 compat has open_by_handle_at() doing the same thing. The same binaries on native host (s390/31 and arm resp.) will *not* force O_LARGEFILE, so IMO both are emulation bugs. Objections? The fix is obvious... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Dec 01, 2012
-
-
Vincent Palatin authored
When a cpu enters S3 state, the FPU state is lost. After resuming for S3, if we try to lazy restore the FPU for a process running on the same CPU, this will result in a corrupted FPU context. Ensure that "fpu_owner_task" is properly invalided when (re-)initializing a CPU, so nobody will try to lazy restore a state which doesn't exist in the hardware. Tested with a 64-bit kernel on a 4-core Ivybridge CPU with eagerfpu=off, by doing thousands of suspend/resume cycles with 4 processes doing FPU operations running. Without the patch, a process is killed after a few hundreds cycles by a SIGFPE. Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Olof Johansson <olofj@chromium.org> Cc: <stable@kernel.org> v3.4+ # for 3.4 need to replace this_cpu_write by percpu_write Signed-off-by:
Vincent Palatin <vpalatin@chromium.org> Link: http://lkml.kernel.org/r/1354306532-1014-1-git-send-email-vpalatin@chromium.org Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
- Nov 29, 2012
-
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
incidentally, declaring a local variable as __user (!) to make sparse STFU is really sick. Especially since sparse had been 100% right - it *is* a bug. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
do_sigaltstack() expects _userland_ address, TYVM... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Al Viro authored
... or we'll end up buggering the results of ELF_PLAT_INIT() Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
Mark Salter authored
Signed-off-by:
Mark Salter <msalter@redhat.com>
-
Mark Salter authored
Some internal kernel symbols were referenced in the exported setup.h. This splits out the internal bits from the exported uapi bits. Signed-off-by:
Mark Salter <msalter@redhat.com>
-
- Nov 28, 2012
-
-
Will Deacon authored
The SP804 driver statically initialises the cpumask of the clock event device to be cpu_all_mask, which is derived from the compile-time constant NR_CPUS. This breaks SMP_ON_UP systems where the interrupt controller handling the sp804 doesn't have the irq_set_affinity callback on the irq_chip, because the common timer code fails to identify the device as cpu-local and ends up treating it as a broadcast device instead. This patch fixes the problem by using cpu_possible_mask at runtime, which will correctly represent the possible CPUs when SMP_ON_UP is being used. Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
H. Peter Anvin authored
There appear to have been some 486 clones, including the "enhanced" version of Am486, which have CPUID but not CR4. These 486 clones had only the FPU flag, if any, unlike the Intel 486s with CPUID, which also had VME and therefore needed CR4. Therefore, look at the basic CPUID flags and require at least one bit other than bit 0 before we modify CR4. Thanks to Christian Ludloff of sandpile.org for confirming this as a problem. Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com>
-
- Nov 27, 2012
-
-
H. Peter Anvin authored
In __emulate_1op_rax_rdx, we use "+a" and "+d" which are input/output constraints, and *then* use "a" and "d" as input constraints. This is incorrect, but happens to work on some versions of gcc. However, it breaks gcc with -O0 and icc, and may break on future versions of gcc. Reported-and-tested-by:
Melanie Blower <melanie.blower@intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/B3584E72CFEBED439A3ECA9BCE67A4EF1B17AF90@FMSMSX107.amr.corp.intel.com Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Acked-by:
Marcelo Tosatti <mtosatti@redhat.com>
-
Mark Salter authored
A comment in entry.S incorrectly stated that interrupt vectors called __do_IRQ() and that int6 vector was used for syscalls. Both statements are incorrect for the current kernel, so this patch cleans up the wording to reflect current reality. Signed-off-by:
Mark Salter <msalter@redhat.com>
-
Mark Salter authored
C6x was mistakenly running do_notify_resume with interrupts disabled. This would triggerlead to a warning in local_bh_enable() because interrupts were disabled: ------------[ cut here ]------------ WARNING: at /es/linux/linux-next/kernel/softirq.c:160 local_bh_enable+0x5c/0x10c() Modules linked in: e02f384d e002cda8 e02f3469 e02f384d 000000a0 e00363fc e01cce58 e5005c00 e0327986 00000000 e63c0aec 00000164 e00363fc 00000000 fffffffe e5005c00 e61fde00 e0268184 00000134 e01c91dc 00000001 fffffffe 00000000 10000100 e01c80e4 e5005c00 00000000 00000000 00000000 e63c0aec e526ce00 10000100 e628f920 e63c0a88 e6010410 e6449750 e5005c20 00000000 00000000 e63c0a80 e5005c20 e01c8590 e63c0a80 e5005c20 e63c0aec e00a0554 e009c758 e639e860 irq_spurious_proc_fops+0x6ad/0x3438 warn_slowpath_common+0x8c/0xb8 irq_spurious_proc_fops+0x2c9/0x3438 irq_spurious_proc_fops+0x6ad/0x3438 local_bh_enable+0x5c/0x10c sk_alloc+0x34/0xa4 local_bh_enable+0x5c/0x10c unix_release_sock+0x5c/0x2a0 sys_connect+0x94/0xd4 sock_release+0x38/0x104 sock_close+0x3c/0x54 __fput+0x154/0x2ec filp_close+0xc0/0xe4 task_work_run+0xdc/0x12c sys_close+0x2c/0x74 resume_userspace+0x0/0x30 ---[ end trace a70cbd610ae1f6b4 ]--- This patch enables interrupts before calling do_notify_resume(). Signed-off-by:
Mark Salter <msalter@redhat.com>
-
- Nov 26, 2012
-
-
Gavin Shan authored
While the EEH does recovery on the specific PE that has PCI errors, the PCI devices belonging to the PE will be removed and the PE will be marked as invalid since we still need the information stored in the PE. We only invalidate the PE when it doesn't have associated EEH devices and valid child PEs. However, the code used to check that is wrong. The patch fixes that. Signed-off-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
- Nov 24, 2012
-
-
Andreas Larsson authored
This bug-fix makes sure that of_iomap is defined extern for sparc so that the sparc-specific implementation of_iomap is once again used when including include/linux/of_address.h in a sparc context. OF_GPIO that is now available for sparc relies on this. The bug was inadvertently introduced in a850a755, "of/address: add empty static inlines for !CONFIG_OF", that added a static dummy inline for of_iomap when !CONFIG_OF_ADDRESS. However, CONFIG_OF_ADDRESS is never defined for sparc, but there is a sparc-specific implementation /arch/sparc/kernel/of_device_common.c. This fix takes the same approach as 0bce04be that solved the equivalent problem for of_address_to_resource. Signed-off-by:
Andreas Larsson <andreas@gaisler.com> Acked-by:
David Miller <davem@davemloft.net> Signed-off-by:
Grant Likely <grant.likely@secretlab.ca>
-
Al Cooper authored
A recent patch changed some irq routines from inlines to functions. These routines are called by the tracer code. Now that they're functions, if they are compiled for function tracing they will call the tracer and crash the system due to infinite recursion. The fix disables tracing in these functions by using "notrace" in the function definition. Signed-off-by:
Al Cooper <alcooperx@gmail.com> Reviewed-by:
David Daney <david.daney@cavium.com> Pathchwork: https://patchwork.linux-mips.org/patch/4564/ Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
Ralf Baechle authored
Without this, we may end up with something like this in /proc/iomem: 01100000-014fffff : System RAM 01100000-013bf48f : Kernel code 013bf490-0149e01f : Kernel data 01500000-0c0fffff : System RAM but the two System RAM ranges should be one single range. This particular case will result in kexec failure on Octeon systems if the kernel being loaded by kexec is bigger than the already running kernel. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org>
-
- Nov 23, 2012
-
-
Dave Martin authored
Modern GCC can generate code which makes use of the CPU's native unaligned memory access capabilities. This is useful for the C decompressor implementations used for unpacking compressed kernels. This patch disables alignment faults and enables the v6 unaligned access model on CPUs which support these features (i.e., v6 and later), allowing full unaligned access support for C code in the decompressor. The decompressor C code must not be built to assume that unaligned access works if support for v5 or older platforms is included in the kernel. For correct code generation, C decompressor code must always use the get_unaligned and put_unaligned accessors when dealing with unaligned pointers, regardless of this patch. Signed-off-by:
Dave Martin <dave.martin@linaro.org> Acked-by:
Nicolas Pitre <nico@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk>
-
Alexey Kardashevskiy authored
The new EEH code introduced a small regression, if the EEH PEs are missin (which happens currently in qemu for example), it will deref a NULL pointer in the MSI code. Signed-off-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
- Nov 22, 2012
-
-
Al Viro authored
int sys32_rt_sigprocmask(int how, compat_sigset_t __user *set, compat_sigset_t __user *oset, unsigned int sigsetsize) { sigset_t old_set, new_set; int ret; if (set && get_sigset32(set, &new_set, sigsetsize)) ... static int get_sigset32(compat_sigset_t __user *up, sigset_t *set, size_t sz) { compat_sigset_t s; int r; if (sz != sizeof *set) panic("put_sigset32()"); In other words, rt_sigprocmask(69, (void *)69, 69) done by 32bit process will promptly panic the box. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by:
James Bottomley <JBottomley@Parallels.com>
-
Arnd Bergmann authored
The ixp4xx queue manager uses "const struct qmgr_regs __iomem *" as the type for a pointer that is passed to __raw_writel, which is not allowed because of the const-ness. Dropping the 'const' keyword fixes the problem. While we're here, let's also drop the useless type cast. Without this patch, building ixp4xx_defconfig results in: In file included from arch/arm/mach-ixp4xx/ixp4xx_qmgr.c:15:0: arch/arm/mach-ixp4xx/include/mach/qmgr.h: In function 'qmgr_put_entry': arch/arm/mach-ixp4xx/include/mach/qmgr.h:96:2: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default] arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *' In file included from drivers/net/ethernet/xscale/ixp4xx_eth.c:41:0: arch/arm/mach-ixp4xx/include/mach/qmgr.h: In function 'qmgr_put_entry': arch/arm/mach-ixp4xx/include/mach/qmgr.h:96:2: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default] arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *' arch/arm/mach-ixp4xx/ixp4xx_qmgr.c: In function 'qmgr_set_irq': arch/arm/mach-ixp4xx/ixp4xx_qmgr.c:41:9: warning: passing argument 2 of '__raw_writel' discards 'const' qualifier from pointer target type [enabled by default] arch/arm/include/asm/io.h:88:91: note: expected 'volatile void *' but argument is of type 'const u32 *' Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Krzysztof Hałasa <khc@pm.waw.pl>
-
Krzysztof Hałasa authored
Signed-off-by:
Krzysztof Hałasa <khc@pm.waw.pl>
-
Krzysztof Hałasa authored
It doesn't make much sense to map QMgr dynamically - we almost always need it and the static mapping will be needed for little-endian data-coherent operation (to make QMgr region value-coherent). Signed-off-by:
Krzysztof Hałasa <khc@pm.waw.pl>
-
Tim Gardner authored
Cc: Krzysztof Halasa <khc@pm.waw.pl> Cc: Imre Kaloz <kaloz@openwrt.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Krzysztof Hałasa <khc@pm.waw.pl>
-
Krzysztof Hałasa authored
Signed-off-by:
Krzysztof Hałasa <khc@pm.waw.pl>
-
Krzysztof Hałasa authored
Signed-off-by:
Krzysztof Hałasa <khc@pm.waw.pl>
-
Krzysztof Hałasa authored
Signed-off-by:
Krzysztof Hałasa <khc@pm.waw.pl>
-
Igor Grinberg authored
Commit 97ee9f01 (ARM: OMAP: fix the ads7846 init code) have enabled the pendown GPIO debounce time setting by the below sequence: gpio_request_one() gpio_set_debounce() gpio_free() It also revealed a bug in the OMAP GPIO handling code which prevented the GPIO debounce clock to be disabled and CORE transition to low power states. Commit c9c55d92 (gpio/omap: fix off-mode bug: clear debounce settings on free/reset) fixes the OMAP GPIO handling code by making sure that the GPIO debounce clock gets disabled if no GPIO is requested from current bank. While fixing the OMAP GPIO handling code (in the right way), the above commit makes the gpio_request->set_debounce->free sequence invalid as after freeing the GPIO, the debounce settings are lost. Fix the debounce settings by moving the debounce initialization to the actual GPIO requesting code - the ads7846 driver. Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com>
-
Jason Gunthorpe authored
- The code relies on rc_pci_fixup being called, which only happens when CONFIG_PCI_QUIRKS is enabled, so add that to Kconfig. Omitting this causes a booting failure with a non-obvious cause. - Update rc_pci_fixup to set the class properly, copying the more modern style from other places - Correct the rc_pci_fixup comment Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Cc: stable@vger.kernel.org Signed-off-by:
Jason Cooper <jason@lakedaemon.net>
-
Russell King - ARM Linux authored
PMU interrupts start at IRQ_DOVE_PMU_START, not IRQ_DOVE_PMU_START + 1. Fix the condition. (It may have been less likely to occur had the code been written "if (irq >= IRQ_DOVE_PMU_START" which imho is the easier to understand notation, and matches the normal way of thinking about these things.) Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Cc: stable@vger.kernel.org Signed-off-by:
Jason Cooper <jason@lakedaemon.net>
-