linux-toradex.git/arch, branch v3.12.11

xtensa: xtfpga: fix definitions of platform devices

2014-02-13T21:50:14+00:00

commit a558d99263936b8a67d4eff8918745a77bfd8c31 upstream.

Remove __initdata attribute, as the devices may be used after init
sections are freed.

Signed-off-by: Max Filippov 
Signed-off-by: Greg Kroah-Hartman

tile: remove compat_sys_lookup_dcookie declaration to fix compile error

2014-02-13T21:50:14+00:00

commit 5a5e75f4714a592f31e57f248b8f5c866f278b8d upstream.

With commit d8d14bd09cdd ("fs/compat: fix lookup_dcookie() parameter
handling") I changed the type of the len parameter of the
lookup_dcookie() syscall.

However I missed that there was still a stale declaration in
arch/tile/..  which now causes a compile error on tile:

  In file included from fs/dcookies.c:28:0:
  include/linux/compat.h:425:17: error: conflicting types for 'compat_sys_lookup_dcookie'
  fs/dcookies.c:207:1: error: conflicting types for 'compat_sys_lookup_dcookie'

Simply remove the declaration in the tile architecture, which is only a
leftover from before the different compat lookup_dcookie() versions have
been merged.  The correct declaration is now in include/linux/compat.h

The build error was reported by Fenguang's build bot.

Signed-off-by: Heiko Carstens 
Acked-by: Chris Metcalf 
Signed-off-by: Linus Torvalds 
Cc: Guenter Roeck 
Signed-off-by: Greg Kroah-Hartman

ARM: mvebu: Fix kernel hang in mvebu_soc_id_init() when of_iomap failed

2014-02-13T21:50:13+00:00

commit dc4910d9e93f8cc56b190dd8fc9e789135978216 upstream.

When pci_base is accessed whereas it has not been properly mapped by
of_iomap() the kernel hang. The check of this pointer made an improper
use of IS_ERR() instead of comparing to NULL. This patch fix this
issue.

Signed-off-by: Gregory CLEMENT 
Reported-by: Ezequiel Garcia 
Fixes: 930ab3d403ae (i2c: mv64xxx: Add I2C Transaction Generator support)
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

ARM: orion: provide C-style interrupt handler for MULTI_IRQ_HANDLER

2014-02-13T21:50:12+00:00

commit f28d7de6bd4d41774744e011141945affa127da4 upstream.

DT-enabled Marvell Kirkwood and Dove SoCs make use of an irqchip
driver. As expected for irqchip drivers, it uses a C-style
interrupt handler and therefore selects MULTI_IRQ_HANDLER.

Now, compiling a kernel with both non-DT and DT support enabled,
selecting MULTI_IRQ_HANDLER will break ASM irq handler used by
non-DT boards.

Therefore, we provide a C-style irq handler even for non-DT boards,
if MULTI_IRQ_HANDLER is set. By installing the C-style irq handler
in orion_irq_init this is transparent to all non-DT board files.

While the regression report was filed on Marvell Kirkwood, also
Marvell Dove non-DT boards are affected and fixed by this patch.

Signed-off-by: Sebastian Hesselbarth 
Tested-by: Ian Campbell 
Reported-by: Ian Campbell 
Fixes: 2326f04321a9 ("ARM: kirkwood: convert to DT irqchip and clocksource")
Fixes: f07d73e33d0e ("ARM: dove: convert to DT irqchip and clocksource")
Acked-by: Andrew Lunn 
Signed-off-by: Jason Cooper 
Signed-off-by: Greg Kroah-Hartman

mm: don't lose the SOFT_DIRTY flag on mprotect

2014-02-13T21:50:12+00:00

commit 24f91eba18bbfdb27e71a1aae5b3a61b67fcd091 upstream.

The SOFT_DIRTY bit shows that the content of memory was changed after a
defined point in the past.  mprotect() doesn't change the content of
memory, so it must not change the SOFT_DIRTY bit.

This bug causes a malfunction: on the first iteration all pages are
dumped.  On other iterations only pages with the SOFT_DIRTY bit are
dumped.  So if the SOFT_DIRTY bit is cleared from a page by mistake, the
page is not dumped and its content will be restored incorrectly.

This patch does nothing with _PAGE_SWP_SOFT_DIRTY, becase pte_modify()
is called only for present pages.

Fixes commit 0f8975ec4db2 ("mm: soft-dirty bits for user memory changes
tracking").

Signed-off-by: Andrey Vagin 
Acked-by: Cyrill Gorcunov 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Pavel Emelyanov 
Cc: Borislav Petkov 
Cc: Wen Congyang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

xen/pvhvm: If xen_platform_pci=0 is set don't blow up (v4).

2014-02-13T21:50:10+00:00

commit 51c71a3bbaca868043cc45b3ad3786dd48a90235 upstream.

The user has the option of disabling the platform driver:
00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev 01)

which is used to unplug the emulated drivers (IDE, Realtek 8169, etc)
and allow the PV drivers to take over. If the user wishes
to disable that they can set:

  xen_platform_pci=0
  (in the guest config file)

or
  xen_emul_unplug=never
  (on the Linux command line)

except it does not work properly. The PV drivers still try to
load and since the Xen platform driver is not run - and it
has not initialized the grant tables, most of the PV drivers
stumble upon:

input: Xen Virtual Keyboard as /devices/virtual/input/input5
input: Xen Virtual Pointer as /devices/virtual/input/input6M
------------[ cut here ]------------
kernel BUG at /home/konrad/ssd/konrad/linux/drivers/xen/grant-table.c:1206!
invalid opcode: 0000 [#1] SMP
Modules linked in: xen_kbdfront(+) xenfs xen_privcmd
CPU: 6 PID: 1389 Comm: modprobe Not tainted 3.13.0-rc1upstream-00021-ga6c892b-dirty #1
Hardware name: Xen HVM domU, BIOS 4.4-unstable 11/26/2013
RIP: 0010:[]  [] get_free_entries+0x2e0/0x300
Call Trace:
 [] ? evdev_connect+0x1e3/0x240
 [] gnttab_grant_foreign_access+0x2e/0x70
 [] xenkbd_connect_backend+0x41/0x290 [xen_kbdfront]
 [] xenkbd_probe+0x2f2/0x324 [xen_kbdfront]
 [] xenbus_dev_probe+0x77/0x130
 [] xenbus_frontend_dev_probe+0x47/0x50
 [] driver_probe_device+0x89/0x230
 [] __driver_attach+0x9b/0xa0
 [] ? driver_probe_device+0x230/0x230
 [] ? driver_probe_device+0x230/0x230
 [] bus_for_each_dev+0x8c/0xb0
 [] driver_attach+0x19/0x20
 [] bus_add_driver+0x1a0/0x220
 [] driver_register+0x5f/0xf0
 [] xenbus_register_driver_common+0x15/0x20
 [] xenbus_register_frontend+0x23/0x40
 [] ? 0xffffffffa0014fff
 [] xenkbd_init+0x2b/0x1000 [xen_kbdfront]
 [] do_one_initcall+0x49/0x170

.. snip..

which is hardly nice. This patch fixes this by having each
PV driver check for:
 - if running in PV, then it is fine to execute (as that is their
   native environment).
 - if running in HVM, check if user wanted 'xen_emul_unplug=never',
   in which case bail out and don't load any PV drivers.
 - if running in HVM, and if PCI device 5853:0001 (xen_platform_pci)
   does not exist, then bail out and not load PV drivers.
 - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=ide-disks',
   then bail out for all PV devices _except_ the block one.
   Ditto for the network one ('nics').
 - (v2) if running in HVM, and if the user wanted 'xen_emul_unplug=unnecessary'
   then load block PV driver, and also setup the legacy IDE paths.
   In (v3) make it actually load PV drivers.

Reported-by: Sander Eikelenboom 
Reported-and-Tested-by: Fabio Fantoni 
Signed-off-by: Konrad Rzeszutek Wilk 
[v2: Add extra logic to handle the myrid ways 'xen_emul_unplug'
can be used per Ian and Stefano suggestion]
[v3: Make the unnecessary case work properly]
[v4: s/disks/ide-disks/ spotted by Fabio]
Reviewed-by: Stefano Stabellini 
Acked-by: Bjorn Helgaas  [for PCI parts]
Signed-off-by: Greg Kroah-Hartman

arch/sh/kernel/kgdb.c: add missing #include

2014-02-13T21:50:09+00:00

commit 53a52f17d96c8d47c79a7dafa81426317e89c7c1 upstream.

  arch/sh/kernel/kgdb.c: In function 'sleeping_thread_to_gdb_regs':
  arch/sh/kernel/kgdb.c:225:32: error: implicit declaration of function 'task_stack_page' [-Werror=implicit-function-declaration]
  arch/sh/kernel/kgdb.c:242:23: error: dereferencing pointer to incomplete type
  arch/sh/kernel/kgdb.c:243:22: error: dereferencing pointer to incomplete type
  arch/sh/kernel/kgdb.c: In function 'singlestep_trap_handler':
  arch/sh/kernel/kgdb.c:310:27: error: 'SIGTRAP' undeclared (first use in this function)
  arch/sh/kernel/kgdb.c:310:27: note: each undeclared identifier is reported only once for each function it appears in

This was introduced by commit 16559ae48c76 ("kgdb: remove #include
 from kgdb.h").

[geert@linux-m68k.org: reworded and reformatted]
Signed-off-by: Wanlong Gao 
Signed-off-by: Geert Uytterhoeven 
Reported-by: Fengguang Wu 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

x86, cpu, amd: Add workaround for family 16h, erratum 793

2014-02-06T19:22:22+00:00

commit 3b56496865f9f7d9bcb2f93b44c63f274f08e3b6 upstream.

This adds the workaround for erratum 793 as a precaution in case not
every BIOS implements it.  This addresses CVE-2013-6885.

Erratum text:

[Revision Guide for AMD Family 16h Models 00h-0Fh Processors,
document 51810 Rev. 3.04 November 2013]

793 Specific Combination of Writes to Write Combined Memory Types and
Locked Instructions May Cause Core Hang

Description

Under a highly specific and detailed set of internal timing
conditions, a locked instruction may trigger a timing sequence whereby
the write to a write combined memory type is not flushed, causing the
locked instruction to stall indefinitely.

Potential Effect on System

Processor core hang.

Suggested Workaround

BIOS should set MSR
C001_1020[15] = 1b.

Fix Planned

No fix planned

[ hpa: updated description, fixed typo in MSR name ]

Signed-off-by: Borislav Petkov 
Link: http://lkml.kernel.org/r/20140114230711.GS29865@pd.tnic
Tested-by: Aravind Gopalakrishnan 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

powerpc: Make sure "cache" directory is removed when offlining cpu

2014-02-06T19:22:22+00:00

commit 91b973f90c1220d71923e7efe1e61f5329806380 upstream.

The code in remove_cache_dir() is supposed to remove the "cache"
subdirectory from the sysfs directory for a CPU when that CPU is
being offlined.  It tries to do this by calling kobject_put() on
the kobject for the subdirectory.  However, the subdirectory only
gets removed once the last reference goes away, and the reference
being put here may well not be the last reference.  That means
that the "cache" subdirectory may still exist when the offlining
operation has finished.  If the same CPU subsequently gets onlined,
the code tries to add a new "cache" subdirectory.  If the old
subdirectory has not yet been removed, we get a WARN_ON in the
sysfs code, with stack trace, and an error message printed on the
console.  Further, we ultimately end up with an online cpu with no
"cache" subdirectory.

This fixes it by doing an explicit kobject_del() at the point where
we want the subdirectory to go away.  kobject_del() removes the sysfs
directory even though the object still exists in memory.  The object
will get freed at some point in the future.  A subsequent onlining
operation can create a new sysfs directory, even if the old object
still exists in memory, without causing any problems.

Signed-off-by: Paul Mackerras 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc: Fix the setup of CPU-to-Node mappings during CPU online

2014-02-06T19:22:22+00:00

commit d4edc5b6c480a0917e61d93d55531d7efa6230be upstream.

On POWER platforms, the hypervisor can notify the guest kernel about dynamic
changes in the cpu-numa associativity (VPHN topology update). Hence the
cpu-to-node mappings that we got from the firmware during boot, may no longer
be valid after such updates. This is handled using the arch_update_cpu_topology()
hook in the scheduler, and the sched-domains are rebuilt according to the new
mappings.

But unfortunately, at the moment, CPU hotplug ignores these updated mappings
and instead queries the firmware for the cpu-to-numa relationships and uses
them during CPU online. So the kernel can end up assigning wrong NUMA nodes
to CPUs during subsequent CPU hotplug online operations (after booting).

Further, a particularly problematic scenario can result from this bug:
On POWER platforms, the SMT mode can be switched between 1, 2, 4 (and even 8)
threads per core. The switch to Single-Threaded (ST) mode is performed by
offlining all except the first CPU thread in each core. Switching back to
SMT mode involves onlining those other threads back, in each core.

Now consider this scenario:

1. During boot, the kernel gets the cpu-to-node mappings from the firmware
   and assigns the CPUs to NUMA nodes appropriately, during CPU online.

2. Later on, the hypervisor updates the cpu-to-node mappings dynamically and
   communicates this update to the kernel. The kernel in turn updates its
   cpu-to-node associations and rebuilds its sched domains. Everything is
   fine so far.

3. Now, the user switches the machine from SMT to ST mode (say, by running
   ppc64_cpu --smt=1). This involves offlining all except 1 thread in each
   core.

4. The user then tries to switch back from ST to SMT mode (say, by running
   ppc64_cpu --smt=4), and this involves onlining those threads back. Since
   CPU hotplug ignores the new mappings, it queries the firmware and tries to
   associate the newly onlined sibling threads to the old NUMA nodes. This
   results in sibling threads within the same core getting associated with
   different NUMA nodes, which is incorrect.

   The scheduler's build-sched-domains code gets thoroughly confused with this
   and enters an infinite loop and causes soft-lockups, as explained in detail
   in commit 3be7db6ab (powerpc: VPHN topology change updates all siblings).

So to fix this, use the numa_cpu_lookup_table to remember the updated
cpu-to-node mappings, and use them during CPU hotplug online operations.
Further, we also need to ensure that all threads in a core are assigned to a
common NUMA node, irrespective of whether all those threads were online during
the topology update. To achieve this, we take care not to use cpu_sibling_mask()
since it is not hotplug invariant. Instead, we use cpu_first_sibling_thread()
and set up the mappings manually using the 'threads_per_core' value for that
particular platform. This helps us ensure that we don't hit this bug with any
combination of CPU hotplug and SMT mode switching.

Signed-off-by: Srivatsa S. Bhat 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman