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: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reported-by: NAl Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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: NVincent Palatin <vpalatin@chromium.org>
Link: http://lkml.kernel.org/r/1354306532-1014-1-git-send-email-vpalatin@chromium.orgSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

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: NAl Viro <viro@zeniv.linux.org.uk>

do_sigaltstack() expects _userland_ address, TYVM...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

... or we'll end up buggering the results of ELF_PLAT_INIT()
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

Signed-off-by: NMark Salter <msalter@redhat.com>

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: NMark Salter <msalter@redhat.com>

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: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NH. Peter Anvin <hpa@linux.intel.com>

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: NMelanie Blower <melanie.blower@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/B3584E72CFEBED439A3ECA9BCE67A4EF1B17AF90@FMSMSX107.amr.corp.intel.comReviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Acked-by: NMarcelo Tosatti <mtosatti@redhat.com>

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: NMark Salter <msalter@redhat.com>

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: NMark Salter <msalter@redhat.com>

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: NGavin Shan <shangw@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

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: NAndreas Larsson <andreas@gaisler.com>
Acked-by: NDavid Miller <davem@davemloft.net>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>

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: NAl Cooper <alcooperx@gmail.com>
Reviewed-by: NDavid Daney <david.daney@cavium.com>
Pathchwork: https://patchwork.linux-mips.org/patch/4564/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

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: NRalf Baechle <ralf@linux-mips.org>

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: NDave Martin <dave.martin@linaro.org>
Acked-by: NNicolas Pitre <nico@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

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: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

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: NAl Viro <viro@zeniv.linux.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>

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: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>

Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>

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: NKrzysztof Hałasa <khc@pm.waw.pl>

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: NTim Gardner <tim.gardner@canonical.com>
Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>

Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>

Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>

Signed-off-by: NKrzysztof Hałasa <khc@pm.waw.pl>

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: NIgor Grinberg <grinberg@compulab.co.il>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

- 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: NJason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: stable@vger.kernel.org
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

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: NRussell King <rmk+kernel@arm.linux.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Fix the acknowledgement of PMU interrupts on Dove: some Dove hardware
has not been sensibly designed so that interrupts can be handled in a
race free manner.  The PMU is one such instance.

The pending (aka 'cause') register is a bunch of RW bits, meaning that
these bits can be both cleared and set by software (confirmed on the
Armada-510 on the cubox.)

Hardware sets the appropriate bit when an interrupt is asserted, and
software is required to clear the bits which are to be processed.  If
we write ~(1 << bit), then we end up asserting every other interrupt
except the one we're processing.  So, we need to do a read-modify-write
cycle to clear the asserted bit.

However, any interrupts which occur in the middle of this cycle will
also be written back as zero, which will also clear the new interrupts.

The upshot of this is: there is _no_ way to safely clear down interrupts
in this register (and other similarly behaving interrupt pending
registers on this device.)  The patch below at least stops us creating
new interrupts.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Cc: stable@vger.kernel.org
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

chan->end is tested for being NULL. However in the event that it is NULL, the
subsequent assignment statement would lead to NULL pointer dereference.
Thus dereferencing it only when it is not NULL.
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>

While these got added in the right place everywhere else, entry_64.S
is the odd one where they ended up before the initial CFI directive(s).
In order to cover the full code ranges, the CFI directive must be
first, though.
Signed-off-by: NJan Beulich <jbeulich@suse.com>
Link: http://lkml.kernel.org/r/5093BA1F02000078000A600E@nat28.tlf.novell.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

Add valid patch size for family 16h processors.

[ hpa: promoting to urgent/stable since it is hw enabling and trivial ]
Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@amd.com>
Acked-by: NAndreas Herrmann <herrmann.der.user@googlemail.com>
Link: http://lkml.kernel.org/r/1353004910-2204-1-git-send-email-boris.ostrovsky@amd.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org>

Modules, in particular oprofile (and possibly other similar tools)
need kernel_stack_pointer(), so export it using EXPORT_SYMBOL_GPL().

