Pull ACPI and power management fixes from Rafael Wysocki:
 "Still fixing regressions (partly by reverting commits that broke
  things for people), fixing other stable-candidate bugs and adding some
  blacklist entries for ACPI video and _OSI.

  Two ACPICA regression fixes (one recent and one for a 3.14 commit), a
  fix for an ACPI-related regression in TPM (introduced in 3.14), a
  revert of the ACPI AC driver conversion in 3.13 that went wrong for an
  unknown reason, two reverts of commits that attempted to remove an old
  user space interface in /proc and broke some utilities, in 3.13 too, a
  fix for a CPU hotplug bug in the ACPI processor driver (stable
  material), two (stable candidate) fixes for intel_pstate and a few new
  blacklist entries, mostly for systems that shipped with Windows 8.

  Specifics:

   - ACPICA fix for a stale pointer access introduced by a recent commit
     in the XSDT validation code from Lv Zheng.

   - ACPICA fix for the default value of the command line switch to
     favor 32-bit FADT addresses (in case there's a conflict between a
     64-bit and a 32-bit address).  The previous default was that the
     32-bit version would take precedence and we tried to change it to
     the other way around and it didn't work.  From Lv Zheng.

   - A TPM commit related to ACPI _DSM in 3.14 caused the driver to
     refuse to load if a specific _DSM was missing and that broke resume
     from system suspend on Chromebooks that require the TPM hardware to
     be restored to a working state during resume by the OS.  Restore
     the old behavior to load the driver if the _DSM in question is not
     present, but prevent it from using the feature the _DSM is for.

   - ACPI AC driver conversion in 3.13 broke thermal management on at
     least one machine and has to be reverted.  From Guenter Roeck.

   - Two reverts of 3.13 commits that attempted to remove the old ACPI
     battery interface in /proc, but turned out to break some utilities
     still using that interface.  From Lan Tianyu.

   - ACPI processor driver fix to prevent acpi_processor_add() from
     modifying the CPU device's .offline field which leads to breakage
     if the initial online of the CPU fails.  From Igor Mammedov.

   - Two intel_pstate fixes, one to take a BayTrail documentation update
     into account and one to avoid forcing the maximum P-state on init
     which causes CPU PM trouble on systems with P-states coordination
     when one of the CPU cores is initialized after an offline/online
     cycle triggered by user space.  Both stable candidates, from Dirk
     Brandewie.

   - Fix for the ACPI video DMI blacklist entry for Dell Inspiron 7520
     from Aaron Lu.

   - Two new ACPI video blacklist entries for machines shipping with
     Win8 that need to use native backlight so that it can be controlled
     in a usual way (which doesn't work otherwise due bugs in the ACPI
     tables) from Hans de Goede.

   - Two ACPI _OSI quirks for systems that need them to work correctly
     with Linux from Edward Lin and Hans de Goede"

* tag 'pm+acpi-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / video: Revert native brightness quirk for ThinkPad T530
  intel_pstate: remove setting P state to MAX on init
  ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses.
  ACPI / video: correct DMI tag for Dell Inspiron 7520
  intel_pstate: Set turbo VID for BayTrail
  ACPI / TPM: Fix resume regression on Chromebooks
  ACPI / proc: Do not say when /proc interfaces will be deleted in Kconfig
  ACPI / processor: do not mark present at boot but not onlined CPU as onlined
  ACPI: Revert "ACPI / AC: convert ACPI ac driver to platform bus"
  ACPI / blacklist: Add dmi_enable_osi_linux quirk for Asus EEE PC 1015PX
  ACPI: blacklist win8 OSI for Dell Inspiron 7737
  ACPI / video: Add use_native_backlight quirks for more systems
  ACPI: Revert "ACPI / Battery: Remove battery's proc directory"
  ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c"
  ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table().

Pull device mapper fixes from Mike Snitzer:
 "A dm-crypt fix for a cpu hotplug crash that switches from using
  per-cpu data to a mempool allocation (which offers allocation with cpu
  locality, and there is no inter-cpu communication on slab allocation).

  A couple dm-thinp stable fixes to address "out-of-data-space" issues.

  A dm-multipath fix for a LOCKDEP warning introduced in 3.15-rc1"

