The expected logic of proc_map_files_get_link() is either to return 0
and initialize 'path' or return an error and leave 'path' uninitialized.

By the time dname_to_vma_addr() returns 0 the corresponding vma may have
already be gone.  In this case the path is not initialized but the
return value is still 0.  This results in 'general protection fault'
inside d_path().

Steps to reproduce:

  CONFIG_CHECKPOINT_RESTORE=y

    fd = open(...);
    while (1) {
        mmap(fd, ...);
        munmap(fd, ...);
    }

  ls -la /proc/$PID/map_files

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=68991Signed-off-by: NArtem Fetishev <artem_fetishev@epam.com>
Signed-off-by: NAleksandr Terekhov <aleksandr_terekhov@epam.com>
Reported-by: <wiebittewas@gmail.com>
Acked-by: NPavel Emelyanov <xemul@parallels.com>
Acked-by: NCyrill Gorcunov <gorcunov@openvz.org>
Reviewed-by: N"Eric W. Biederman" <ebiederm@xmission.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We received several reports of bad page state when freeing CMA pages
previously allocated with alloc_contig_range:

    BUG: Bad page state in process Binder_A  pfn:63202
    page:d21130b0 count:0 mapcount:1 mapping:  (null) index:0x7dfbf
    page flags: 0x40080068(uptodate|lru|active|swapbacked)

Based on the page state, it looks like the page was still in use.  The
page flags do not make sense for the use case though.  Further debugging
showed that despite alloc_contig_range returning success, at least one
page in the range still remained in the buddy allocator.

There is an issue with isolate_freepages_block.  In strict mode (which
CMA uses), if any pages in the range cannot be isolated,
isolate_freepages_block should return failure 0.  The current check
keeps track of the total number of isolated pages and compares against
the size of the range:

        if (strict && nr_strict_required > total_isolated)
                total_isolated = 0;

After taking the zone lock, if one of the pages in the range is not in
the buddy allocator, we continue through the loop and do not increment
total_isolated.  If in the last iteration of the loop we isolate more
than one page (e.g.  last page needed is a higher order page), the check
for total_isolated may pass and we fail to detect that a page was
skipped.  The fix is to bail out if the loop immediately if we are in
strict mode.  There's no benfit to continuing anyway since we need all
pages to be isolated.  Additionally, drop the error checking based on
nr_strict_required and just check the pfn ranges.  This matches with
what isolate_freepages_range does.
Signed-off-by: NLaura Abbott <lauraa@codeaurora.org>
Acked-by: NMinchan Kim <minchan@kernel.org>
Cc: Mel Gorman <mgorman@suse.de>
Acked-by: NVlastimil Babka <vbabka@suse.cz>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Acked-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: NMichal Nazarewicz <mina86@mina86.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

GFP_THISNODE is for callers that implement their own clever fallback to
remote nodes.  It restricts the allocation to the specified node and
does not invoke reclaim, assuming that the caller will take care of it
when the fallback fails, e.g.  through a subsequent allocation request
without GFP_THISNODE set.

However, many current GFP_THISNODE users only want the node exclusive
aspect of the flag, without actually implementing their own fallback or
triggering reclaim if necessary.  This results in things like page
migration failing prematurely even when there is easily reclaimable
memory available, unless kswapd happens to be running already or a
concurrent allocation attempt triggers the necessary reclaim.

