linux.git/arch, branch v3.13.3

powerpc/mm: Fix compile error of pgtable-ppc64.h

2014-02-13T21:55:45+00:00

commit fd120dc2e205d2318a8b47d6d8098b789e3af67d upstream.

It seems that forward declaration couldn't work well with typedef, use
struct spinlock directly to avoiding following build errors:

In file included from include/linux/spinlock.h:81,
                 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:17,
                 from arch/powerpc/kernel/asm-offsets.c:17:
include/linux/spinlock_types.h:76: error: redefinition of typedef 'spinlock_t'
/root/linux-next/arch/powerpc/include/asm/pgtable-ppc64.h:563: note: previous declaration of 'spinlock_t' was here

Signed-off-by: Li Zhong 
Signed-off-by: Aneesh Kumar K.V 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

powerpc/thp: Fix crash on mremap

2014-02-13T21:55:44+00:00

commit b3084f4db3aeb991c507ca774337c7e7893ed04f upstream.

This patch fix the below crash

NIP [c00000000004cee4] .__hash_page_thp+0x2a4/0x440
LR [c0000000000439ac] .hash_page+0x18c/0x5e0
...
Call Trace:
[c000000736103c40] [00001ffffb000000] 0x1ffffb000000(unreliable)
[437908.479693] [c000000736103d50] [c0000000000439ac] .hash_page+0x18c/0x5e0
[437908.479699] [c000000736103e30] [c00000000000924c] .do_hash_page+0x4c/0x58

On ppc64 we use the pgtable for storing the hpte slot information and
store address to the pgtable at a constant offset (PTRS_PER_PMD) from
pmd. On mremap, when we switch the pmd, we need to withdraw and deposit
the pgtable again, so that we find the pgtable at PTRS_PER_PMD offset
from new pmd.

We also want to move the withdraw and deposit before the set_pmd so
that, when page fault find the pmd as trans huge we can be sure that
pgtable can be located at the offset.

Signed-off-by: Aneesh Kumar K.V 
Acked-by: Kirill A. Shutemov 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

xtensa: xtfpga: fix definitions of platform devices

2014-02-13T21:55:32+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:55:31+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:55:30+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:55:30+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:55:29+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:55:28+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:55:27+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:34:12+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