* tag 'dm-3.15-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm mpath: fix lock order inconsistency in multipath_ioctl
  dm thin: add timeout to stop out-of-data-space mode holding IO forever
  dm thin: allow metadata commit if pool is in PM_OUT_OF_DATA_SPACE mode
  dm crypt: fix cpu hotplug crash by removing per-cpu structure

Pull device tree fixes from Grant Likely:
 "Drivercore bugfixes for v3.15

  This branch contains bug fixes important to get into v3.15.  There is
  a fix for modifying properties seen during early boot, a fix for an
  incorrect prototype when CONFIG_OF=n, and a couple of corrections to
  device tree memory nodes on a few platforms"

* tag 'dt-for-linus' of git://git.secretlab.ca/git/linux:
  mips: dts: Fix missing device_type="memory" property in memory nodes
  arm: dts: Fix missing device_type="memory" for ste-ccu8540
  of: fix CONFIG_OF=n prototype of of_node_full_name()
  of: make of_update_property() usable earlier in the boot process

Pull sound fixes from Takashi Iwai:
 "Unfortunately this update became bigger than previous pull requests,
  which is almost a pattern in rc5-6.  But, the only obvious big changes
  are for the new Intel DSP ASoC drivers, so the impact must be fairly
  limited.

  Other than that, usual small fixes in various fields: HD-audio, ASoC
  core and ASoC fsl and codec drivers"

* tag 'sound-3.15-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (26 commits)
  ALSA: sb_mixer: missing return statement
  ASoC: wm8962: Update register CLASS_D_CONTROL_1 to be non-volatile
  ASoC: Intel: Fix Baytrail SST DSP firmware loading
  ALSA: hda - mask buggy stream DMA0 for Broadwell display controller
  ALSA: hda - Add new GPU codec ID to snd-hda
  ASoC: fsl_esai: Set PCRC and PRRC registers at the end of hw_params()
  ASoC: fsl_esai: Only bypass sck_div for EXTAL source
  ASoC: fsl_esai: Fix incorrect condition within ratio range check for FP
  ASoC: dapm: Fix SUSPEND -> OFF bias sequence
  ASoC: dapm: Skip CODEC<->CODEC links in connect_dai_link_widgets()
  ASoC: pcm: Fix incorrect condition check for case SNDRV_PCM_TRIGGER_SUSPEND
  ALSA: hda - add headset mic detect quirks for three Dell laptops
  ASoC: Update Cirrus Logic CODEC maintainers.
  ASoC: Intel: Fix block offset calculations.
  ASoC: Intel: Fix check for pdata usage before dereference.
  ASoC: Intel: Fix stream position pointer.
  ASoC: Intel: Fix allow hw_params to be called more than once.
  ASoC: Intel: Fix Audio DSP usage when IOMMU is enabled.
  ASoC: Intel: Fix Haswell/Broadwell DSP page table creation.
  ASoC: Intel: Fix allocated block list usage when adding blocks.
  ...

Pull MIPS fixes from Ralf Baechle:
 "MIPS fixes for various loose ends:

   - Fix workarounds for R4000 erratum.
   - Patch up DEC, Siemens-Nixdorf and Loongson hardware support.
   - Wire up renameat2 syscall.
   - Delete unused file - it was causing false warnings from maintenance
     scripts.
   - Revert a patch because it's functionality is now implemented twice
     which causes superfluous /proc/cpuinfo output.
   - Fix a microMIPS regression"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: mm: Fix broken microMIPS kernel regression.
  MIPS: Add new AUDIT_ARCH token for the N32 ABI on MIPS64
  MIPS: Wire up renameat2 syscall.
  MIPS: inst.h: Rename BITFIELD_FIELD to __BITFIELD_FIELD.
  MIPS: Remove file missed when removing rm9k support a while ago.
  MIPS/loongson2_cpufreq: Fix CPU clock rate setting
  MIPS: Loongson: No need to select GENERIC_HARDIRQS_NO__DO_IRQ
  MIPS: csum_partial.S CPU_DADDI_WORKAROUNDS bug fix
  MIPS: __strncpy_from_user_asm CPU_DADDI_WORKAROUNDS bug fix
  MIPS: __delay CPU_DADDI_WORKAROUNDS bug fix
  MIPS: DEC/SNI: O32 wrapper stack switching fixes
  MIPS: DEC: Bus error handler <asm/cpu-type.h> fixes
  MAINTAINERS: TURBOchannel: Update entry
  Revert "MIPS: MT: proc: Add support for printing VPE and TC ids"