Convert all callsites that don't implement their own fallback strategy
to __GFP_THISNODE.  This restricts the allocation a single node too, but
at the same time allows the allocator to enter the slowpath, wake
kswapd, and invoke direct reclaim if necessary, to make the allocation
happen when memory is full.
Signed-off-by: NJohannes Weiner <hannes@cmpxchg.org>
Acked-by: NRik van Riel <riel@redhat.com>
Cc: Jan Stancek <jstancek@redhat.com>
Cc: Mel Gorman <mgorman@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull ARM SoC fixes from from Olof Johansson:
 "A collection of fixes for ARM platforms.  A little large due to us
  missing to do one last week, but there's nothing in particular here
  that is in itself large and scary.

  Mostly a handful of smaller fixes all over the place.  The majority is
  made up of fixes for OMAP, but there are a few for others as well.  In
  particular, there was a decision to rename a binding for the Broadcom
  pinctrl block that we need to go in before the final release since we
  then treat it as ABI"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid problems with booting
  ARM: tegra: add LED options back into tegra_defconfig
  ARM: dts: omap3-igep: fix boot fail due wrong compatible match
  ARM: OMAP3: Fix pinctrl interrupts for core2
  pinctrl: Rename Broadcom Capri pinctrl binding
  pinctrl: refer to updated dt binding string.
  Update dtsi with new pinctrl compatible string
  ARM: OMAP: Kill warning in CPUIDLE code with !CONFIG_SMP
  ARM: OMAP2+: Add support for thumb mode on DT booted N900
  ARM: OMAP2+: clock: fix clkoutx2 with CLK_SET_RATE_PARENT
  ARM: OMAP4: hwmod: Fix SOFTRESET logic for OMAP4
  ARM: DRA7: hwmod data: correct the sysc data for spinlock
  ARM: OMAP5: PRM: Fix reboot handling
  ARM: sunxi: dt: Change the touchscreen compatibles
  ARM: sun7i: dt: Fix interrupt trigger types

Pull NFS client bugfixes from Trond Myklebust:
 "Highlights include:

   - Fix another nfs4_sequence corruptor in RELEASE_LOCKOWNER
   - Fix an Oopsable delegation callback race
   - Fix another bad stateid infinite loop
   - Fail the data server I/O is the stateid represents a lost lock
   - Fix an Oopsable sunrpc trace event"

* tag 'nfs-for-3.14-5' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
  SUNRPC: Fix oops when trace sunrpc_task events in nfs client
  NFSv4: Fail the truncate() if the lock/open stateid is invalid
  NFSv4.1 Fail data server I/O if stateid represents a lost lock
  NFSv4: Fix the return value of nfs4_select_rw_stateid
  NFSv4: nfs4_stateid_is_current should return 'true' for an invalid stateid
  NFS: Fix a delegation callback race
  NFSv4: Fix another nfs4_sequence corruptor

Pull USB fixes from Greg KH:
 "Here are 4 USB fixes for your current tree.

  Two of them are reverts to hopefully resolve the nasty XHCI
  regressions we have been having on some types of devices.  The other
  two are quirks for some Logitech video devices"

* tag 'usb-3.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma"
  Revert "xhci 1.0: Limit arbitrarily-aligned scatter gather."
  usb: Make DELAY_INIT quirk wait 100ms between Get Configuration requests
  usb: Add device quirk for Logitech HD Pro Webcams C920 and C930e

Pull staging driver tree fix from Greg KH:
 "Here is a single staging driver fix for your tree.

  It resolves an issue with arbritary writes to memory if a specific
  driver is loaded"

* tag 'staging-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging/cxt1e1/linux.c: Correct arbitrary memory write in c4_ioctl()

This fixes CVE-2014-0102.

The following command sequence produces an oops:

	keyctl new_session
	i=`keyctl newring _ses @s`
	keyctl link @s $i

The problem is that search_nested_keyrings() sees two keyrings that have
matching type and description, so keyring_compare_object() returns true.
s_n_k() then passes the key to the iterator function -
keyring_detect_cycle_iterator() - which *should* check to see whether this is
the keyring of interest, not just one with the same name.

Because assoc_array_find() will return one and only one match, I assumed that
the iterator function would only see an exact match or never be called - but
the iterator isn't only called from assoc_array_find()...