Cc: Yang Wei <wei.yang@windriver.com>
Cc: Robert Richter <robert.richter@amd.com>
Cc: Jun Zhang <jun.zhang@intel.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>

In 32 bit the stack address provided by kernel_stack_pointer() may
point to an invalid range causing NULL pointer access or page faults
while in NMI (see trace below). This happens if called in softirq
context and if the stack is empty. The address at &regs->sp is then
out of range.

Fixing this by checking if regs and &regs->sp are in the same stack
context. Otherwise return the previous stack pointer stored in struct
thread_info. If that address is invalid too, return address of regs.

 BUG: unable to handle kernel NULL pointer dereference at 0000000a
 IP: [<c1004237>] print_context_stack+0x6e/0x8d
 *pde = 00000000
 Oops: 0000 [#1] SMP
 Modules linked in:
 Pid: 4434, comm: perl Not tainted 3.6.0-rc3-oprofile-i386-standard-g4411a05 #4 Hewlett-Packard HP xw9400 Workstation/0A1Ch
 EIP: 0060:[<c1004237>] EFLAGS: 00010093 CPU: 0
 EIP is at print_context_stack+0x6e/0x8d
 EAX: ffffe000 EBX: 0000000a ECX: f4435f94 EDX: 0000000a
 ESI: f4435f94 EDI: f4435f94 EBP: f5409ec0 ESP: f5409ea0
  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
 CR0: 8005003b CR2: 0000000a CR3: 34ac9000 CR4: 000007d0
 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
 DR6: ffff0ff0 DR7: 00000400
 Process perl (pid: 4434, ti=f5408000 task=f5637850 task.ti=f4434000)
 Stack:
  000003e8 ffffe000 00001ffc f4e39b00 00000000 0000000a f4435f94 c155198c
  f5409ef0 c1003723 c155198c f5409f04 00000000 f5409edc 00000000 00000000
  f5409ee8 f4435f94 f5409fc4 00000001 f5409f1c c12dce1c 00000000 c155198c
 Call Trace:
  [<c1003723>] dump_trace+0x7b/0xa1
  [<c12dce1c>] x86_backtrace+0x40/0x88
  [<c12db712>] ? oprofile_add_sample+0x56/0x84
  [<c12db731>] oprofile_add_sample+0x75/0x84
  [<c12ddb5b>] op_amd_check_ctrs+0x46/0x260
  [<c12dd40d>] profile_exceptions_notify+0x23/0x4c
  [<c1395034>] nmi_handle+0x31/0x4a
  [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [<c13950ed>] do_nmi+0xa0/0x2ff
  [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [<c13949e5>] nmi_stack_correct+0x28/0x2d
  [<c1029dc5>] ? ftrace_define_fields_irq_handler_entry+0x45/0x45
  [<c1003603>] ? do_softirq+0x4b/0x7f
  <IRQ>
  [<c102a06f>] irq_exit+0x35/0x5b
  [<c1018f56>] smp_apic_timer_interrupt+0x6c/0x7a
  [<c1394746>] apic_timer_interrupt+0x2a/0x30
 Code: 89 fe eb 08 31 c9 8b 45 0c ff 55 ec 83 c3 04 83 7d 10 00 74 0c 3b 5d 10 73 26 3b 5d e4 73 0c eb 1f 3b 5d f0 76 1a 3b 5d e8 73 15 <8b> 13 89 d0 89 55 e0 e8 ad 42 03 00 85 c0 8b 55 e0 75 a6 eb cc
 EIP: [<c1004237>] print_context_stack+0x6e/0x8d SS:ESP 0068:f5409ea0
 CR2: 000000000000000a
 ---[ end trace 62afee3481b00012 ]---
 Kernel panic - not syncing: Fatal exception in interrupt

V2:
* add comments to kernel_stack_pointer()
* always return a valid stack address by falling back to the address
  of regs
Reported-by: NYang Wei <wei.yang@windriver.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Link: http://lkml.kernel.org/r/20120912135059.GZ8285@erda.amd.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: Jun Zhang <jun.zhang@intel.com>