Pull parisc fixes from Helge Deller:
 "There are two patches in here:

  The first patch greatly improves latency and corrects the memory
  ordering in our light-weight atomic locking syscall.

  The second patch ratelimits printing of userspace segfaults in the
  same way as it's done on other platforms.  This fixes a possible DOS
  on parisc since it prevents the syslog to grow too fast.  For example,
  when the debian acl2 package was built on our debian buildd servers,
  this package produced lots of gigabytes in syslog in very short time
  and thus filled our harddisks, which then turned the server nearly
  completely unaccessible and unresponsive"

* 'parisc-3.15-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Improve LWS-CAS performance
  parisc: ratelimit userspace segfault printing

Pull two arm64 fixes from Catalin Marinas:
 - arm64 migrate_irqs() fix following commit ffde1de6 (irqchip: Gic:
   Support forced affinity setting)
 - fix arm64 pud_huge() to return 0 when only 2 levels page tables are
   used (__PAGETABLE_PMD_FOLDED defined and pmd_huge already covers
   block entries at the first level), otherwise KVM gets confused

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: fix pud_huge() for 2-level pagetables
  arm64: use cpu_online_mask when using forced irq_set_affinity

Pull Metag architecture and related fixes from James Hogan:
 "Mostly fixes for metag and parisc relating to upgrowing stacks.

   - Fix missing compiler barriers in metag memory barriers.
   - Fix BUG_ON on metag when RLIMIT_STACK hard limit is increased
     beyond safe value.
   - Make maximum stack size configurable.  This reduces the default
     user stack size back to 80MB (especially on parisc after their
     removal of _STK_LIM_MAX override).  This only affects metag and
     parisc.
   - Remove metag _STK_LIM_MAX override to match other arches and follow
     parisc, now that it is safe to do so (due to the BUG_ON fix
     mentioned above).
   - Finally now that both metag and parisc _STK_LIM_MAX overrides have
     been removed, it makes sense to remove _STK_LIM_MAX altogether"

* tag 'metag-for-v3.15-2' of git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag:
  asm-generic: remove _STK_LIM_MAX
  metag: Remove _STK_LIM_MAX override
  parisc,metag: Do not hardcode maximum userspace stack size
  metag: Reduce maximum stack size to 256MB
  metag: fix memory barriers

Pull drm/intel fixes from Dave Airlie:
 "Just some intel fixes.

  I have some radeon ones but I need to get some patches dropped from
  the pull req"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/i915: Increase WM memory latency values on SNB
  drm/i915: restore backlight precision when converting from ACPI
  drm/i915: Use the first mode if there is no preferred mode in the EDID
  drm/i915/dp: force eDP lane count to max available lanes on BDW
  drm/i915/vlv: reset VLV media force wake request register
  drm/i915/SDVO: For sysfs link put directory and target in correct order
  drm/i915: use lane count and link rate from VBT as minimums for eDP
  drm/i915: clean up VBT eDP link param decoding
  drm/i915: consider the source max DP lane count too

Pull x86 fixes from Peter Anvin.

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86-64, modify_ldt: Make support for 16-bit segments a runtime option
  x86, mm, hugetlb: Add missing TLB page invalidation for hugetlb_cow()
  x86, rdrand: When nordrand is specified, disable RDSEED as well

Pull timer fix from Thomas Gleixner:
 "A single bug fix for a long standing issue:

   - Updating the expiry value of a relative timer _after_ letting the
     idle logic select a target cpu for the timer based on its stale
     expiry value is outright stupid.  Thanks to Viresh for spotting the
     brainfart"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  hrtimer: Set expiry time before switch_hrtimer_base()

Pull irq fixes from Thomas Gleixner:
 "Two small updates from the irq departement:

   - Provide missing inline stub for a SMP only function

   - Add sub-maintainer for the drivers/irqchip/ part of the irq
     subsystem.  YAY!"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  MAINTAINERS: Add co-maintainer for drivers/irqchip
  genirq: Provide irq_force_affinity fallback for non-SMP

Intel fixes for regressions, black screens and hangs, for 3.15.