The oops looks something like this:

	kernel BUG at /data/fs/linux-2.6-fscache/security/keys/keyring.c:1003!
	invalid opcode: 0000 [#1] SMP
	...
	RIP: keyring_detect_cycle_iterator+0xe/0x1f
	...
	Call Trace:
	  search_nested_keyrings+0x76/0x2aa
	  __key_link_check_live_key+0x50/0x5f
	  key_link+0x4e/0x85
	  keyctl_keyring_link+0x60/0x81
	  SyS_keyctl+0x65/0xe4
	  tracesys+0xdd/0xe2

The fix is to make keyring_detect_cycle_iterator() check that the key it
has is the key it was actually looking for rather than calling BUG_ON().

A testcase has been included in the keyutils testsuite for this:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=891f3365d07f1996778ade0e3428f01878a1790bReported-by: NTommi Rantala <tt.rantala@gmail.com>
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Acked-by: NJames Morris <james.l.morris@oracle.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull thermal fixes from Zhang Rui:
 "Specifics:

   - Update the help text of INT3403 Thermal driver, which was not
     friendly to users.  From Zhang Rui.

   - The "type" sysfs attribute of x86_pkg_temp_thermal registered
     thermal zones includes an instance number, which makes the
     thermal-to-hwmon bridge fails to group them all in a single hwmon
     device.  Fixed by Jean Delvare.

   - The hwmon device registered by x86_pkg_temp_thermal driver is
     redundant because the temperature value reported by
     x86_pkg_temp_thermal is already reported by the coretemp driver.
     Fixed by Jean Delvare.

   - Fix a problem that the cooling device can not be updated properly
     if it is initialized at max cooling state.  From Ni Wade.

   - Fix a problem that OF registered thermal zones are running without
     thermal governors.  From Zhang Rui.

   - Commit beeb5a1e ("thermal: rcar-thermal: Enable driver
     compilation with COMPILE_TEST") broke build on archs wihout io
     memory.  Thus make it depend on HAS_IOMEM to bypass build failures.
     Fixed by Richard Weinberger"

* 'for-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
  Thermal: thermal zone governor fix
  Thermal: Allow first update of cooling device state
  thermal,rcar_thermal: Add dependency on HAS_IOMEM
  x86_pkg_temp_thermal: Fix the thermal zone type
  x86_pkg_temp_thermal: Do not expose as a hwmon device
  Thermal: update INT3404 thermal driver help text

Pull spi fixes from Mark Brown:
 "A scattering of driver specific fixes here.

  The fixes from Axel cover bitrot in apparently unmaintained drivers,
  the at79 bug is fixing a glitch on /CS during initialisation of some
  devices which could break some slaves and the remainder are fixes for
  recently introduced bugs from the past release cycle or so"

* tag 'spi-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
  spi: atmel: add missing spi_master_{resume,suspend} calls to PM callbacks
  spi: coldfire-qspi: Fix getting correct address for *mcfqspi
  spi: fsl-dspi: Fix getting correct address for master
  spi: spi-ath79: fix initial GPIO CS line setup
  spi: spi-imx: spi_imx_remove: do not disable disabled clocks
  spi-topcliff-pch: Fix probing when DMA mode is used
  spi/topcliff-pch: Fix DMA channel

Pull SCSI target fixes from Nicholas Bellinger:
 "This series addresses a number of outstanding issues wrt to active I/O
  shutdown using iser-target.  This includes:

   - Fix a long standing tpg_state bug where a tpg could be referenced
     during explicit shutdown (v3.1+ stable)
   - Use list_del_init for iscsi_cmd->i_conn_node so list_empty checks
     work as expected (v3.10+ stable)
   - Fix a isert_conn->state related hung task bug + ensure outstanding
     I/O completes during session shutdown.  (v3.10+ stable)
   - Fix isert_conn->post_send_buf_count accounting for RDMA READ/WRITEs
     (v3.10+ stable)
   - Ignore FRWR completions during active I/O shutdown (v3.12+ stable)
   - Fix command leakage for interrupt coalescing during active I/O
     shutdown (v3.13+ stable)

  Also included is another DIF emulation fix from Sagi specific to
  v3.14-rc code"

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  Target/sbc: Fix sbc_copy_prot for offset scatters
  iser-target: Fix command leak for tx_desc->comp_llnode_batch
  iser-target: Ignore completions for FRWRs in isert_cq_tx_work
  iser-target: Fix post_send_buf_count for RDMA READ/WRITE
  iscsi/iser-target: Fix isert_conn->state hung shutdown issues
  iscsi/iser-target: Use list_del_init for ->i_conn_node
  iscsi-target: Fix iscsit_get_tpg_from_np tpg_state bug

Revert commit 3130497f ("ACPI / sleep: pm_power_off needs more
sanity checks to be installed") that breaks power ACPI power off on a
lot of systems, because it checks wrong registers.

Fixes: 3130497f ("ACPI / sleep: pm_power_off needs more sanity checks to be installed")
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Merge tag 'omap-for-v3.14/fixes-dt-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

From Tony Lindgren:

Two omap3430 vs 3630 device tree regression fixes for
issues booting 3430 based boards.

* tag 'omap-for-v3.14/fixes-dt-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: dts: omap3-gta04: Add ti,omap36xx to compatible property to avoid problems with booting
  ARM: dts: omap3-igep: fix boot fail due wrong compatible match
Signed-off-by: NOlof Johansson <olof@lixom.net>

Merge 'bcm pinctrl rename' From Christin Daudt:

Rename pinctrl dt binding to restore consistency with other bcm mobile
bindings.

* tag 'bcm-for-3.14-pinctrl-reduced-rename' of git://github.com/broadcom/bcm11351:
  pinctrl: Rename Broadcom Capri pinctrl binding
  pinctrl: refer to updated dt binding string.
  Update dtsi with new pinctrl compatible string
  + Linux 3.14-rc4
Signed-off-by: NOlof Johansson <olof@lixom.net>

Allwinner fixes from Maxime Ripard:

Two fixes for device trees additions that got added in 3.14. One fixes the
interrupt types of some IPs, the other fixes up a compatible that got
introduced during 3.14

* tag 'sunxi-fixes-for-3.14' of https://github.com/mripard/linux:
  ARM: sunxi: dt: Change the touchscreen compatibles
  ARM: sun7i: dt: Fix interrupt trigger types
Signed-off-by: NOlof Johansson <olof@lixom.net>

Pull cgroup fixes from Tejun Heo:
 "Two cpuset locking fixes from Li.  Both tagged for -stable"

* 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cpuset: fix a race condition in __cpuset_node_allowed_softwall()
  cpuset: fix a locking issue in cpuset_migrate_mm()

Pull libata fixes from Tejun Heo:
 "Just a couple patches blacklisting more broken devices"

* 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8 (2BA30001)
  libata: disable queued TRIM for Crucial M500 mSATA SSDs

Pull workqueue fix from Tejun Heo:
 "This pull request contains a workqueue usage fix for firewire.

  For quite a long time now, workqueue only treats two work items
  identical iff both their addresses and callbacks match.  This is to
  avoid introducing false dependency through the work item being
  recycled while being executed.  This changes non-reentrancy guarantee
  for the users of PREPARE[_DELAYED]_WORK() - if the function changes,
  reentrancy isn't guaranteed against the previous instance.  Firewire
  depended on such nonreentrancy guarantee.

  This is fixed by doing the work item multiplexing from firewire proper
  while keeping the work function unchanged"

* 'for-3.14-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
  firewire: don't use PREPARE_DELAYED_WORK

Pull firewire fixes from Stefan Richter:
 "Fix a use-after-free regression since v3.4 and an initialization
  regression since v3.10"

* tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
  firewire: ohci: fix probe failure with Agere/LSI controllers
  firewire: net: fix use after free

Pull clk driver fix from Mike Turquette:
 "Single fix for a clock driver merged in 3.14-rc1.  Without this fix
  the CPU frequency cannot be scaled"

* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
  clk: shmobile: rcar-gen2: Use kick bit to allow Z clock frequency change

Pull ACPI and power management fixes from Rafael Wysocki:

 - ACPI tables in some BIOSes list device resources with size equal to
   0, which doesn't make sense, so we should ignore them, but instead we
   try to use them and mangle things completely.  Fix from Zhang Rui.

 - Several models of Samsung laptops accumulate EC events when they are
   in sleep states which leads to EC buffer overflows that prevent new
   events from being signaled after system resume or reboot.  This has
   been affecting many users for quite a while and may be addressed by
   clearing the EC buffer during system resume and system startup on
   those machines.  From Kieran Clancy.

 - If the ACPI sleep control and status registers are not present (which
   happens if the Hardware Reduced ACPI mode bit is set in the ACPI
   tables, but also may result from BIOS bugs), we should not try to use
   ACPI to power off the system and ACPI S5 should not be listed as
   supported.  Fix from Aubrey Li.

 - There's a race condition in cpufreq_get() that leads to a kernel
   crash if that function is called at a wrong time.  Fix from Aaron
   Plattner.

 - cpufreq policy objects have to be initialized entirely before they
   are first accessed by their users which isn't the case currently and
   that potentially leads to various kinds of breakage that is difficult
   to debug.  Fix from Viresh Kumar.

 - Locking is missing in __cpufreq_add_dev() which leads to a race
   condition that may trigger a kernel crash.  Fix from Viresh Kumar.

* tag 'pm+acpi-3.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / EC: Clear stale EC events on Samsung systems
  cpufreq: Initialize governor for a new policy under policy->rwsem
  cpufreq: Initialize policy before making it available for others to use
  cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditions
  ACPI / sleep: pm_power_off needs more sanity checks to be installed
  ACPI / resources: ignore invalid ACPI device resources

It's an enum, not a #define, you can't use it in asm files.

Introduced in commit 5fa10196 ("x86: Ignore NMIs that come in during
early boot"), and sadly I didn't compile-test things like I should have
before pushing out.

My weak excuse is that the x86 tree generally doesn't introduce stupid
things like this (and the ARM pull afterwards doesn't cause me to do a
compile-test either, since I don't cross-compile).

Cc: Don Zickus <dzickus@redhat.com>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Pull ARM fixes from Russell King:
 "A number of ARM updates for -rc, covering mostly ARM specific code,
  but with one change to modpost.c to allow Thumb section mismatches to
  be detected.

  ARM changes include reporting when an attempt is made to boot a LPAE
  kernel on hardware which does not support LPAE, rather than just being
  silent about it.

  A number of other minor fixes are included too"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 7992/1: boot: compressed: ignore bswapsdi2.S
  ARM: 7991/1: sa1100: fix compile problem on Collie
  ARM: fix noMMU kallsyms symbol filtering
  ARM: 7980/1: kernel: improve error message when LPAE config doesn't match CPU
  ARM: 7964/1: Detect section mismatches in thumb relocations
  ARM: 7963/1: mm: report both sections from PMD

Pull x86 fixes from Peter Anvin:
 "A small collection of minor fixes.  The FPU stuff is still pending, I
  fear.  I haven't heard anything from Suresh so I suspect I'm going to
  have to dig into the init specifics myself and fix up the patchset"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86: Ignore NMIs that come in during early boot
  x86, trace: Further robustify CR2 handling vs tracing
  x86, trace: Fix CR2 corruption when tracing page faults
  x86/efi: Quirk out SGI UV

Pull power fixes from Ben Herrenschmidt:
 "Here are a couple of powerpc fixes for 3.14.

  One is (another!) nasty TM problem, we can crash the kernel by forking
  inside a transaction.  The other one is a simple fix for an alignment
  issue which can hurt in LE mode"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: Align p_dyn, p_rela and p_st symbols
  powerpc/tm: Fix crash when forking inside a transaction

Merge tag 'trace-fixes-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

Pull tracing fix from Steven Rostedt:
 "In the past, I've had lots of reports about trace events not working.
  Developers would say they put a trace_printk() before and after the
  trace event but when they enable it (and the trace event said it was
  enabled) they would see the trace_printks but not the trace event.

  I was not able to reproduce this, but that's because I wasn't looking
  at the right location.  Recently, another bug came up that showed the
  issue.

  If your kernel supports signed modules but allows for non-signed
  modules to be loaded, then when one is, the kernel will silently set
  the MODULE_FORCED taint on the module.  Although, this taint happens
  without the need for insmod --force or anything of the kind, it labels
  the module with that taint anyway.

  If this tainted module has tracepoints, the tracepoints will be
  ignored because of the MODULE_FORCED taint.  But no error message will
  be displayed.  Worse yet, the event infrastructure will still be
  created letting users enable the trace event represented by the
  tracepoint, although that event will never actually be enabled.  This
  is because the tracepoint infrastructure allows for non-existing
  tracepoints to be enabled for new modules to arrive and have their
  tracepoints set.

  Although there are several things wrong with the above, this change
  only addresses the creation of the trace event files for tracepoints
  that are not created when a module is loaded and is tainted.  This
  change will print an error message about the module being tainted and
  not the trace events will not be created, and it does not create the
  trace event infrastructure"

* tag 'trace-fixes-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Do not add event files for modules that fail tracepoints

Pull irq fixes from Thomas Gleixner:
 - a bugfix for a long standing waitqueue race
 - a trivial fix for a missing include

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  genirq: Include missing header file in irqdomain.c
  genirq: Remove racy waitqueue_active check

When tracking sunrpc_task events in nfs client, the clnt pointer may be NULL.

[  139.269266] BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
[  139.269915] IP: [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
[  139.269915] PGD 1d293067 PUD 1d294067 PMD 0
[  139.269915] Oops: 0000 [#1] SMP
[  139.269915] Modules linked in: nfsv4 dns_resolver nfs lockd sunrpc fscache sg ppdev e1000
serio_raw pcspkr parport_pc parport i2c_piix4 i2c_core microcode xfs libcrc32c sd_mod sr_mod
cdrom ata_generic crc_t10dif crct10dif_common pata_acpi ahci libahci ata_piix libata dm_mirror
dm_region_hash dm_log dm_mod
[  139.269915] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 3.10.0-84.el7.x86_64 #1
[  139.269915] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[  139.269915] Workqueue: rpciod rpc_async_schedule [sunrpc]
[  139.269915] task: ffff88001b598000 ti: ffff88001b632000 task.ti: ffff88001b632000
[  139.269915] RIP: 0010:[<ffffffffa026f216>]  [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
[  139.269915] RSP: 0018:ffff88001b633d70  EFLAGS: 00010206
[  139.269915] RAX: ffff88001dfc5338 RBX: ffff88001cc37a00 RCX: ffff88001dfc5334
[  139.269915] RDX: ffff88001dfc5338 RSI: 0000000000000000 RDI: ffff88001dfc533c
[  139.269915] RBP: ffff88001b633db0 R08: 000000000000002c R09: 000000000000000a
[  139.269915] R10: 0000000000062180 R11: 00000020759fb9dc R12: ffffffffa0292c20
[  139.269915] R13: ffff88001dfc5334 R14: 0000000000000000 R15: 0000000000000000
[  139.269915] FS:  0000000000000000(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
[  139.269915] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  139.269915] CR2: 0000000000000004 CR3: 000000001d290000 CR4: 00000000000006f0
[  139.269915] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  139.269915] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  139.269915] Stack:
[  139.269915]  000000001b633d98 0000000000000246 ffff88001df1dc00 ffff88001cc37a00
[  139.269915]  ffff88001bc35e60 0000000000000000 ffff88001ffa0a48 ffff88001bc35ee0
[  139.269915]  ffff88001b633e08 ffffffffa02704b5 0000000000010000 ffff88001cc37a70
[  139.269915] Call Trace:
[  139.269915]  [<ffffffffa02704b5>] __rpc_execute+0x1d5/0x400 [sunrpc]
[  139.269915]  [<ffffffffa0270706>] rpc_async_schedule+0x26/0x30 [sunrpc]
[  139.269915]  [<ffffffff8107867b>] process_one_work+0x17b/0x460
[  139.269915]  [<ffffffff8107942b>] worker_thread+0x11b/0x400
[  139.269915]  [<ffffffff81079310>] ? rescuer_thread+0x3e0/0x3e0
[  139.269915]  [<ffffffff8107fc80>] kthread+0xc0/0xd0
[  139.269915]  [<ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
[  139.269915]  [<ffffffff815d122c>] ret_from_fork+0x7c/0xb0
[  139.269915]  [<ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
[  139.269915] Code: 4c 8b 45 c8 48 8d 7d d0 89 4d c4 41 89 c9 b9 28 00 00 00 e8 9d b4 e9
e0 48 85 c0 49 89 c5 74 a2 48 89 c7 e8 9d 3f e9 e0 48 89 c2 <41> 8b 46 04 48 8b 7d d0 4c
89 e9 4c 89 e6 89 42 0c 0f b7 83 d4
[  139.269915] RIP  [<ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
[  139.269915]  RSP <ffff88001b633d70>
[  139.269915] CR2: 0000000000000004
[  140.946406] ---[ end trace ba486328b98d7622 ]---
Signed-off-by: NDitang Chen <chendt.fnst@cn.fujitsu.com>
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>

* pm-cpufreq:
  cpufreq: Initialize governor for a new policy under policy->rwsem
  cpufreq: Initialize policy before making it available for others to use
  cpufreq: use cpufreq_cpu_get() to avoid cpufreq_get() race conditions

* acpi-resources:
  ACPI / resources: ignore invalid ACPI device resources

* acpi-ec:
  ACPI / EC: Clear stale EC events on Samsung systems

* acpi-sleep:
  ACPI / sleep: pm_power_off needs more sanity checks to be installed

Pull device mapper fixes from Mike Snitzer:

 - dm-cache memory allocation failure fix
 - fix DM's Kconfig identation
 - dm-snapshot metadata corruption fix for bug introduced in 3.14-rc1
 - important refcount < 0 fix for the DM persistent data library's space
   map metadata interface which fixes corruption reported by a few
   dm-thinp users

and last but not least:

 - more extensive fixes than ideal for dm-thinp's data resize capability
   (which has had growing pain much like we've seen from -ENOSPC
   handling of filesystems that mature).

   The end result is dm-thinp now handles metadata operation failure and
   no data space error conditions much better than before.

* tag 'dm-3.14-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm space map metadata: fix refcount decrement below 0 which caused corruption
  dm thin: fix Documentation for held metadata root feature
  dm thin: fix noflush suspend IO queueing
  dm thin: fix deadlock in __requeue_bio_list
  dm thin: fix out of data space handling
  dm thin: ensure user takes action to validate data and metadata consistency
  dm thin: synchronize the pool mode during suspend
  dm snapshot: fix metadata corruption
  dm: fix Kconfig indentation
  dm cache mq: fix memory allocation failure for large cache devices

Don Zickus reports:

A customer generated an external NMI using their iLO to test kdump
worked.  Unfortunately, the machine hung.  Disabling the nmi_watchdog
made things work.

I speculated the external NMI fired, caused the machine to panic (as
expected) and the perf NMI from the watchdog came in and was latched.
My guess was this somehow caused the hang.

   ----

It appears that the latched NMI stays latched until the early page
table generation on 64 bits, which causes exceptions to happen which
end in IRET, which re-enable NMI.  Therefore, ignore NMIs that come in
during early execution, until we have proper exception handling.
Reported-and-tested-by: NDon Zickus <dzickus@redhat.com>
Link: http://lkml.kernel.org/r/1394221143-29713-1-git-send-email-dzickus@redhat.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
Cc: <stable@vger.kernel.org> # v3.5+, older with some backport effort

Commit 017f161a (ARM: 7877/1: use built-in byte swap function) added
bswapsdi2.{o,S} to arch/arm/boot/compressed/Makefile, but didn't update
the .gitignore. Thus after a a build git status shows bswapsdi2.S as a
new file, which is a little annoying.

This patch updates arch/arm/boot/compressed/.gitignore to ignore
bswapsdi2.S, as we already do for ashldi3.S and others.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NNicolas Pitre <nico@linaro.org>
Acked-by: NKim Phillips <kim.phillips@freescale.com>
Cc: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Due to a problem in the MFD Kconfig it was not possible to
compile the UCB battery driver for the Collie SA1100 system,
in turn making it impossible to compile in the battery driver.
(See patch "mfd: include all drivers in subsystem menu".)

After fixing the MFD Kconfig (separate patch) a compile error
appears in the Collie battery driver due to the <mach/collie.h>
implicitly requiring <mach/hardware.h> through <linux/gpio.h>
via <mach/gpio.h> prior to commit
40ca061b "ARM: 7841/1: sa1100: remove complex GPIO interface".

Fix this up by including the required header into
<mach/collie.h>.

Cc: stable@vger.kernel.org
Cc: Andrea Adami <andrea.adami@gmail.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

With noMMU, CONFIG_PAGE_OFFSET was not being set correctly.  As there's
no MMU, PAGE_OFFSET should be equal to PHYS_OFFSET in all cases.  This
commit makes that explicit.

Since we do this, we don't need to mess around in asm/memory.h with
ifdefs to sort this out, so let's get rid of that, and there's no point
offering the "Memory split" option for noMMU as that's meaningless
there.

Fixes: b9b32bf7 ("ARM: use linker magic for vectors and vector stubs")
Cc: <stable@vger.kernel.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This reverts commit 3804fad4.

This commit, together with commit 247bf557
"xhci 1.0: Limit arbitrarily-aligned scatter gather." were
origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
storage devices to fail more frequently.

USB 3.0 mass storage devices used to work before 3.14-rc1.  Theoretically,
the TD fragment rules could have caused an occasional disk glitch.
Now the devices *will* fail, instead of theoretically failing.
>From a user perspective, this looks like a regression; the USB device obviously
fails on 3.14-rc1, and may sometimes silently fail on prior kernels.

The proper soluition is to implement the TD fragment rules for xHCI 1.0 hosts,
but for now, revert this patch until scatter gather can be properly supported.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 247bf557.

This commit, together with commit 3804fad4
"USBNET: ax88179_178a: enable tso if usb host supports sg dma" were
origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a devices
working together with scatter gather. xHCI 1.0 hosts pose some requirement on how transfer
buffers are aligned, setting this requirement for 1.0 hosts caused USB 3.0 mass
storage devices to fail more frequently.

USB 3.0 mass storage devices used to work before 3.14-rc1.  Theoretically,
the TD fragment rules could have caused an occasional disk glitch.
Now the devices *will* fail, instead of theoretically failing.
>From a user perspective, this looks like a regression; the USB device obviously
fails on 3.14-rc1, and may sometimes silently fail on prior kernels.

The proper soluition is to implement the TD fragment rules required, but for now
this patch needs to be reverted to get USB 3.0 mass storage devices working at the
level they used to.
Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The DELAY_INIT quirk only reduces the frequency of enumeration failures
with the Logitech HD Pro C920 and C930e webcams, but does not quite
eliminate them. We have found that adding a delay of 100ms between the
first and second Get Configuration request makes the device enumerate
perfectly reliable even after several weeks of extensive testing. The
reasons for that are anyone's guess, but since the DELAY_INIT quirk
already delays enumeration by a whole second, wating for another 10th of
that isn't really a big deal for the one other device that uses it, and
it will resolve the problems with these webcams.
Signed-off-by: NJulius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We've encountered a rare issue when enumerating two Logitech webcams
after a reboot that doesn't power cycle the USB ports. They are spewing
random data (possibly some leftover UVC buffers) on the second
(full-sized) Get Configuration request of the enumeration phase. Since
the data is random this can potentially cause all kinds of odd behavior,
and since it occasionally happens multiple times (after the kernel
issues another reset due to the garbled configuration descriptor), it is
not always recoverable. Set the USB_DELAY_INIT quirk that seems to work
around the issue.
Signed-off-by: NJulius Werner <jwerner@chromium.org>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>