* tag 'drm-intel-fixes-2014-05-16' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Increase WM memory latency values on SNB
  drm/i915: restore backlight precision when converting from ACPI
  drm/i915: Use the first mode if there is no preferred mode in the EDID
  drm/i915/dp: force eDP lane count to max available lanes on BDW
  drm/i915/vlv: reset VLV media force wake request register
  drm/i915/SDVO: For sysfs link put directory and target in correct order
  drm/i915: use lane count and link rate from VBT as minimums for eDP
  drm/i915: clean up VBT eDP link param decoding
  drm/i915: consider the source max DP lane count too

* acpi-video:
  ACPI / video: Revert native brightness quirk for ThinkPad T530

Seems it helps some users, but causes issues for other users:
https://bugzilla.redhat.com/show_bug.cgi?id=1089545

So lets drop it for now until we've figured out a better fix.

Fixes: 43d94902 (ACPI / video: Add use_native_backlight quirks for more systems)
References: https://bugzilla.redhat.com/show_bug.cgi?id=1089545
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The following happens when trying to run a kvm guest on a kernel
configured for 64k pages. This doesn't happen with 4k pages:

  BUG: failure at include/linux/mm.h:297/put_page_testzero()!
  Kernel panic - not syncing: BUG!
  CPU: 2 PID: 4228 Comm: qemu-system-aar Tainted: GF            3.13.0-0.rc7.31.sa2.k32v1.aarch64.debug #1
  Call trace:
  [<fffffe0000096034>] dump_backtrace+0x0/0x16c
  [<fffffe00000961b4>] show_stack+0x14/0x1c
  [<fffffe000066e648>] dump_stack+0x84/0xb0
  [<fffffe0000668678>] panic+0xf4/0x220
  [<fffffe000018ec78>] free_reserved_area+0x0/0x110
  [<fffffe000018edd8>] free_pages+0x50/0x88
  [<fffffe00000a759c>] kvm_free_stage2_pgd+0x30/0x40
  [<fffffe00000a5354>] kvm_arch_destroy_vm+0x18/0x44
  [<fffffe00000a1854>] kvm_put_kvm+0xf0/0x184
  [<fffffe00000a1938>] kvm_vm_release+0x10/0x1c
  [<fffffe00001edc1c>] __fput+0xb0/0x288
  [<fffffe00001ede4c>] ____fput+0xc/0x14
  [<fffffe00000d5a2c>] task_work_run+0xa8/0x11c
  [<fffffe0000095c14>] do_notify_resume+0x54/0x58

In arch/arm/kvm/mmu.c:unmap_range(), we end up doing an extra put_page()
on the stage2 pgd which leads to the BUG in put_page_testzero(). This
happens because a pud_huge() test in unmap_range() returns true when it
should always be false with 2-level pages tables used by 64k pages.
This patch removes support for huge puds if 2-level pagetables are
being used.
Signed-off-by: Mark Salter <msalter@redhat.com>
[catalin.marinas@arm.com: removed #ifndef around PUD_SIZE check]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: <stable@vger.kernel.org> # v3.11+

A few platforms lack a 'device_type = "memory"' for their memory
nodes, relying on an old ppc quirk in order to discover its memory.
Add the missing data so that all parsing code can find memory nodes
correctly.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: linux-mips@linux-mips.org
Cc: devicetree@vger.kernel.org
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org>
Acked-by: John Crispin <blogic@openwrt.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>

The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for
its memory node, relying on an old ppc quirk in order to discover its
memory. Fix the data so that all parsing code can handle it correctly.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Grant Likely <grant.likely@linaro.org>

The attached change significantly improves the performance of the LWS-CAS code
in syscall.S.
This allows a number of packages to build (e.g., zeromq3, gtest and libxs)
that previously failed because slow LWS-CAS performance under contention. In
particular, interrupts taken while the lock was taken degraded performance
significantly.

The change does the following:

1) Disables interrupts around the CAS operation, and
2) Changes the loads and stores to use the ordered completer, "o", on
PA 2.0. "o" and "ma" with a zero offset are equivalent. The latter is
accepted on both PA 1.X and 2.0.

The use of ordered loads and stores probably makes no difference on all
existing hardware, but it seemed pedantically correct. In particular, the CAS
operation must complete before LDCW lock is released. As written before, a
processor could reorder the operations.

I don't believe the period interrupts are disabled is long enough to
significantly increase interrupt latency. For example, the TLB insert code is
longer. Worst case is a memory fault in the CAS operation.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # 3.13+
Signed-off-by: Helge Deller <deller@gmx.de>

Ratelimit printing of userspace segfaults and make it runtime
configurable via the /proc/sys/debug/exception-trace variable. This
should resolve syslog from growing way too fast and thus prevents
possible system service attacks.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 3.13+

Make the CONFIG_OF=n prototpe of of_node_full_name() mateh the CONFIG_OF=y
version.

Fixes compile warnings like this:

sound/soc/soc-core.c: In function 'soc_check_aux_dev':
sound/soc/soc-core.c:1667:3: warning: passing argument 1 of 'of_node_full_name' discards 'const' qualifier from pointer target type [enabled by default]
   codecname = of_node_full_name(aux_dev->codec_of_node);

when CONFIG_OF is not defined.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Grant Likely <grant.likely@linaro.org>

* pm-cpufreq:
  intel_pstate: remove setting P state to MAX on init
  intel_pstate: Set turbo VID for BayTrail

* acpi-video:
  ACPI / video: correct DMI tag for Dell Inspiron 7520
  ACPI / video: Add use_native_backlight quirks for more systems

* acpi-blacklist:
  ACPI / blacklist: Add dmi_enable_osi_linux quirk for Asus EEE PC 1015PX
  ACPI: blacklist win8 OSI for Dell Inspiron 7737

* acpi-ac:
  ACPI: Revert "ACPI / AC: convert ACPI ac driver to platform bus"

* acpi-proc:
  ACPI / proc: Do not say when /proc interfaces will be deleted in Kconfig
  ACPI: Revert "ACPI / Battery: Remove battery's proc directory"
  ACPI: Revert "ACPI: Remove CONFIG_ACPI_PROCFS_POWER and cm_sbsc.c"

* acpica:
  ACPICA: Tables: Restore old behavor to favor 32-bit FADT addresses.
  ACPICA: Tables: Fix invalid pointer accesses in acpi_tb_parse_root_table().

* acpi-tpm:
  ACPI / TPM: Fix resume regression on Chromebooks

* acpi-processor:
  ACPI / processor: do not mark present at boot but not onlined CPU as onlined

On SNB the BIOS provided WM memory latency values seem insufficient to
handle high resolution displays.

In this particular case the display mode was a 2560x1440@60Hz, which
makes the pixel clock 241.5 MHz. It was empirically found that a memory
latency value if 1.2 usec is enough to avoid underruns, whereas the BIOS
provided value of 0.7 usec was clearly too low. Incidentally 1.2 usec
is what the typical BIOS provided values are on IVB systems.

Increase the WM memory latency values to at least 1.2 usec on SNB.
Hopefully this won't have a significant effect on power consumption.

v2: Increase the latency values regardless of the pixel clock

Cc: Robert N <crshman@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70254Tested-by: Robert Navarro <crshman@gmail.com>
Tested-by: Vitaly Minko <vitaly.minko@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

When we set backlight on behalf of ACPI opregion, we will convert the
backlight value in the 0-255 range defined in opregion to the actual
hardware level. Commit 22505b82 (drm/i915: avoid brightness overflow
when doing scale) is meant to fix the overflow problem when doing the
conversion, but it also caused a problem that the converted hardware
level doesn't quite represent the intended value: say user wants maximum
backlight level(255 in opregion's range), then we will calculate the
actual hardware level to be: level = freq / max * level, where freq is
the hardware's max backlight level(937 on an user's box), and max and
level are all 255. The converted value should be 937 but the above
calculation will yield 765.

To fix this issue, just use 64 bits to do the calculation to keep the
precision and avoid overflow at the same time.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491Reported-by: Nico Schottelius <nico-bugzilla.kernel.org@schottelius.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

This matches the algorithm used by earlier kernels when selecting the
mode for the fbcon. And only if there is no modes at all, do we fall
back to using the BIOS configuration. Seamless transition is still
preserved (from the BIOS configuration to ours) so long as the BIOS has
also chosen what we hope is the native configuration.
Reported-by: Knut Petersen <Knut_Petersen@t-online.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78655Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Knut Petersen <Knut_Petersen@t-online.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[Jani: applied Chris' "Please imagine that I wrote this correctly."]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

There are certain BDW high res eDP machines that regressed due to

commit 38aecea0
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Mar 3 11:18:10 2014 +0100

    drm/i915: reverse dp link param selection, prefer fast over wide again

The commit lead to 2 lanes at 5.4 Gbps being used instead of 4 lanes at
2.7 Gbps on the affected machines. Link training succeeded for both, but
the screen remained blank with the former config. Further investigation
showed that 4 lanes at 5.4 Gbps worked also.

The root cause for the blank screen using 2 lanes remains unknown, but
apparently the driver for a certain other operating system by default
uses the max available lanes. Follow suit on Broadwell eDP, for at least
until we figure out what is going on.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76711Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Checkin:

b3b42ac2 x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels

disabled 16-bit segments on 64-bit kernels due to an information
leak.  However, it does seem that people are genuinely using Wine to
run old 16-bit Windows programs on Linux.

A proper fix for this ("espfix64") is coming in the upcoming merge
window, but as a temporary fix, create a sysctl to allow the
administrator to re-enable support for 16-bit segments.

It adds a "/proc/sys/abi/ldt16" sysctl that defaults to zero (off). If
you hit this issue and care about your old Windows program more than
you care about a kernel stack address information leak, you can do

   echo 1 > /proc/sys/abi/ldt16

as root (add it to your startup scripts), and you should be ok.

The sysctl table is only added if you have COMPAT support enabled on
x86-64, but I assume anybody who runs old windows binaries very much
does that ;)
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Link: http://lkml.kernel.org/r/CA%2B55aFw9BPoD10U1LfHbOMpHWZkvJTkMcfCs9s3urPr1YyWBxw@mail.gmail.com
Cc: <stable@vger.kernel.org>

_STK_LIM_MAX could be used to override the RLIMIT_STACK hard limit from
an arch's include/uapi/asm-generic/resource.h file, but is no longer
used since both parisc and metag removed the override. Therefore remove
it entirely, setting the hard RLIMIT_STACK limit to RLIM_INFINITY
directly in include/asm-generic/resource.h.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arch@vger.kernel.org
Cc: Helge Deller <deller@gmx.de>
Cc: John David Anglin <dave.anglin@bell.net>

Meta overrode _STK_LIM_MAX (the default RLIMIT_STACK hard limit) to
256MB, apparently in an attempt to prevent setup_arg_pages's
STACK_GROWSUP code from choosing the maximum stack size of 1GB, which is
far too large for Meta's limited virtual address space and hits a BUG_ON
(stack_top is usually 0x3ffff000).

However the commit "metag: Reduce maximum stack size to 256MB" reduces
the absolute stack size limit to a safe value for metag. This allows the
default _STK_LIM_MAX override to be removed, bringing the default
behaviour in line with all other architectures. Parisc in particular
recently removed their override of _STK_LIMT_MAX in commit e0d8898d
(parisc: remove _STK_LIM_MAX override) since it subtly affects stack
allocation semantics in userland. Meta's uapi/asm/resource.h can now be
removed and switch to using generic-y.
Suggested-by: Helge Deller <deller@gmx.de>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>

This patch affects only architectures where the stack grows upwards
(currently parisc and metag only). On those do not hardcode the maximum
initial stack size to 1GB for 32-bit processes, but make it configurable
via a config option.

The main problem with the hardcoded stack size is, that we have two
memory regions which grow upwards: stack and heap. To keep most of the
memory available for heap in a flexmap memory layout, it makes no sense
to hard allocate up to 1GB of the memory for stack which can't be used
as heap then.

This patch makes the stack size for 32-bit processes configurable and
uses 80MB as default value which has been in use during the last few
years on parisc and which hasn't showed any problems yet.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>

Specify the maximum stack size for arches where the stack grows upward
(parisc and metag) in asm/processor.h rather than hard coding in
fs/exec.c so that metag can specify a smaller value of 256MB rather than
1GB.

This fixes a BUG on metag if the RLIMIT_STACK hard limit is increased
beyond a safe value by root. E.g. when starting a process after running
"ulimit -H -s unlimited" it will then attempt to use a stack size of the
maximum 1GB which is far too big for metag's limited user virtual
address space (stack_top is usually 0x3ffff000):

BUG: failure at fs/exec.c:589/shift_arg_pages()!
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Helge Deller <deller@gmx.de>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: linux-parisc@vger.kernel.org
Cc: linux-metag@vger.kernel.org
Cc: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # only needed for >= v3.9 (arch/metag)

Volatile access doesn't really imply the compiler barrier. Volatile access
is only ordered with respect to other volatile accesses, it isn't ordered
with respect to general memory accesses. Gcc may reorder memory accesses
around volatile access, as we can see in this simple example (if we
compile it with optimization, both increments of *b will be collapsed to
just one):

void fn(volatile int *a, long *b)
{
	(*b)++;
	*a = 10;
	(*b)++;
}

Consequently, we need the compiler barrier after a write to the volatile
variable, to make sure that the compiler doesn't reorder the volatile
write with something else.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
Acked-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: James Hogan <james.hogan@imgtec.com>

Commit 3e9f1be1 ("dm mpath: remove process_queued_ios()") did not
consistently take the multipath device's spinlock (m->lock) before
calling dm_table_run_md_queue_async() -- which takes the q->queue_lock.

Found with code inspection using hint from reported lockdep warning.
Reported-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>

If the pool runs out of data space, dm-thin can be configured to
either error IOs that would trigger provisioning, or hold those IOs
until the pool is resized.  Unfortunately, holding IOs until the pool is
resized can result in a cascade of tasks hitting the hung_task_timeout,
which may render the system unavailable.

Add a fixed timeout so IOs can only be held for a maximum of 60 seconds.
If LVM is going to resize a thin-pool that is out of data space it needs
to be prompt about it.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org # 3.14+

Commit 3e1a0699 ("dm thin: fix out of data space handling") introduced
a regression in the metadata commit() method by returning an error if
the pool is in PM_OUT_OF_DATA_SPACE mode.  This oversight caused a thin
device to return errors even if the default queue_if_no_space ENOSPC
handling mode is used.

Fix commit() to only fail if pool is in PM_READ_ONLY or PM_FAIL mode.

Reported-by: qindehua@163.com
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org # 3.14+

The DM crypt target used per-cpu structures to hold pointers to a
ablkcipher_request structure.  The code assumed that the work item keeps
executing on a single CPU, so it didn't use synchronization when
accessing this structure.

If a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online,
the work item could be moved to another CPU.  This causes dm-crypt
crashes, like the following, because the code starts using an incorrect
ablkcipher_request:

 smpboot: CPU 7 is now offline
 BUG: unable to handle kernel NULL pointer dereference at 0000000000000130
 IP: [<ffffffffa1862b3d>] crypt_convert+0x12d/0x3c0 [dm_crypt]
 ...
 Call Trace:
  [<ffffffffa1864415>] ? kcryptd_crypt+0x305/0x470 [dm_crypt]
  [<ffffffff81062060>] ? finish_task_switch+0x40/0xc0
  [<ffffffff81052a28>] ? process_one_work+0x168/0x470
  [<ffffffff8105366b>] ? worker_thread+0x10b/0x390
  [<ffffffff81053560>] ? manage_workers.isra.26+0x290/0x290
  [<ffffffff81058d9f>] ? kthread+0xaf/0xc0
  [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120
  [<ffffffff813464ac>] ? ret_from_fork+0x7c/0xb0
  [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120

Fix this bug by removing the per-cpu definition.  The structure
ablkcipher_request is accessed via a pointer from convert_context.
Consequently, if the work item is rescheduled to a different CPU, the
thread still uses the same ablkcipher_request.

This change may undermine performance improvements intended by commit
c0297721 ("dm crypt: scale to multiple cpus") on select hardware.  In
practice no performance difference was observed on recent hardware.  But
regardless, correctness is more important than performance.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org

Commit f4ae17aa [MIPS: mm: Use scratch for
PGD when !CONFIG_MIPS_PGD_C0_CONTEXT] broke microMIPS kernel builds. This
patch refactors that code similar to what was done for the 'clear_page'
and 'copy_page' functions.
Signed-off-by: Steven J. Hill <Steven.Hill@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6744/Signed-off-by: Ralf Baechle <ralf@linux-mips.org>