Merge tag 'vfio-v4.10-rc6' of git://github.com/awilliam/linux-vfio

Pull VFIO fix from Alex Williamson:
 "mdev IOMMU groups are not yet compatible with the powerpc SPAPR IOMMU
  backend, detect and fail group attach (Greg Kurz)"

* tag 'vfio-v4.10-rc6' of git://github.com/awilliam/linux-vfio:
  vfio/spapr: fail tce_iommu_attach_group() when iommu_data is null

Merge tag 'media/v4.10-2' of git://git./linux/kernel/git/mchehab/linux-media

Pull media fixes from Mauro Carvalho Chehab:

 - fix a regression on tvp5150 causing failures at input selection and
   image glitches

 - CEC was moved out of staging for v4.10. Fix some bugs on it while not
   too late

 - fix a regression on pctv452e caused by VM stack changes

 - fix suspend issued with smiapp

 - fix a regression on cobalt driver

 - fix some warnings and Kconfig issues with some random configs.

* tag 'media/v4.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] s5k4ecgx: select CRC32 helper
  [media] dvb: avoid warning in dvb_net
  [media] v4l: tvp5150: Don't override output pinmuxing at stream on/off time
  [media] v4l: tvp5150: Fix comment regarding output pin muxing
  [media] v4l: tvp5150: Reset device at probe time, not in get/set format handlers
  [media] pctv452e: move buffer to heap, no mutex
  [media] media/cobalt: use pci_irq_allocate_vectors
  [media] cec: fix race between configuring and unconfiguring
  [media] cec: move cec_report_phys_addr into cec_config_thread_func
  [media] cec: replace cec_report_features by cec_fill_msg_report_features
  [media] cec: update log_addr[] before finishing configuration
  [media] cec: CEC_MSG_GIVE_FEATURES should abort for CEC version < 2
  [media] cec: when canceling a message, don't overwrite old status info
  [media] cec: fix report_current_latency
  [media] smiapp: Make suspend and resume functions __maybe_unused
  [media] smiapp: Implement power-on and power-off sequences without runtime PM

Merge tag 'mmc-v4.10-rc5' of git://git./linux/kernel/git/ulfh/mmc

Pull MMC fix from Ulf Hansson:
 "MMC host: fix runtime PM resume path in dw_mmc"

* tag 'mmc-v4.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  mmc: dw_mmc: force setup bus if active slots exist

Merge branch 'for-rc' of git://git./linux/kernel/git/rzhang/linux

Pull thermal management fix from Zhang Rui:
 "A single revert from a recently introduced problem.

  Specifics:

  Commit 7611fb68062f ("thermal: thermal_hwmon: Convert to
  hwmon_device_register_with_info()"), which was introduced in 4.10-rc5,
  uses new hwmon API. But this breaks some soc thermal driver because
  the new hwmon API has a strict rule for the hwmon device name. Revert
  the offending commit as a quick solution for 4.10"

* 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
  Revert "thermal: thermal_hwmon: Convert to hwmon_device_register_with_info()"

Merge tag 'drm-fixes-for-v4.10-rc6-part-two' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "This is the main request for rc6, since really the one earlier was the
  rc5 one :-)

  The main thing are the nouveau specific race fixes for the connector
  locking bug we fixed in -next and reverted here as it has quite large
  prereqs. These two fixes should solve the problem at that level and we
  can fix it properly in 4.11

  Otherwise i915 has a bunch of changes, one ABI change for GVT related
  stuff, some VC4 leak fixes, one core fence fix and some AMD changes,
  oh and one ast hang avoidance fix.

  Hoping it calms down around now"

* tag 'drm-fixes-for-v4.10-rc6-part-two' of git://people.freedesktop.org/~airlied/linux: (25 commits)
  drm/nouveau: Handle fbcon suspend/resume in seperate worker
  drm/nouveau: Don't enabling polling twice on runtime resume
  drm/ast: Fixed system hanged if disable P2A
  Revert "drm/radeon: always apply pci shutdown callbacks"
  drm/i915: reinstate call to trace_i915_vma_bind
  drm/i915: Move atomic state free from out of fence release
  drm/i915: Check for NULL atomic state in intel_crtc_disable_noatomic()
  drm/i915: Fix calculation of rotated x and y offsets for planar formats
  drm/i915: Don't init hpd polling for vlv and chv from runtime_suspend()
  drm/i915: Don't leak edid in intel_crt_detect_ddc()
  drm/i915: Release temporary load-detect state upon switching
  drm/i915: prevent crash with .disable_display parameter
  drm/i915: Avoid drm_atomic_state_put(NULL) in intel_display_resume
  MAINTAINERS: update new mail list for intel gvt driver
  drm/i915/gvt: Fix kmem_cache_create() name
  drm/i915/gvt/kvmgt: mdev ABI is available_instances, not available_instance
  drm/amdgpu: fix unload driver issue for virtual display
  drm/amdgpu: check ring being ready before using
  drm/vc4: Return -EINVAL on the overflow checks failing.
  drm/vc4: Fix an integer overflow in temporary allocation layout.
  ...

Merge tag 'drm-intel-fixes-2017-01-26' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes

More fixes than I'd like at this stage, but I think the holidays and
conferences have delayed finding and fixing the stuff a bit. Almost all
of them have Fixes: tags, so it's not just random fixes, we can point
fingers at the commits that broke stuff.

There's an ABI fix to GVT from Alex, before we go on an release a kernel
with the wrong attribute name.

* tag 'drm-intel-fixes-2017-01-26' of git://anongit.freedesktop.org/git/drm-intel:
  drm/i915: reinstate call to trace_i915_vma_bind
  drm/i915: Move atomic state free from out of fence release
  drm/i915: Check for NULL atomic state in intel_crtc_disable_noatomic()
  drm/i915: Fix calculation of rotated x and y offsets for planar formats
  drm/i915: Don't init hpd polling for vlv and chv from runtime_suspend()
  drm/i915: Don't leak edid in intel_crt_detect_ddc()
  drm/i915: Release temporary load-detect state upon switching
  drm/i915: prevent crash with .disable_display parameter
  drm/i915: Avoid drm_atomic_state_put(NULL) in intel_display_resume
  MAINTAINERS: update new mail list for intel gvt driver
  drm/i915/gvt: Fix kmem_cache_create() name
  drm/i915/gvt/kvmgt: mdev ABI is available_instances, not available_instance
  drm/i915/gvt: Fix relocation of shadow bb
  drm/i915/gvt: Enable the shadow batch buffer

Merge tag 'acpi-4.10-rc6' of git://git./linux/kernel/git/rafael/linux-pm

Pull ACPI fixes from Rafael Wysocki:
 "These fix two regressions introduced recently, one by reverting the
  problematic commit and one by fixing up locking in the ACPICA core.

  Specifics:

   - Revert a recent change that added an ACPI video blacklist entry for
     HP Pavilion dv6 as it turned to introduce backlight handling
     regressions on some systems (Hans de Goede).

   - Fix locking in the ACPICA core to avoid deadlocks related to table
     loading that were exposed by a recent change in that area (Lv
     Zheng)"

* tag 'acpi-4.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  Revert "ACPI / video: Add force_native quirk for HP Pavilion dv6"
  ACPICA: Tables: Fix hidden logic related to acpi_tb_install_standard_table()

Merge tag 'pm-4.10-rc6' of git://git./linux/kernel/git/rafael/linux-pm

Pull power management fixes from Rafael Wysocki:
 "These fix two regressions introduced recently, one by reverting the
  problematic commit and one by fixing up the behavior in an overlooked
  case.

  Specifics:

   - Revert the recent change that caused suspend-to-idle to be used as
     the default suspend method on systems where it is indicated to be
     efficient by the ACPI tables, as that turned out to be premature
     and introduced suspend regressions on some systems with missing
     power management support in device drivers (Rafael Wysocki).

   - Fix up the intel_pstate driver to take changes of the global limits
     via sysfs correctly when the performance policy is used which has
     been broken by a recent change in it (Srinivas Pandruvada)"

* tag 'pm-4.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  cpufreq: intel_pstate: Fix sysfs limits enforcement for performance policy
  Revert "PM / sleep / ACPI: Use the ACPI_FADT_LOW_POWER_S0 flag"

drm/nouveau: Handle fbcon suspend/resume in seperate worker

Resuming from RPM can happen while already holding
dev->mode_config.mutex. This means we can't actually handle fbcon in
any RPM resume workers, since restoring fbcon requires grabbing
dev->mode_config.mutex again. So move the fbcon suspend/resume code into
it's own worker, and rely on that instead to avoid deadlocking.

This fixes more deadlocks for runtime suspending the GPU on the ThinkPad
W541. Reproduction recipe:

 - Get a machine with both optimus and a nvidia card with connectors
   attached to it
 - Wait for the nvidia GPU to suspend
 - Attempt to manually reprobe any of the connectors on the nvidia GPU
   using sysfs
 - *deadlock*

[airlied: use READ_ONCE to address Hans's comment]

Signed-off-by: Lyude <lyude@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: David Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau: Don't enabling polling twice on runtime resume

As it turns out, on cards that actually have CRTCs on them we're already
calling drm_kms_helper_poll_enable(drm_dev) from
nouveau_display_resume() before we call it in
nouveau_pmops_runtime_resume(). This leads us to accidentally trying to
enable polling twice, which results in a potential deadlock between the
RPM locks and drm_dev->mode_config.mutex if we end up trying to enable
polling the second time while output_poll_execute is running and holding
the mode_config lock. As such, make sure we only enable polling in
nouveau_pmops_runtime_resume() if we need to.

This fixes hangs observed on the ThinkPad W541

Signed-off-by: Lyude <lyude@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: David Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/ast: Fixed system hanged if disable P2A

The original ast driver will access some BMC configuration through P2A bridge
that can be disabled since AST2300 and after.
It will cause system hanged if P2A bridge is disabled.
Here is the update to fix it.

Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'drm-vc4-fixes-2017-01-23' of https://github.com/anholt/linux into drm-fixes

This pull request brings in a few little error checking fixes and one
slow memory leak fix.

* tag 'drm-vc4-fixes-2017-01-23' of https://github.com/anholt/linux:
  drm/vc4: Return -EINVAL on the overflow checks failing.
  drm/vc4: Fix an integer overflow in temporary allocation layout.
  drm/vc4: fix a bounds check
  drm/vc4: Fix memory leak of the CRTC state.

Merge branch 'drm-fixes-4.10' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

Just a few small fixes.

* 'drm-fixes-4.10' of git://people.freedesktop.org/~agd5f/linux:
  Revert "drm/radeon: always apply pci shutdown callbacks"
  drm/amdgpu: fix unload driver issue for virtual display
  drm/amdgpu: check ring being ready before using

Merge tag 'drm-misc-fixes-2017-01-23' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes

Single fence fix.
* tag 'drm-misc-fixes-2017-01-23' of git://anongit.freedesktop.org/git/drm-misc:
  drm/fence: fix memory overwrite when setting out_fence fd

Merge branches 'acpica' and 'acpi-video'

* acpica:
  ACPICA: Tables: Fix hidden logic related to acpi_tb_install_standard_table()

* acpi-video:
  Revert "ACPI / video: Add force_native quirk for HP Pavilion dv6"

Merge branches 'pm-sleep' and 'pm-cpufreq'

* pm-sleep:
  Revert "PM / sleep / ACPI: Use the ACPI_FADT_LOW_POWER_S0 flag"

* pm-cpufreq:
  cpufreq: intel_pstate: Fix sysfs limits enforcement for performance policy

sysctl: fix proc_doulongvec_ms_jiffies_minmax()

We perform the conversion between kernel jiffies and ms only when
exporting kernel value to user space.

We need to do the opposite operation when value is written by user.

Only matters when HZ != 1000

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'pinctrl-v4.10-3' of git://git./linux/kernel/git/linusw/linux-pinctrl

Pull pin control fixes from Linus Walleij:
 "A bunch of pin control fixes for v4.10 that didn't get sent off until
  now, sorry for the delay.

  It's only driver fixes:

   - A bunch of fixes to the Intel drivers: broxton, baytrail. Bugs
     related to register offsets, IRQ, debounce functionality.

   - Fix a conflict amongst UART settings on the meson.

   - Fix the ethernet setting on the Uniphier.

   - A compilation warning squelched"

* tag 'pinctrl-v4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
  pinctrl: uniphier: fix Ethernet (RMII) pin-mux setting for LD20
  pinctrl: meson: fix uart_ao_b for GXBB and GXL/GXM
  pinctrl: amd: avoid maybe-uninitalized warning
  pinctrl: baytrail: Do not add all GPIOs to IRQ domain
  pinctrl: baytrail: Rectify debounce support
  pinctrl: intel: Set pin direction properly
  pinctrl: broxton: Use correct PADCFGLOCK offset

Merge tag 'drm-fixes-for-v4.10-rc6-revert-one' of git://people.freedesktop.org/~airlied/linux

Pull drm revert from Dave Airlie:
 "Revert one patch missing some prereqs.

  One of the connector fixes was missing some prereqs, we have an
  alternate driver fix that should work that I'll send tomorrow.

  Today is a holiday here so quickly smashing this out"

Daniel Vetter explains:
 "I pushed a locking change to fix a nouveau rpm issue to -fixes that
  needed the connector_list rework. And that's only in -next, but I
  missed that. Dave has the revert in a pull, and he'll follow-up with
  the hack nouveau patch for 4.10, and then we'll reapply the proper fix
  again for -next and revert the hacks. A bit a mess, but should be
  sorted soon"

* tag 'drm-fixes-for-v4.10-rc6-revert-one' of git://people.freedesktop.org/~airlied/linux:
  Revert "drm/probe-helpers: Drop locking from poll_enable"

Revert "drm/radeon: always apply pci shutdown callbacks"

This seems to break reboot on some evergreen systems.

bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=99524
https://bugzilla.kernel.org/show_bug.cgi?id=192271

This reverts commit a481daa88fd4d6b54f25348972bba10b5f6a84d0.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Revert "drm/probe-helpers: Drop locking from poll_enable"

This reverts commit 3846fd9b86001bea171943cc3bb9222cb6da6b42.

There were some precursor commits missing for this around connector
locking, we should probably merge Lyude's nouveau avoid the problem patch.

Merge tag 'for_linus' of git://git./linux/kernel/git/mst/vhost

Pull virtio/vhost fixes from Michael Tsirkin:

 - ARM DMA fixes

 - vhost vsock bugfix

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  vring: Force use of DMA API for ARM-based systems with legacy devices
  virtio_mmio: Set DMA masks appropriately
  vhost/vsock: handle vhost_vq_init_access() error

Revert "ACPI / video: Add force_native quirk for HP Pavilion dv6"

Revert commit 6276e53fa8c0 (ACPI / video: Add force_native quirk for
HP Pavilion dv6).

In the commit message for the quirk this revert removes I wrote:

"Note that there are quite a few HP Pavilion dv6 variants, some
woth ATI and some with NVIDIA hybrid gfx, both seem to need this
quirk to have working backlight control. There are also some versions
with only Intel integrated gfx, these may not need this quirk, but it
should not hurt there."

Unfortunately that seems wrong, I've already received 2 reports of
this commit causing regressions on some dv6 variants (at least one
of which actually has a nvidia GPU). So it seems that HP has made a
mess here by using the same model-name both in marketing and in the
DMI data for many different variants. Some of which need
acpi_backlight=native for functional backlight control (as the
quirk this commit reverts was doing), where as others are broken by
it. So lets get back to the old sitation so as to avoid regressing
on models which used to work without any kernel cmdline arguments
before.

Fixes: 6276e53fa8c0 (ACPI / video: Add force_native quirk for HP Pavilion dv6)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Merge tag 'gvt-fixes-2017-01-25' of https://github.com/01org/gvt-linux into drm-intel-fixes

gvt-fixes-2017-01-25

- re-enable shadow batch buffer for security that was falsely turned off.
- kvmgt/mdev typo fix for correct ABI
- gvt mail list change

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: reinstate call to trace_i915_vma_bind

The call went away in:

commit 3b16525cc4c1a43e9053cfdc414356eea24bdfad
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Thu Aug 4 16:32:25 2016 +0100

    drm/i915: Split insertion/binding of an object into the VM

It is useful to have this trace as it pairs nicely with the vma_unbind
one to track vma activity.
Added inside the i915_vma_bind function (was outside before) to keep a
similar placement as trace_i915_vma_unbind.

v2: print bind_flags instead of flags (Chris)

Fixes: 3b16525cc4c1 ("drm/i915: Split insertion/binding of an object into the VM")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484949083-11430-1-git-send-email-daniele.ceraolospurio@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 6146e6da5c961735dacf9b6c0c8b5f1382193ee2)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Move atomic state free from out of fence release

Fences are required to support being released from under an atomic context.
The drm_atomic_state struct may take a mutex when being released and so
we cannot drop a reference to the drm_atomic_state from the fence release
path directly, and so we need to defer that unreference to a worker.

[  326.576697] WARNING: CPU: 2 PID: 366 at kernel/sched/core.c:7737 __might_sleep+0x5d/0x80
[  326.576816] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffffc0359549>] intel_breadcrumbs_signaler+0x59/0x270 [i915]
[  326.576818] Modules linked in: rfcomm fuse snd_hda_codec_hdmi bnep snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer input_leds led_class snd punit_atom_debug btusb btrtl btbcm btintel intel_rapl bluetooth i915 drm_kms_helper syscopyarea sysfillrect iwlwifi sysimgblt soundcore fb_sys_fops mei_txe cfg80211 drm pwm_lpss_platform pwm_lpss pinctrl_cherryview fjes acpi_pad parport_pc ppdev parport autofs4
[  326.576899] CPU: 2 PID: 366 Comm: i915/signal:0 Tainted: G     U          4.10.0-rc3-patser+ #5030
[  326.576902] Hardware name:                  /NUC5PPYB, BIOS PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
[  326.576905] Call Trace:
[  326.576920]  dump_stack+0x4d/0x6d
[  326.576926]  __warn+0xc0/0xe0
[  326.576931]  warn_slowpath_fmt+0x5a/0x80
[  326.577004]  ? intel_breadcrumbs_signaler+0x59/0x270 [i915]
[  326.577075]  ? intel_breadcrumbs_signaler+0x59/0x270 [i915]
[  326.577079]  __might_sleep+0x5d/0x80
[  326.577087]  mutex_lock+0x1b/0x40
[  326.577133]  drm_property_free_blob+0x1e/0x80 [drm]
[  326.577167]  ? drm_property_destroy+0xe0/0xe0 [drm]
[  326.577200]  drm_mode_object_unreference+0x5c/0x70 [drm]
[  326.577233]  drm_property_unreference_blob+0xe/0x10 [drm]
[  326.577260]  __drm_atomic_helper_crtc_destroy_state+0x14/0x40 [drm_kms_helper]
[  326.577278]  drm_atomic_helper_crtc_destroy_state+0x10/0x20 [drm_kms_helper]
[  326.577352]  intel_crtc_destroy_state+0x9/0x10 [i915]
[  326.577388]  drm_atomic_state_default_clear+0xea/0x1d0 [drm]
[  326.577462]  intel_atomic_state_clear+0xd/0x20 [i915]
[  326.577497]  drm_atomic_state_clear+0x1a/0x30 [drm]
[  326.577532]  __drm_atomic_state_free+0x13/0x60 [drm]
[  326.577607]  intel_atomic_commit_ready+0x6f/0x78 [i915]
[  326.577670]  i915_sw_fence_release+0x3a/0x50 [i915]
[  326.577733]  dma_i915_sw_fence_wake+0x39/0x80 [i915]
[  326.577741]  dma_fence_signal+0xda/0x120
[  326.577812]  ? intel_breadcrumbs_signaler+0x59/0x270 [i915]
[  326.577884]  intel_breadcrumbs_signaler+0xb1/0x270 [i915]
[  326.577889]  kthread+0x127/0x130
[  326.577961]  ? intel_engine_remove_wait+0x1a0/0x1a0 [i915]
[  326.577964]  ? kthread_stop+0x120/0x120
[  326.577970]  ret_from_fork+0x22/0x30

Fixes: c004a90b7263 ("drm/i915: Restore nonblocking awaits for modesetting")
Reported-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170123212939.30345-1-chris@chris-wilson.co.uk
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit eb955eee27d9dc176871540c43c9070ee4701642)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Check for NULL atomic state in intel_crtc_disable_noatomic()

In intel_crtc_disable_noatomic(), bail on a failure to allocate an
atomic state to avoid a NULL pointer dereference.

Fixes: 4a80655827af ("drm/i915: Pass atomic state to crtc enable/disable functions")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484922525-6131-4-git-send-email-ander.conselvan.de.oliveira@intel.com
(cherry picked from commit 31bb2ef97ea9db343348f9b5ccaa9bb6f48fc655)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Fix calculation of rotated x and y offsets for planar formats

Parameters tile_size, tile_width and tile_height were passed in the
wrong order to _intel_adjust_tile_offset() when calculating the rotated
offsets.

This doesn't fix any user visible bug, since for packed formats new
and old offset are the same and the rotated offsets are within a tile
before they are fed to _intel_adjust_tile_offset(). In that case, the
offsets are unchanged. That is not true for planar formats, but those
are currently not supported.

Fixes: 66a2d927cb0e ("drm/i915: Make intel_adjust_tile_offset() work for linear buffers")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484922525-6131-3-git-send-email-ander.conselvan.de.oliveira@intel.com
(cherry picked from commit 46a1bd289507dfcc428fb9daf65421ed6be6af8b)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Don't init hpd polling for vlv and chv from runtime_suspend()

An error in the condition for avoiding the call to intel_hpd_poll_init()
for valleyview and cherryview from intel_runtime_suspend() caused it to
be called unconditionally. Fix it.

Fixes: 19625e85c6ec ("drm/i915: Enable polling when we don't have hpd")
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Lyude <cpaul@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484922525-6131-2-git-send-email-ander.conselvan.de.oliveira@intel.com
(cherry picked from commit 04313b00b79405f86d815100f85c47a2ee5b8ca0)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Don't leak edid in intel_crt_detect_ddc()

In the path where intel_crt_detect_ddc() detects a CRT, if would return
true without freeing the edid.

Fixes: a2bd1f541f19 ("drm/i915: check whether we actually received an edid in detect_ddc")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v3.6+
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484922525-6131-1-git-send-email-ander.conselvan.de.oliveira@intel.com
(cherry picked from commit c96b63a6a7ac4bd670ec2e663793a9a31418b790)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Release temporary load-detect state upon switching

After we call drm_atomic_commit() on the load-detect state, we can free
our local reference. Upon restore, we only apply and free the previous state.

Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170119113749.2517-1-chris@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
(cherry picked from commit 7abbd11f344aa7abe29befb218774a1ea26018ac)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: prevent crash with .disable_display parameter

The .disable_display parameter was causing a fatal crash when fbdev
was dereferenced during driver init.

V1: protection in i915_drv.c
V2: Moved protection to intel_fbdev.c

Fixes: 43cee314345a ("drm/i915/fbdev: Limit the global async-domain synchronization")
Testcase: igt/drv_module_reload/basic-no-display
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484775523-29428-1-git-send-email-clinton.a.taylor@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 5b8cd0755f8a06a851c436a013e7be0823fb155a)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Avoid drm_atomic_state_put(NULL) in intel_display_resume

intel_display_resume() may be called without an atomic state to restore,
i.e. dev_priv->modeset_reset_restore state is NULL. One such case is
following a lid open/close event and the forced modeset in
intel_lid_notify().

Reported-by: Stefan Seyfried <stefan.seyfried@googlemail.com>
Tested-by: Stefan Seyfried <stefan.seyfried@googlemail.com>
Fixes: 0853695c3ba4 ("drm: Add reference counting to drm_atomic_state")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170115125825.18597-1-chris@chris-wilson.co.uk
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
(cherry picked from commit 3c5e37f169cb67cbd03c6116fbc93e0805815d29)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

MAINTAINERS: update new mail list for intel gvt driver

We've moved to lists.freedesktop.org from lists.01.org.
Update info in MAINTAINERS.

Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt: Fix kmem_cache_create() name

According to kmem_cache_sanity_check(), spaces are not allowed in the
name of a cache and results in a kernel oops with CONFIG_DEBUG_VM.
Convert to underscores.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915/gvt/kvmgt: mdev ABI is available_instances, not available_instance

Per the ABI specification[1], each mdev_supported_types entry should
have an available_instances, with an "s", not available_instance.

[1] Documentation/ABI/testing/sysfs-bus-vfio-mdev

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>

Revert "thermal: thermal_hwmon: Convert to hwmon_device_register_with_info()"

This reverts commit 7611fb68062f ("thermal: thermal_hwmon: Convert to
hwmon_device_register_with_info()").

Pavel Machek reported breakage in the Nokia N900 due to this commit.

We can revisit a proper fix for the warning later.

Reported-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>

Merge branch 'akpm' (patches from Andrew)

Merge fixes from Andrew Morton:
 "26 fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>: (26 commits)
  MAINTAINERS: add Dan Streetman to zbud maintainers
  MAINTAINERS: add Dan Streetman to zswap maintainers
  mm: do not export ioremap_page_range symbol for external module
  mn10300: fix build error of missing fpu_save()
  romfs: use different way to generate fsid for BLOCK or MTD
  frv: add missing atomic64 operations
  mm, page_alloc: fix premature OOM when racing with cpuset mems update
  mm, page_alloc: move cpuset seqcount checking to slowpath
  mm, page_alloc: fix fast-path race with cpuset update or removal
  mm, page_alloc: fix check for NULL preferred_zone
  kernel/panic.c: add missing \n
  fbdev: color map copying bounds checking
  frv: add atomic64_add_unless()
  mm/mempolicy.c: do not put mempolicy before using its nodemask
  radix-tree: fix private list warnings
  Documentation/filesystems/proc.txt: add VmPin
  mm, memcg: do not retry precharge charges
  proc: add a schedule point in proc_pid_readdir()
  mm: alloc_contig: re-allow CMA to compact FS pages
  mm/slub.c: trace free objects at KERN_INFO
  ...

MAINTAINERS: add Dan Streetman to zbud maintainers

Add myself as zbud maintainer.

Link: http://lkml.kernel.org/r/20170124221705.26523-1-ddstreet@ieee.org
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Cc: Seth Jennings <sjenning@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

MAINTAINERS: add Dan Streetman to zswap maintainers

Add myself as zswap maintainer.

Link: http://lkml.kernel.org/r/20170124212200.19052-1-ddstreet@ieee.org
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Acked-by: Seth Jennings <sjenning@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: do not export ioremap_page_range symbol for external module

Recently, I've found cases in which ioremap_page_range was used
incorrectly, in external modules, leading to crashes.  This can be
partly attributed to the fact that ioremap_page_range is lower-level,
with fewer protections, as compared to the other functions that an
external module would typically call.  Those include:

     ioremap_cache
     ioremap_nocache
     ioremap_prot
     ioremap_uc
     ioremap_wc
     ioremap_wt

...each of which wraps __ioremap_caller, which in turn provides a safer
way to achieve the mapping.

Therefore, stop EXPORT-ing ioremap_page_range.

Link: http://lkml.kernel.org/r/1485173220-29010-1-git-send-email-zhongjiang@huawei.com
Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Suggested-by: John Hubbard <jhubbard@nvidia.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mn10300: fix build error of missing fpu_save()

When CONFIG_FPU is not enabled on arch/mn10300, <asm/switch_to.h> causes
a build error with a call to fpu_save():

  kernel/built-in.o: In function `.L410':
  core.c:(.sched.text+0x28a): undefined reference to `fpu_save'

Fix this by including <asm/fpu.h> in <asm/switch_to.h> so that an empty
static inline fpu_save() is defined.

Link: http://lkml.kernel.org/r/dc421c4f-4842-4429-1b99-92865c2f24b6@infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reviewed-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

romfs: use different way to generate fsid for BLOCK or MTD

Commit 8a59f5d25265 ("fs/romfs: return f_fsid for statfs(2)") generates
a 64bit id from sb->s_bdev->bd_dev.  This is only correct when romfs is
defined with CONFIG_ROMFS_ON_BLOCK.  If romfs is only defined with
CONFIG_ROMFS_ON_MTD, sb->s_bdev is NULL, referencing sb->s_bdev->bd_dev
will triger an oops.

Richard Weinberger points out that when CONFIG_ROMFS_BACKED_BY_BOTH=y,
both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD are defined.
Therefore when calling huge_encode_dev() to generate a 64bit id, I use
the follow order to choose parameter,

- CONFIG_ROMFS_ON_BLOCK defined
  use sb->s_bdev->bd_dev
- CONFIG_ROMFS_ON_BLOCK undefined and CONFIG_ROMFS_ON_MTD defined
  use sb->s_dev when,
- both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD undefined
  leave id as 0

When CONFIG_ROMFS_ON_MTD is defined and sb->s_mtd is not NULL, sb->s_dev
is set to a device ID generated by MTD_BLOCK_MAJOR and mtd index,
otherwise sb->s_dev is 0.

This is a try-best effort to generate a uniq file system ID, if all the
above conditions are not meet, f_fsid of this romfs instance will be 0.
Generally only one romfs can be built on single MTD block device, this
method is enough to identify multiple romfs instances in a computer.

Link: http://lkml.kernel.org/r/1482928596-115155-1-git-send-email-colyli@suse.de
Signed-off-by: Coly Li <colyli@suse.de>
Reported-by: Nong Li <nongli1031@gmail.com>
Tested-by: Nong Li <nongli1031@gmail.com>
Cc: Richard Weinberger <richard.weinberger@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

frv: add missing atomic64 operations

Some more atomic64 operations were missing and as a result frv
allmodconfig was failing.  Add the missing operations.

Link: http://lkml.kernel.org/r/1485193844-12850-1-git-send-email-sudip.mukherjee@codethink.co.uk
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, page_alloc: fix premature OOM when racing with cpuset mems update

Ganapatrao Kulkarni reported that the LTP test cpuset01 in stress mode
triggers OOM killer in few seconds, despite lots of free memory.  The
test attempts to repeatedly fault in memory in one process in a cpuset,
while changing allowed nodes of the cpuset between 0 and 1 in another
process.

The problem comes from insufficient protection against cpuset changes,
which can cause get_page_from_freelist() to consider all zones as
non-eligible due to nodemask and/or current->mems_allowed.  This was
masked in the past by sufficient retries, but since commit 682a3385e773
("mm, page_alloc: inline the fast path of the zonelist iterator") we fix
the preferred_zoneref once, and don't iterate over the whole zonelist in
further attempts, thus the only eligible zones might be placed in the
zonelist before our starting point and we always miss them.

A previous patch fixed this problem for current->mems_allowed.  However,
cpuset changes also update the task's mempolicy nodemask.  The fix has
two parts.  We have to repeat the preferred_zoneref search when we
detect cpuset update by way of seqcount, and we have to check the
seqcount before considering OOM.

[akpm@linux-foundation.org: fix typo in comment]
Link: http://lkml.kernel.org/r/20170120103843.24587-5-vbabka@suse.cz
Fixes: c33d6c06f60f ("mm, page_alloc: avoid looking up the first zone in a zonelist twice")
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Ganapatrao Kulkarni <gpkulkarni@gmail.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, page_alloc: move cpuset seqcount checking to slowpath

This is a preparation for the following patch to make review simpler.
While the primary motivation is a bug fix, this also simplifies the fast
path, although the moved code is only enabled when cpusets are in use.

Link: http://lkml.kernel.org/r/20170120103843.24587-4-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Ganapatrao Kulkarni <gpkulkarni@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, page_alloc: fix fast-path race with cpuset update or removal

Ganapatrao Kulkarni reported that the LTP test cpuset01 in stress mode
triggers OOM killer in few seconds, despite lots of free memory.  The
test attempts to repeatedly fault in memory in one process in a cpuset,
while changing allowed nodes of the cpuset between 0 and 1 in another
process.

One possible cause is that in the fast path we find the preferred
zoneref according to current mems_allowed, so that it points to the
middle of the zonelist, skipping e.g.  zones of node 1 completely.  If
the mems_allowed is updated to contain only node 1, we never reach it in
the zonelist, and trigger OOM before checking the cpuset_mems_cookie.

This patch fixes the particular case by redoing the preferred zoneref
search if we switch back to the original nodemask.  The condition is
also slightly changed so that when the last non-root cpuset is removed,
we don't miss it.

Note that this is not a full fix, and more patches will follow.

Link: http://lkml.kernel.org/r/20170120103843.24587-3-vbabka@suse.cz
Fixes: 682a3385e773 ("mm, page_alloc: inline the fast path of the zonelist iterator")
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Reported-by: Ganapatrao Kulkarni <gpkulkarni@gmail.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, page_alloc: fix check for NULL preferred_zone

Patch series "fix premature OOM regression in 4.7+ due to cpuset races".

This is v2 of my attempt to fix the recent report based on LTP cpuset
stress test [1].  The intention is to go to stable 4.9 LTSS with this,
as triggering repeated OOMs is not nice.  That's why the patches try to
be not too intrusive.

Unfortunately why investigating I found that modifying the testcase to
use per-VMA policies instead of per-task policies will bring the OOM's
back, but that seems to be much older and harder to fix problem.  I have
posted a RFC [2] but I believe that fixing the recent regressions has a
higher priority.

Longer-term we might try to think how to fix the cpuset mess in a better
and less error prone way.  I was for example very surprised to learn,
that cpuset updates change not only task->mems_allowed, but also
nodemask of mempolicies.  Until now I expected the parameter to
alloc_pages_nodemask() to be stable.  I wonder why do we then treat
cpusets specially in get_page_from_freelist() and distinguish HARDWALL
etc, when there's unconditional intersection between mempolicy and
cpuset.  I would expect the nodemask adjustment for saving overhead in
g_p_f(), but that clearly doesn't happen in the current form.  So we
have both crazy complexity and overhead, AFAICS.

[1] https://lkml.kernel.org/r/CAFpQJXUq-JuEP=QPidy4p_=FN0rkH5Z-kfB4qBvsf6jMS87Edg@mail.gmail.com
[2] https://lkml.kernel.org/r/7c459f26-13a6-a817-e508-b65b903a8378@suse.cz

This patch (of 4):

Since commit c33d6c06f60f ("mm, page_alloc: avoid looking up the first
zone in a zonelist twice") we have a wrong check for NULL preferred_zone,
which can theoretically happen due to concurrent cpuset modification.  We
check the zoneref pointer which is never NULL and we should check the zone
pointer.  Also document this in first_zones_zonelist() comment per Michal
Hocko.

Fixes: c33d6c06f60f ("mm, page_alloc: avoid looking up the first zone in a zonelist twice")
Link: http://lkml.kernel.org/r/20170120103843.24587-2-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Ganapatrao Kulkarni <gpkulkarni@gmail.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/panic.c: add missing \n

When a system panics, the "Rebooting in X seconds.." message is never
printed because it lacks a new line.  Fix it.

Link: http://lkml.kernel.org/r/20170119114751.2724-1-jslaby@suse.cz
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

fbdev: color map copying bounds checking

Copying color maps to userspace doesn't check the value of to->start,
which will cause kernel heap buffer OOB read due to signedness wraps.

CVE-2016-8405

Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: Peter Pi (@heisecode) of Trend Micro
Cc: Min Chong <mchong@google.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

frv: add atomic64_add_unless()

The build of frv allmodconfig was failing with the error:
lib/atomic64_test.c:209:9: error:

implicit declaration of function 'atomic64_add_unless'

All the atomic64 operations were defined in frv, but
atomic64_add_unless() was not done.

Implement atomic64_add_unless() as done in other arches.

Link: http://lkml.kernel.org/r/1484781236-6698-1-git-send-email-sudipm.mukherjee@gmail.com
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/mempolicy.c: do not put mempolicy before using its nodemask

Since commit be97a41b291e ("mm/mempolicy.c: merge alloc_hugepage_vma to
alloc_pages_vma") alloc_pages_vma() can potentially free a mempolicy by
mpol_cond_put() before accessing the embedded nodemask by
__alloc_pages_nodemask().  The commit log says it's so "we can use a
single exit path within the function" but that's clearly wrong.  We can
still do that when doing mpol_cond_put() after the allocation attempt.

Make sure the mempolicy is not freed prematurely, otherwise
__alloc_pages_nodemask() can end up using a bogus nodemask, which could
lead e.g.  to premature OOM.

Fixes: be97a41b291e ("mm/mempolicy.c: merge alloc_hugepage_vma to alloc_pages_vma")
Link: http://lkml.kernel.org/r/20170118141124.8345-1-vbabka@suse.cz
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org> [4.0+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

radix-tree: fix private list warnings

The newly introduced warning in radix_tree_free_nodes() was testing the
wrong variable; it should have been 'old' instead of 'node'.

Fixes: ea07b862ac8e ("mm: workingset: fix use-after-free in shadow node shrinker")
Link: http://lkml.kernel.org/r/20170118163746.GA32495@cmpxchg.org
Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Documentation/filesystems/proc.txt: add VmPin

Commit bc3e53f682d9 ("mm: distinguish between mlocked and pinned pages")
added VmPin in /proc/<pid>/status.  Report that in
Documentation/filesystems/proc.txt

Also move Umask after Name to keep correct order.

Link: http://lkml.kernel.org/r/20170114201219.30387-1-fabf@skynet.be
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Cc: Christoph Lameter <cl@linux.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm, memcg: do not retry precharge charges

When memory.move_charge_at_immigrate is enabled and precharges are
depleted during move, mem_cgroup_move_charge_pte_range() will attempt to
increase the size of the precharge.

Prevent precharges from ever looping by setting __GFP_NORETRY.  This was
probably the intention of the GFP_KERNEL & ~__GFP_NORETRY, which is
pointless as written.

Fixes: 0029e19ebf84 ("mm: memcontrol: remove explicit OOM parameter in charge path")
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1701130208510.69402@chino.kir.corp.google.com
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

proc: add a schedule point in proc_pid_readdir()

We have seen proc_pid_readdir() invocations holding cpu for more than 50
ms.  Add a cond_resched() to be gentle with other tasks.

[akpm@linux-foundation.org: coding style fix]
Link: http://lkml.kernel.org/r/1484238380.15816.42.camel@edumazet-glaptop3.roam.corp.google.com
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: alloc_contig: re-allow CMA to compact FS pages

Commit 73e64c51afc5 ("mm, compaction: allow compaction for GFP_NOFS
requests") changed compation to skip FS pages if not explicitly allowed
to touch them, but missed to update the CMA compact_control.

This leads to a very high isolation failure rate, crippling performance
of CMA even on a lightly loaded system.  Re-allow CMA to compact FS
pages by setting the correct GFP flags, restoring CMA behavior and
performance to the kernel 4.9 level.

Fixes: 73e64c51afc5 (mm, compaction: allow compaction for GFP_NOFS requests)
Link: http://lkml.kernel.org/r/20170113115155.24335-1-l.stach@pengutronix.de
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/slub.c: trace free objects at KERN_INFO

Currently when trace is enabled (e.g.  slub_debug=T,kmalloc-128 ) the
trace messages are mostly output at KERN_INFO.  However the trace code
also calls print_section() to hexdump the head of a free object.  This
is hard coded to use KERN_ERR, meaning the console is deluged with trace
messages even if we've asked for quiet.

Fix this the obvious way but adding a level parameter to
print_section(), allowing calls from the trace code to use the same
trace level as other trace messages.

Link: http://lkml.kernel.org/r/20170113154850.518-1-daniel.thompson@linaro.org
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Christoph Lameter <cl@linux.com>
Acked-by: David Rientjes <rientjes@google.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

userfaultfd: fix SIGBUS resulting from false rwsem wakeups

With >=32 CPUs the userfaultfd selftest triggered a graceful but
unexpected SIGBUS because VM_FAULT_RETRY was returned by
handle_userfault() despite the UFFDIO_COPY wasn't completed.

This seems caused by rwsem waking the thread blocked in
handle_userfault() and we can't run up_read() before the wait_event
sequence is complete.

Keeping the wait_even sequence identical to the first one, would require
running userfaultfd_must_wait() again to know if the loop should be
repeated, and it would also require retaking the rwsem and revalidating
the whole vma status.

It seems simpler to wait the targeted wakeup so that if false wakeups
materialize we still wait for our specific wakeup event, unless of
course there are signals or the uffd was released.

Debug code collecting the stack trace of the wakeup showed this:

  $ ./userfaultfd 100 99999
  nr_pages: 25600, nr_pages_per_cpu: 800
  bounces: 99998, mode: racing ver poll, userfaults: 32 35 90 232 30 138 69 82 34 30 139 40 40 31 20 19 43 13 15 28 27 38 21 43 56 22 1 17 31 8 4 2
  bounces: 99997, mode: rnd ver poll, Bus error (core dumped)

    save_stack_trace+0x2b/0x50
    try_to_wake_up+0x2a6/0x580
    wake_up_q+0x32/0x70
    rwsem_wake+0xe0/0x120
    call_rwsem_wake+0x1b/0x30
    up_write+0x3b/0x40
    vm_mmap_pgoff+0x9c/0xc0
    SyS_mmap_pgoff+0x1a9/0x240
    SyS_mmap+0x22/0x30
    entry_SYSCALL_64_fastpath+0x1f/0xbd
    0xffffffffffffffff
    FAULT_FLAG_ALLOW_RETRY missing 70
  CPU: 24 PID: 1054 Comm: userfaultfd Tainted: G        W       4.8.0+ #30
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
  Call Trace:
    dump_stack+0xb8/0x112
    handle_userfault+0x572/0x650
    handle_mm_fault+0x12cb/0x1520
    __do_page_fault+0x175/0x500
    trace_do_page_fault+0x61/0x270
    do_async_page_fault+0x19/0x90
    async_page_fault+0x25/0x30

This always happens when the main userfault selftest thread is running
clone() while glibc runs either mprotect or mmap (both taking mmap_sem
down_write()) to allocate the thread stack of the background threads,
while locking/userfault threads already run at full throttle and are
susceptible to false wakeups that may cause handle_userfault() to return
before than expected (which results in graceful SIGBUS at the next
attempt).

This was reproduced only with >=32 CPUs because the loop to start the
thread where clone() is too quick with fewer CPUs, while with 32 CPUs
there's already significant activity on ~32 locking and userfault
threads when the last background threads are started with clone().

This >=32 CPUs SMP race condition is likely reproducible only with the
selftest because of the much heavier userfault load it generates if
compared to real apps.

We'll have to allow "one more" VM_FAULT_RETRY for the WP support and a
patch floating around that provides it also hidden this problem but in
reality only is successfully at hiding the problem.

False wakeups could still happen again the second time
handle_userfault() is invoked, even if it's a so rare race condition
that getting false wakeups twice in a row is impossible to reproduce.
This full fix is needed for correctness, the only alternative would be
to allow VM_FAULT_RETRY to be returned infinitely.  With this fix the WP
support can stick to a strict "one more" VM_FAULT_RETRY logic (no need
of returning it infinite times to avoid the SIGBUS).

Link: http://lkml.kernel.org/r/20170111005535.13832-2-aarcange@redhat.com
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Reported-by: Shubham Kumar Sharma <shubham.kumar.sharma@oracle.com>
Tested-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Michael Rapoport <RAPOPORT@il.ibm.com>
Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drivers/memstick/core/memstick.c: avoid -Wnonnull warning

gcc-7 produces a harmless false-postive warning about a possible NULL
pointer access:

  drivers/memstick/core/memstick.c: In function 'h_memstick_read_dev_id':
  drivers/memstick/core/memstick.c:309:3: error: argument 2 null where non-null expected [-Werror=nonnull]
     memcpy(mrq->data, buf, mrq->data_len);

This can't happen because the caller sets the command to 'MS_TPC_READ_REG',
which causes the data direction to be 'READ' and the NULL pointer not
accessed.

As a simple workaround for the warning, we can pass a pointer to the
data that we actually want to read into.  This is not needed here, but
also harmless, and lets the compiler know that the access is ok.

Link: http://lkml.kernel.org/r/20170111144143.548867-1-arnd@arndb.de
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Alex Dubov <oakad@yahoo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

kernel/watchdog: prevent false hardlockup on overloaded system

On an overloaded system, it is possible that a change in the watchdog
threshold can be delayed long enough to trigger a false positive.

This can easily be achieved by having a cpu spinning indefinitely on a
task, while another cpu updates watchdog threshold.

What happens is while trying to park the watchdog threads, the hrtimers
on the other cpus trigger and reprogram themselves with the new slower
watchdog threshold.  Meanwhile, the nmi watchdog is still programmed
with the old faster threshold.

Because the one cpu is blocked, it prevents the thread parking on the
other cpus from completing, which is needed to shutdown the nmi watchdog
and reprogram it correctly.  As a result, a false positive from the nmi
watchdog is reported.

Fix this by setting a park_in_progress flag to block all lockups until
the parking is complete.

Fix provided by Ulrich Obergfell.

[akpm@linux-foundation.org: s/park_in_progress/watchdog_park_in_progress/]
Link: http://lkml.kernel.org/r/1481041033-192236-1-git-send-email-dzickus@redhat.com
Signed-off-by: Don Zickus <dzickus@redhat.com>
Reviewed-by: Aaron Tomlin <atomlin@redhat.com>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

dax: fix build warnings with FS_DAX and !FS_IOMAP

As reported by Arnd:

  https://lkml.org/lkml/2017/1/10/756

Compiling with the following configuration:

  # CONFIG_EXT2_FS is not set
  # CONFIG_EXT4_FS is not set
  # CONFIG_XFS_FS is not set
  # CONFIG_FS_IOMAP depends on the above filesystems, as is not set
  CONFIG_FS_DAX=y

generates build warnings about unused functions in fs/dax.c:

  fs/dax.c:878:12: warning: `dax_insert_mapping' defined but not used [-Wunused-function]
   static int dax_insert_mapping(struct address_space *mapping,
              ^~~~~~~~~~~~~~~~~~
  fs/dax.c:572:12: warning: `copy_user_dax' defined but not used [-Wunused-function]
   static int copy_user_dax(struct block_device *bdev, sector_t sector, size_t size,
              ^~~~~~~~~~~~~
  fs/dax.c:542:12: warning: `dax_load_hole' defined but not used [-Wunused-function]
   static int dax_load_hole(struct address_space *mapping, void **entry,
              ^~~~~~~~~~~~~
  fs/dax.c:312:14: warning: `grab_mapping_entry' defined but not used [-Wunused-function]
   static void *grab_mapping_entry(struct address_space *mapping, pgoff_t index,
                ^~~~~~~~~~~~~~~~~~

Now that the struct buffer_head based DAX fault paths and I/O path have
been removed we really depend on iomap support being present for DAX.
Make this explicit by selecting FS_IOMAP if we compile in DAX support.

This allows us to remove conditional selections of FS_IOMAP when FS_DAX
was present for ext2 and ext4, and to remove an #ifdef in fs/dax.c.

Link: http://lkml.kernel.org/r/1484087383-29478-1-git-send-email-ross.zwisler@linux.intel.com
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp

In commit 19be0eaffa3a ("mm: remove gup_flags FOLL_WRITE games from
__get_user_pages()"), the mm code was changed from unsetting FOLL_WRITE
after a COW was resolved to setting the (newly introduced) FOLL_COW
instead.  Simultaneously, the check in gup.c was updated to still allow
writes with FOLL_FORCE set if FOLL_COW had also been set.

However, a similar check in huge_memory.c was forgotten.  As a result,
remote memory writes to ro regions of memory backed by transparent huge
pages cause an infinite loop in the kernel (handle_mm_fault sets
FOLL_COW and returns 0 causing a retry, but follow_trans_huge_pmd bails
out immidiately because `(flags & FOLL_WRITE) && !pmd_write(*pmd)` is
true.

While in this state the process is stil SIGKILLable, but little else
works (e.g.  no ptrace attach, no other signals).  This is easily
reproduced with the following code (assuming thp are set to always):

    #include <assert.h>
    #include <fcntl.h>
    #include <stdint.h>
    #include <stdio.h>
    #include <string.h>
    #include <sys/mman.h>
    #include <sys/stat.h>
    #include <sys/types.h>
    #include <sys/wait.h>
    #include <unistd.h>

    #define TEST_SIZE 5 * 1024 * 1024

    int main(void) {
      int status;
      pid_t child;
      int fd = open("/proc/self/mem", O_RDWR);
      void *addr = mmap(NULL, TEST_SIZE, PROT_READ,
                        MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
      assert(addr != MAP_FAILED);
      pid_t parent_pid = getpid();
      if ((child = fork()) == 0) {
        void *addr2 = mmap(NULL, TEST_SIZE, PROT_READ | PROT_WRITE,
                           MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
        assert(addr2 != MAP_FAILED);
        memset(addr2, 'a', TEST_SIZE);
        pwrite(fd, addr2, TEST_SIZE, (uintptr_t)addr);
        return 0;
      }
      assert(child == waitpid(child, &status, 0));
      assert(WIFEXITED(status) && WEXITSTATUS(status) == 0);
      return 0;
    }

Fix this by updating follow_trans_huge_pmd in huge_memory.c analogously
to the update in gup.c in the original commit.  The same pattern exists
in follow_devmap_pmd.  However, we should not be able to reach that
check with FOLL_COW set, so add WARN_ONCE to make sure we notice if we
ever do.

[akpm@linux-foundation.org: coding-style fixes]
Link: http://lkml.kernel.org/r/20170106015025.GA38411@juliacomputing.com
Signed-off-by: Keno Fischer <keno@juliacomputing.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Greg Thelen <gthelen@google.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

memory_hotplug: make zone_can_shift() return a boolean value

online_{kernel|movable} is used to change the memory zone to
ZONE_{NORMAL|MOVABLE} and online the memory.

To check that memory zone can be changed, zone_can_shift() is used.
Currently the function returns minus integer value, plus integer
value and 0. When the function returns minus or plus integer value,
it means that the memory zone can be changed to ZONE_{NORNAL|MOVABLE}.

But when the function returns 0, there are two meanings.

One of the meanings is that the memory zone does not need to be changed.
For example, when memory is in ZONE_NORMAL and onlined by online_kernel
the memory zone does not need to be changed.

Another meaning is that the memory zone cannot be changed. When memory
is in ZONE_NORMAL and onlined by online_movable, the memory zone may
not be changed to ZONE_MOVALBE due to memory online limitation(see
Documentation/memory-hotplug.txt). In this case, memory must not be
onlined.

The patch changes the return type of zone_can_shift() so that memory
online operation fails when memory zone cannot be changed as follows:

Before applying patch:
   # grep -A 35 "Node 2" /proc/zoneinfo
   Node 2, zone   Normal
   <snip>
      node_scanned  0
           spanned  8388608
           present  7864320
           managed  7864320
   # echo online_movable > memory4097/state
   # grep -A 35 "Node 2" /proc/zoneinfo
   Node 2, zone   Normal
   <snip>
      node_scanned  0
           spanned  8388608
           present  8388608
           managed  8388608

   online_movable operation succeeded. But memory is onlined as
   ZONE_NORMAL, not ZONE_MOVABLE.

After applying patch:
   # grep -A 35 "Node 2" /proc/zoneinfo
   Node 2, zone   Normal
   <snip>
      node_scanned  0
           spanned  8388608
           present  7864320
           managed  7864320
   # echo online_movable > memory4097/state
   bash: echo: write error: Invalid argument
   # grep -A 35 "Node 2" /proc/zoneinfo
   Node 2, zone   Normal
   <snip>
      node_scanned  0
           spanned  8388608
           present  7864320
           managed  7864320

   online_movable operation failed because of failure of changing
   the memory zone from ZONE_NORMAL to ZONE_MOVABLE

Fixes: df429ac03936 ("memory-hotplug: more general validation of zone during online")
Link: http://lkml.kernel.org/r/2f9c3837-33d7-b6e5-59c0-6ca4372b2d84@gmail.com
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Reza Arbab <arbab@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

vring: Force use of DMA API for ARM-based systems with legacy devices

Booting Linux on an ARM fastmodel containing an SMMU emulation results
in an unexpected I/O page fault from the legacy virtio-blk PCI device:

[    1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
[    1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
[    1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
[    1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
[    1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
[    1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
[    1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
[    1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
[    1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
[    1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000

<system hangs failing to read partition table>

This is because the legacy virtio-blk device is behind an SMMU, so we
have consequently swizzled its DMA ops and configured the SMMU to
translate accesses. This then requires the vring code to use the DMA API
to establish translations, otherwise all transactions will result in
fatal faults and termination.

Given that ARM-based systems only see an SMMU if one is really present
(the topology is all described by firmware tables such as device-tree or
IORT), then we can safely use the DMA API for all legacy virtio devices.
Modern devices can advertise the prescense of an IOMMU using the
VIRTIO_F_IOMMU_PLATFORM feature flag.

Cc: Andy Lutomirski <luto@kernel.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: <stable@vger.kernel.org>
Fixes: 876945dbf649 ("arm64: Hook up IOMMU dma_ops")
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>

virtio_mmio: Set DMA masks appropriately

Once DMA API usage is enabled, it becomes apparent that virtio-mmio is
inadvertently relying on the default 32-bit DMA mask, which leads to
problems like rapidly exhausting SWIOTLB bounce buffers.

Ensure that we set the appropriate 64-bit DMA mask whenever possible,
with the coherent mask suitably limited for the legacy vring as per
a0be1db4304f ("virtio_pci: Limit DMA mask to 44 bits for legacy virtio
devices").

Cc: Andy Lutomirski <luto@kernel.org>
Cc: Michael S. Tsirkin <mst@redhat.com>
Reported-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Fixes: b42111382f0e ("virtio_mmio: Use the DMA API if enabled")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

vhost/vsock: handle vhost_vq_init_access() error

Propagate the error when vhost_vq_init_access() fails and set
vq->private_data to NULL.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>

Merge tag 'platform-drivers-x86-v4.10-4' of git://git.infradead.org/linux-platform-drivers-x86

Pull x86 platform-driver fixes from Andy Shevchenko:
 "This is my first pull request since I become a co-maintainer of
  Platform Drivers x86 subsystem. It's a bit bigger than usual due to
  material collected for almost two weeks in a row.

  MAINTAINERS:
   - Add myself to X86 PLATFORM DRIVERS as a co-maintainer

  ideapad-laptop:
   - handle ACPI event 1

  intel_mid_powerbtn:
   - Set IRQ_ONESHOT

  surface3-wmi:
   - fix uninitialized symbol
   - Shut up unused-function warning

  mlx-platform:
   - free first dev on error"

* tag 'platform-drivers-x86-v4.10-4' of git://git.infradead.org/linux-platform-drivers-x86:
  MAINTAINERS: Add myself to X86 PLATFORM DRIVERS as a co-maintainer
  platform/x86: ideapad-laptop: handle ACPI event 1
  platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT
  platform/x86: surface3-wmi: fix uninitialized symbol
  platform/x86: surface3-wmi: Shut up unused-function warning
  platform/x86: mlx-platform: free first dev on error

Merge branch 'for-linus' of git://git./linux/kernel/git/ebiederm/user-namespace

Pull namespace fix from Eric Biederman:
 "This has a single brown bag fix.

  The possible deadlock with dec_pid_namespaces that I had thought was
  fixed earlier turned out only to have been moved. So instead of being
  cleaver this change takes ucounts_lock with irqs disabled. So
  dec_ucount can be used from any context without fear of deadlock.

  The items accounted for dec_ucount and inc_ucount are all
  comparatively heavy weight objects so I don't exepct this will have
  any measurable performance impact"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
  userns: Make ucounts lock irq-safe

vfio/spapr: fail tce_iommu_attach_group() when iommu_data is null

The recently added mediated VFIO driver doesn't know about powerpc iommu.
It thus doesn't register a struct iommu_table_group in the iommu group
upon device creation. The iommu_data pointer hence remains null.

This causes a kernel oops when userspace tries to set the iommu type of a
container associated with a mediated device to VFIO_SPAPR_TCE_v2_IOMMU.

[   82.585440] mtty mtty: MDEV: Registered
[   87.655522] iommu: Adding device 83b8f4f2-509f-382f-3c1e-e6bfe0fa1001 to group 10
[   87.655527] vfio_mdev 83b8f4f2-509f-382f-3c1e-e6bfe0fa1001: MDEV: group_id = 10
[  116.297184] Unable to handle kernel paging request for data at address 0x00000030
[  116.297389] Faulting instruction address: 0xd000000007870524
[  116.297465] Oops: Kernel access of bad area, sig: 11 [#1]
[  116.297611] SMP NR_CPUS=2048
[  116.297611] NUMA
[  116.297627] PowerNV
...
[  116.297954] CPU: 33 PID: 7067 Comm: qemu-system-ppc Not tainted 4.10.0-rc5-mdev-test #8
[  116.297993] task: c000000e7718b680 task.stack: c000000e77214000
[  116.298025] NIP: d000000007870524 LR: d000000007870518 CTR: 0000000000000000
[  116.298064] REGS: c000000e77217990 TRAP: 0300   Not tainted  (4.10.0-rc5-mdev-test)
[  116.298103] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
[  116.298107]   CR: 84004444  XER: 00000000
[  116.298154] CFAR: c00000000000888c DAR: 0000000000000030 DSISR: 40000000 SOFTE: 1
               GPR00: d000000007870518 c000000e77217c10 d00000000787b0ed c000000eed2103c0
               GPR04: 0000000000000000 0000000000000000 c000000eed2103e0 0000000f24320000
               GPR08: 0000000000000104 0000000000000001 0000000000000000 d0000000078729b0
               GPR12: c00000000025b7e0 c00000000fe08400 0000000000000001 000001002d31d100
               GPR16: 000001002c22c850 00003ffff315c750 0000000043145680 0000000043141bc0
               GPR20: ffffffffffffffed fffffffffffff000 0000000020003b65 d000000007706018
               GPR24: c000000f16cf0d98 d000000007706000 c000000003f42980 c000000003f42980
               GPR28: c000000f1575ac00 c000000003f429c8 0000000000000000 c000000eed2103c0
[  116.298504] NIP [d000000007870524] tce_iommu_attach_group+0x10c/0x360 [vfio_iommu_spapr_tce]
[  116.298555] LR [d000000007870518] tce_iommu_attach_group+0x100/0x360 [vfio_iommu_spapr_tce]
[  116.298601] Call Trace:
[  116.298610] [c000000e77217c10] [d000000007870518] tce_iommu_attach_group+0x100/0x360 [vfio_iommu_spapr_tce] (unreliable)
[  116.298671] [c000000e77217cb0] [d0000000077033a0] vfio_fops_unl_ioctl+0x278/0x3e0 [vfio]
[  116.298713] [c000000e77217d40] [c0000000002a3ebc] do_vfs_ioctl+0xcc/0x8b0
[  116.298745] [c000000e77217de0] [c0000000002a4700] SyS_ioctl+0x60/0xc0
[  116.298782] [c000000e77217e30] [c00000000000b220] system_call+0x38/0xfc
[  116.298812] Instruction dump:
[  116.298828] 7d3f4b78 409effc8 3d220000 e9298020 3c800140 38a00018 608480c0 e8690028
[  116.298869] 4800249d e8410018 7c7f1b79 41820230 <e93e0030> 2fa90000 419e0114 e9090020
[  116.298914] ---[ end trace 1e10b0ced08b9120 ]---

This patch fixes the oops.

Reported-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>

MAINTAINERS: Add myself to X86 PLATFORM DRIVERS as a co-maintainer

For last few months Darren and I are co-maintaining PDx86 subsystem.
Make this fact official by updating MAINTAINERS database.

Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Merge branch 'stable' of git://git./linux/kernel/git/cmetcalf/linux-tile

Pull tile bugfix from Chris Metcalf:
 "This avoids an issue with short userspace reads for regset via ptrace"

* 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile:
  tile/ptrace: Preserve previous registers for short regset write

drm/amdgpu: fix unload driver issue for virtual display

Virtual display doesn't allocate amdgpu_encoder when initializing,
so will get invaild pointer if try to free amdgpu_encoder when
unloading driver.

Signed-off-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amdgpu: check ring being ready before using

Return success when the ring is properly initialized, otherwise return
failure.

Tonga SRIOV VF doesn't have UVD and VCE engines, the initialization of
these IPs is bypassed. The system crashes if application submit IB to
their rings which are not ready to use. It could be a common issue if
IP having ring buffer is disabled for some reason on specific ASIC, so
it should check the ring being ready to use.

Bug: amdgpu_test crashes system on Tonga VF.

Signed-off-by: Ding Pixel <Pixel.Ding@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Merge tag 'gpio-v4.10-3' of git://git./linux/kernel/git/linusw/linux-gpio

Pull GPIO fix from Linus Walleij:
 "A single lockdep fix, nothing else going on. This makes lockdep
  noiseless and work properly with threaded GPIO IRQchips.

  Summary:

  Fix a lockdep issue: the threaded irqchips also need their unique key,
  and take this opportunity to get rid of the horrible macro and replace
  it with a static inline"

* tag 'gpio-v4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: provide lockdep keys for nested/unnested irqchips

Merge tag 'drm-fixes-for-v4.10-rc6' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "drm fixes across the board.

  Okay holidays and LCA kinda caught up with me, I thought I'd get some
  of this dequeued last week, but Hobart was sunny and warm and not all
  gloomy and rainy as usual.

  This is a bit large, but not too much considering it's two weeks stuff
  from AMD and Intel.

  core:
   - one locking fix that helps with dynamic suspend/resume races

  i915:
   - mostly GVT updates, GVT was a recent introduction so fixes for it
     shouldn't cause any notable side effects.

  amdgpu:
   - a bunch of fixes for GPUs with a different memory controller design
     that need different firmware.

  exynos:
   - decon regression fixes

  msm:
   - two regression fixes

  etnaviv:
   - a workaround for an mmu bug that needs a lot more work.

  virtio:
   - sparse fix, and a maintainers update"

* tag 'drm-fixes-for-v4.10-rc6' of git://people.freedesktop.org/~airlied/linux: (56 commits)
  drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
  drm/exynos/decon5433: fix CMU programming
  drm/exynos/decon5433: do not disable video after reset
  drm/i915: Ignore bogus plane coordinates on SKL when the plane is not visible
  drm/i915: Remove WaDisableLSQCROPERFforOCL KBL workaround.
  drm/amdgpu: add support for new hainan variants
  drm/radeon: add support for new hainan variants
  drm/amdgpu: change clock gating mode for uvd_v4.
  drm/amdgpu: fix program vce instance logic error.
  drm/amdgpu: fix bug set incorrect value to vce register
  Revert "drm/amdgpu: Only update the CUR_SIZE register when necessary"
  drm/msm: fix potential null ptr issue in non-iommu case
  drm/msm/mdp5: rip out plane->pending tracking
  drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
  drm/exynos/decon5433: update shadow registers iff there are active windows
  drm/i915/gvt: rewrite gt reset handler using new function intel_gvt_reset_vgpu_locked
  drm/i915/gvt: fix vGPU instance reuse issues by vGPU reset function
  drm/i915/gvt: introduce intel_vgpu_reset_mmio() to reset mmio space
  drm/i915/gvt: move mmio init/clean function to mmio.c
  drm/i915/gvt: introduce intel_vgpu_reset_cfg_space to reset configuration space
  ...

userns: Make ucounts lock irq-safe

The ucounts_lock is being used to protect various ucounts lifecycle
management functionalities. However, those services can also be invoked
when a pidns is being freed in an RCU callback (e.g. softirq context).
This can lead to deadlocks. There were already efforts trying to
prevent similar deadlocks in add7c65ca426 ("pid: fix lockdep deadlock
warning due to ucount_lock"), however they just moved the context
from hardirq to softrq. Fix this issue once and for all by explictly
making the lock disable irqs altogether.

Dmitry Vyukov <dvyukov@google.com> reported:

> I've got the following deadlock report while running syzkaller fuzzer
> on eec0d3d065bfcdf9cd5f56dd2a36b94d12d32297 of linux-next (on odroid
> device if it matters):
>
> =================================
> [ INFO: inconsistent lock state ]
> 4.10.0-rc3-next-20170112-xc2-dirty #6 Not tainted
> ---------------------------------
> inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
> swapper/2/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
>  (ucounts_lock){+.?...}, at: [<     inline     >] spin_lock
> ./include/linux/spinlock.h:302
>  (ucounts_lock){+.?...}, at: [<ffff2000081678c8>]
> put_ucounts+0x60/0x138 kernel/ucount.c:162
> {SOFTIRQ-ON-W} state was registered at:
> [<ffff2000081c82d8>] mark_lock+0x220/0xb60 kernel/locking/lockdep.c:3054
> [<     inline     >] mark_irqflags kernel/locking/lockdep.c:2941
> [<ffff2000081c97a8>] __lock_acquire+0x388/0x3260 kernel/locking/lockdep.c:3295
> [<ffff2000081cce24>] lock_acquire+0xa4/0x138 kernel/locking/lockdep.c:3753
> [<     inline     >] __raw_spin_lock ./include/linux/spinlock_api_smp.h:144
> [<ffff200009798128>] _raw_spin_lock+0x90/0xd0 kernel/locking/spinlock.c:151
> [<     inline     >] spin_lock ./include/linux/spinlock.h:302
> [<     inline     >] get_ucounts kernel/ucount.c:131
> [<ffff200008167c28>] inc_ucount+0x80/0x6c8 kernel/ucount.c:189
> [<     inline     >] inc_mnt_namespaces fs/namespace.c:2818
> [<ffff200008481850>] alloc_mnt_ns+0x78/0x3a8 fs/namespace.c:2849
> [<ffff200008487298>] create_mnt_ns+0x28/0x200 fs/namespace.c:2959
> [<     inline     >] init_mount_tree fs/namespace.c:3199
> [<ffff200009bd6674>] mnt_init+0x258/0x384 fs/namespace.c:3251
> [<ffff200009bd60bc>] vfs_caches_init+0x6c/0x80 fs/dcache.c:3626
> [<ffff200009bb1114>] start_kernel+0x414/0x460 init/main.c:648
> [<ffff200009bb01e8>] __primary_switched+0x6c/0x70 arch/arm64/kernel/head.S:456
> irq event stamp: 2316924
> hardirqs last  enabled at (2316924): [<     inline     >] rcu_do_batch
> kernel/rcu/tree.c:2911
> hardirqs last  enabled at (2316924): [<     inline     >]
> invoke_rcu_callbacks kernel/rcu/tree.c:3182
> hardirqs last  enabled at (2316924): [<     inline     >]
> __rcu_process_callbacks kernel/rcu/tree.c:3149
> hardirqs last  enabled at (2316924): [<ffff200008210414>]
> rcu_process_callbacks+0x7a4/0xc28 kernel/rcu/tree.c:3166
> hardirqs last disabled at (2316923): [<     inline     >] rcu_do_batch
> kernel/rcu/tree.c:2900
> hardirqs last disabled at (2316923): [<     inline     >]
> invoke_rcu_callbacks kernel/rcu/tree.c:3182
> hardirqs last disabled at (2316923): [<     inline     >]
> __rcu_process_callbacks kernel/rcu/tree.c:3149
> hardirqs last disabled at (2316923): [<ffff20000820fe80>]
> rcu_process_callbacks+0x210/0xc28 kernel/rcu/tree.c:3166
> softirqs last  enabled at (2316912): [<ffff20000811b4c4>]
> _local_bh_enable+0x4c/0x80 kernel/softirq.c:155
> softirqs last disabled at (2316913): [<     inline     >]
> do_softirq_own_stack ./include/linux/interrupt.h:488
> softirqs last disabled at (2316913): [<     inline     >]
> invoke_softirq kernel/softirq.c:371
> softirqs last disabled at (2316913): [<ffff20000811c994>]
> irq_exit+0x264/0x308 kernel/softirq.c:405
>
> other info that might help us debug this:
>  Possible unsafe locking scenario:
>
>        CPU0
>        ----
>   lock(ucounts_lock);
>   <Interrupt>
>     lock(ucounts_lock);
>
>  *** DEADLOCK ***
>
> 1 lock held by swapper/2/0:
>  #0:  (rcu_callback){......}, at: [<     inline     >] __rcu_reclaim
> kernel/rcu/rcu.h:108
>  #0:  (rcu_callback){......}, at: [<     inline     >] rcu_do_batch
> kernel/rcu/tree.c:2919
>  #0:  (rcu_callback){......}, at: [<     inline     >]
> invoke_rcu_callbacks kernel/rcu/tree.c:3182
>  #0:  (rcu_callback){......}, at: [<     inline     >]
> __rcu_process_callbacks kernel/rcu/tree.c:3149
>  #0:  (rcu_callback){......}, at: [<ffff200008210390>]
> rcu_process_callbacks+0x720/0xc28 kernel/rcu/tree.c:3166
>
> stack backtrace:
> CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.10.0-rc3-next-20170112-xc2-dirty #6
> Hardware name: Hardkernel ODROID-C2 (DT)
> Call trace:
> [<ffff20000808fa60>] dump_backtrace+0x0/0x440 arch/arm64/kernel/traps.c:500
> [<ffff20000808fec0>] show_stack+0x20/0x30 arch/arm64/kernel/traps.c:225
> [<ffff2000088a99e0>] dump_stack+0x110/0x168
> [<ffff2000082fa2b4>] print_usage_bug.part.27+0x49c/0x4bc
> kernel/locking/lockdep.c:2387
> [<     inline     >] print_usage_bug kernel/locking/lockdep.c:2357
> [<     inline     >] valid_state kernel/locking/lockdep.c:2400
> [<     inline     >] mark_lock_irq kernel/locking/lockdep.c:2617
> [<ffff2000081c89ec>] mark_lock+0x934/0xb60 kernel/locking/lockdep.c:3065
> [<     inline     >] mark_irqflags kernel/locking/lockdep.c:2923
> [<ffff2000081c9a60>] __lock_acquire+0x640/0x3260 kernel/locking/lockdep.c:3295
> [<ffff2000081cce24>] lock_acquire+0xa4/0x138 kernel/locking/lockdep.c:3753
> [<     inline     >] __raw_spin_lock ./include/linux/spinlock_api_smp.h:144
> [<ffff200009798128>] _raw_spin_lock+0x90/0xd0 kernel/locking/spinlock.c:151
> [<     inline     >] spin_lock ./include/linux/spinlock.h:302
> [<ffff2000081678c8>] put_ucounts+0x60/0x138 kernel/ucount.c:162
> [<ffff200008168364>] dec_ucount+0xf4/0x158 kernel/ucount.c:214
> [<     inline     >] dec_pid_namespaces kernel/pid_namespace.c:89
> [<ffff200008293dc8>] delayed_free_pidns+0x40/0xe0 kernel/pid_namespace.c:156
> [<     inline     >] __rcu_reclaim kernel/rcu/rcu.h:118
> [<     inline     >] rcu_do_batch kernel/rcu/tree.c:2919
> [<     inline     >] invoke_rcu_callbacks kernel/rcu/tree.c:3182
> [<     inline     >] __rcu_process_callbacks kernel/rcu/tree.c:3149
> [<ffff2000082103d8>] rcu_process_callbacks+0x768/0xc28 kernel/rcu/tree.c:3166
> [<ffff2000080821dc>] __do_softirq+0x324/0x6e0 kernel/softirq.c:284
> [<     inline     >] do_softirq_own_stack ./include/linux/interrupt.h:488
> [<     inline     >] invoke_softirq kernel/softirq.c:371
> [<ffff20000811c994>] irq_exit+0x264/0x308 kernel/softirq.c:405
> [<ffff2000081ecc28>] __handle_domain_irq+0xc0/0x150 kernel/irq/irqdesc.c:636
> [<ffff200008081c80>] gic_handle_irq+0x68/0xd8
> Exception stack(0xffff8000648e7dd0 to 0xffff8000648e7f00)
> 7dc0:                                   ffff8000648d4b3c 0000000000000007
> 7de0: 0000000000000000 1ffff0000c91a967 1ffff0000c91a967 1ffff0000c91a967
> 7e00: ffff20000a4b6b68 0000000000000001 0000000000000007 0000000000000001
> 7e20: 1fffe4000149ae90 ffff200009d35000 0000000000000000 0000000000000002
> 7e40: 0000000000000000 0000000000000000 0000000002624a1a 0000000000000000
> 7e60: 0000000000000000 ffff200009cbcd88 000060006d2ed000 0000000000000140
> 7e80: ffff200009cff000 ffff200009cb6000 ffff200009cc2020 ffff200009d2159d
> 7ea0: 0000000000000000 ffff8000648d4380 0000000000000000 ffff8000648e7f00
> 7ec0: ffff20000820a478 ffff8000648e7f00 ffff20000820a47c 0000000010000145
> 7ee0: 0000000000000140 dfff200000000000 ffffffffffffffff ffff20000820a478
> [<ffff2000080837f8>] el1_irq+0xb8/0x130 arch/arm64/kernel/entry.S:486
> [<     inline     >] arch_local_irq_restore
> ./arch/arm64/include/asm/irqflags.h:81
> [<ffff20000820a47c>] rcu_idle_exit+0x64/0xa8 kernel/rcu/tree.c:1030
> [<     inline     >] cpuidle_idle_call kernel/sched/idle.c:200
> [<ffff2000081bcbfc>] do_idle+0x1dc/0x2d0 kernel/sched/idle.c:243
> [<ffff2000081bd1cc>] cpu_startup_entry+0x24/0x28 kernel/sched/idle.c:345
> [<ffff200008099f8c>] secondary_start_kernel+0x2cc/0x358
> arch/arm64/kernel/smp.c:276
> [<000000000279f1a4>] 0x279f1a4

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Fixes: add7c65ca426 ("pid: fix lockdep deadlock warning due to ucount_lock")
Fixes: f333c700c610 ("pidns: Add a limit on the number of pid namespaces")
Cc: stable@vger.kernel.org
Link: https://www.spinics.net/lists/kernel/msg2426637.html
Signed-off-by: Nikolay Borisov <n.borisov.lkml@gmail.com>
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>

mmc: dw_mmc: force setup bus if active slots exist

It's necessary to setup bus if any slots are present.
- update clock after ctrl reset
- if the host has genpd node, we can guarantee the clock is
  available before starting request. Otherwies, the clock register
  is reset once power off the pd, and host can't output the active
  clock during communication.

Fixes: e9ed8835e990 ("mmc: dw_mmc: add runtime PM callback")
Fixes: df9bcc2bc0a1 ("mmc: dw_mmc: add missing codes for runtime resume")
cc: <stable@vger.kernel.org>
Reported-by: Randy Li <randy.li@rock-chips.com>
Reported-by: S. Gilles <sgilles@math.umd.edu>
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

Merge tag 'drm-qemu-20170110' of git://git.kraxel.org/linux into drm-fixes

drm-qemu: virtio sparse fix, MAINTAINERS updates.

* tag 'drm-qemu-20170110' of git://git.kraxel.org/linux:
  drm: flip cirrus driver status to "obsolete".
  drm: update MAINTAINERS for qemu drivers (bochs, cirrus, qxl, virtio-gpu)
  drm/virtio: fix framebuffer sparse warning

Merge branch 'drm-etnaviv-fixes' of https://git.pengutronix.de/git/lst/linux into drm-fixes

a single fix for a FE hang after IOVA rollover on GC3000. This isn't
pretty, but is the minimal fix for the issue. A larger rework of the
code, that will also fix this issue properly, is currently in the works,
but that needs to wait for at least the next feature pull.

* 'drm-etnaviv-fixes' of https://git.pengutronix.de/git/lst/linux:
  drm/etnaviv: trick drm_mm into giving out a low IOVA

Merge branch 'exynos-drm-fixes' of git://git./linux/kernel/git/daeinki/drm-exynos into drm-fixes

Just regression fixups to resolve page fault issue of DECON device.

* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos/decon5433: set STANDALONE_UPDATE_F on output enablement
  drm/exynos/decon5433: fix CMU programming
  drm/exynos/decon5433: do not disable video after reset
  drm/exynos/decon5433: set STANDALONE_UPDATE_F also if planes are disabled
  drm/exynos/decon5433: update shadow registers iff there are active windows

Merge branch 'drm-fixes-4.10' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

A little bigger than usual since it's two weeks worth.  Highlights:
- Add support for new smc firmware on some new hainan variants
- add support for SI chips that require special mc firmware
- remove workarounds for issues fixed by new mc firmware
- fix a regression in cursor handling
- various VCE fixes
- fix for UVD clockgating

* 'drm-fixes-4.10' of git://people.freedesktop.org/~agd5f/linux:
  drm/amdgpu: add support for new hainan variants
  drm/radeon: add support for new hainan variants
  drm/amdgpu: change clock gating mode for uvd_v4.
  drm/amdgpu: fix program vce instance logic error.
  drm/amdgpu: fix bug set incorrect value to vce register
  Revert "drm/amdgpu: Only update the CUR_SIZE register when necessary"
  drm/amd/powerplay: refine vce dpm update code on Cz.
  drm/amdgpu: fix vm_fault_stop on gfx6
  drm/amd/powerplay: fix vce cg logic error on CZ/St.
  drm/radeon: drop the mclk quirk for hainan
  drm/radeon: drop oland quirks
  drm/amdgpu: drop the mclk quirk for hainan
  drm/amdgpu: drop oland quirks
  drm/amdgpu/si: load special ucode for certain MC configs
  drm/radeon/si: load special ucode for certain MC configs

Merge branch 'msm-fixes-4.10-rc4' of git://people.freedesktop.org/~robclark/linux into drm-fixes

* 'msm-fixes-4.10-rc4' of git://people.freedesktop.org/~robclark/linux:
  drm/msm: fix potential null ptr issue in non-iommu case
  drm/msm/mdp5: rip out plane->pending tracking

Merge tag 'drm-misc-fixes-2017-01-13' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes

A few more core fixes.

* tag 'drm-misc-fixes-2017-01-13' of git://anongit.freedesktop.org/git/drm-misc:
  drm/probe-helpers: Drop locking from poll_enable
  drm: Fix broken VT switch with video=1366x768 option
  drm: Schedule the output_poll_work with 1s delay if we have delayed event

Merge tag 'drm-intel-fixes-2017-01-19' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes

More GVT-g stuff than I'd like at this stage, but then again that's
pretty new and isolated so I'm not too worried.

* tag 'drm-intel-fixes-2017-01-19' of git://anongit.freedesktop.org/git/drm-intel: (26 commits)
  drm/i915: Ignore bogus plane coordinates on SKL when the plane is not visible
  drm/i915: Remove WaDisableLSQCROPERFforOCL KBL workaround.
  drm/i915/gvt: rewrite gt reset handler using new function intel_gvt_reset_vgpu_locked
  drm/i915/gvt: fix vGPU instance reuse issues by vGPU reset function
  drm/i915/gvt: introduce intel_vgpu_reset_mmio() to reset mmio space
  drm/i915/gvt: move mmio init/clean function to mmio.c
  drm/i915/gvt: introduce intel_vgpu_reset_cfg_space to reset configuration space
  drm/i915/gvt: move cfg space inititation function to cfg_space.c
  drm/i915/gvt: introuduce intel_vgpu_reset_gtt() to reset gtt
  drm/i915/gvt: introudce intel_vgpu_reset_resource() to reset vgpu resource state
  drm/i915: Fix phys pwrite for struct_mutex-less operation
  drm/i915: Clear ret before unbinding in i915_gem_evict_something()
  drm/i915/gvt: cleanup GFP flags
  drm/i915/gvt/kvmgt: return meaningful error for vgpu creating failure
  drm/i915/gvt: cleanup opregion memory allocation code
  drm/i915/gvt: destroy the allocated idr on vgpu creating failures
  drm/i915/gvt: init/destroy vgpu_idr properly
  drm/i915/gvt: dec vgpu->running_workload_num after the workload is really done
  drm/i915/gvt: fix use after free for workload
  drm/i915/gvt: remove duplicated definition
  ...

Linux 4.10-rc5

Merge branch 'x86-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull x86 fix from Thomas Gleixner:
 "Restore the retrigger callbacks in the IO APIC irq chips. That
  addresses a long standing regression which got introduced with the
  rewrite of the x86 irq subsystem two years ago and went unnoticed so
  far"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/ioapic: Restore IO-APIC irq_chip retrigger callback

Merge branch 'smp-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull smp/hotplug fix from Thomas Gleixner:
 "Remove an unused variable which is a leftover from the notifier
  removal"

* 'smp-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  cpu/hotplug: Remove unused but set variable in _cpu_down()

Merge tag 'for_linus' of git://git./linux/kernel/git/mst/vhost

Pull virtio/vhost fixes from Michael Tsirkin:
 "Random fixes and cleanups that accumulated over the time"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  virtio/s390: virtio: constify virtio_config_ops structures
  virtio/s390: add missing \n to end of dev_err message
  virtio/s390: support READ_STATUS command for virtio-ccw
  tools/virtio/ringtest: tweaks for s390
  tools/virtio/ringtest: fix run-on-all.sh for offline cpus
  virtio_console: fix a crash in config_work_handler
  vhost/scsi: silence uninitialized variable warning
  vhost: scsi: constify target_core_fabric_ops structures

Merge branch 'for-rc' of git://git./linux/kernel/git/rzhang/linux

Pull thermal management fixes from Zhang Rui:

 - fix a regression that thermal zone dynamically allocated sysfs
   attributes are freed before they're removed, which is introduced in
   4.10-rc1 (Jacob von Chorus)

 - fix a boot warning because deprecated hwmon API is used (Fabio
   Estevam)

 - a couple of fixes for rockchip thermal driver (Brian Norris, Caesar
   Wang)

* 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
  thermal: rockchip: fixes the conversion table
  thermal: core: move tz->device.groups cleanup to thermal_release
  thermal: thermal_hwmon: Convert to hwmon_device_register_with_info()
  thermal: rockchip: handle set_trips without the trip points
  thermal: rockchip: optimize the conversion table
  thermal: rockchip: fixes invalid temperature case
  thermal: rockchip: don't pass table structs by value
  thermal: rockchip: improve conversion error messages

platform/x86: ideapad-laptop: handle ACPI event 1

On Ideapad laptops, ACPI event 1 is currently not handled. Many models
log "ideapad_laptop: Unknown event: 1" every 20 seconds or so while
running on battery power. Some convertible laptops receive this event
when switching in and out of tablet mode.

This adds and additional case for event 1 in ideapad_acpi_notify to call
ideapad_input_report(priv, vpc_bit), so that the event is reported to
userspace and we avoid unnecessary logging.

Fixes bug #107481 (https://bugzilla.kernel.org/show_bug.cgi?id=107481)
Fixes bug #65751 (https://bugzilla.kernel.org/show_bug.cgi?id=65751)

Signed-off-by: Zach Ploskey <zach@ploskey.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Merge tag 'usb-4.10-rc5' of git://git./linux/kernel/git/gregkh/usb

Pull USB fixes from Greg KH:
 "Here are a few small USB fixes for 4.10-rc5.

  Most of these are gadget/dwc2 fixes for reported issues, all of these
  have been in linux-next for a while. The last one is a single xhci
  WARN_ON removal to handle an issue that the dwc3 driver is hitting in
  the 4.10-rc tree. The warning is harmless and needs to be removed, and
  a "real" fix that is more complex will show up in 4.11-rc1 for this
  device.

  That last patch hasn't been in linux-next yet due to the weekend
  timing, but it's a "simple" WARN_ON() removal so what could go wrong?
  :)"

Famous last words.

* tag 'usb-4.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
  xhci: remove WARN_ON if dma mask is not set for platform devices
  usb: dwc2: host: fix Wmaybe-uninitialized warning
  usb: dwc2: gadget: Fix GUSBCFG.USBTRDTIM value
  usb: gadget: udc: atmel: remove memory leak
  usb: dwc3: exynos fix axius clock error path to do cleanup
  usb: dwc2: Avoid suspending if we're in gadget mode
  usb: dwc2: use u32 for DT binding parameters
  usb: gadget: f_fs: Fix iterations on endpoints.
  usb: dwc2: gadget: Fix DMA memory freeing
  usb: gadget: composite: Fix function used to free memory

Merge branch 'libnvdimm-fixes' of git://git./linux/kernel/git/nvdimm/nvdimm

Pull libnvdimm fixes from Dan Williams:
 "Two fixes:

   - a regression fix for the multiple-pmem-namespace-per-region support
     added in 4.9. Even if an existing environment is not using that
     feature the act of creating and a destroying a single namespace
     with the ndctl utility will lead to the proliferation of extra
     unwanted namespace devices.

   - a fix for the error code returned from the pmem driver when the
     memcpy_mcsafe() routine returns -EFAULT. Btrfs seems to be the only
     block I/O consumer that tries to parse the meaning of the error
     code when it is non-zero.

  Neither of these fixes are critical, the namespace leak is awkward in
  that it can cause device naming to change and complicates debugging
  namespace initialization issues. The error code fix is included out of
  caution for what other consumers might be expecting -EIO for block I/O
  errors"

* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  libnvdimm, namespace: fix pmem namespace leak, delete when size set to zero
  pmem: return EIO on read_pmem() failure

Merge tag 'clk-fixes-for-linus' of git://git./linux/kernel/git/clk/linux

Pull clk fix from Stephen Boyd:
 "One fix for Samsung Exynos524x SoCs where recent IOMMU patches have
  caused some of these clocks to turn off when they were always left on
  before"

* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
  clk/samsung: exynos542x: mark some clocks as critical

Merge tag 'arc-4.10-rc5' of git://git./linux/kernel/git/vgupta/arc

Pull ARC fixes from Vineet Gupta:

 - more intc updates [Yuriv]

 - fix module build when unwinder is turned off

 - IO Coherency Programming model updates

 - other miscellaneous

* tag 'arc-4.10-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  ARC: Revert "ARC: mm: IOC: Don't enable IOC by default"
  ARC: mm: split arc_cache_init to allow __init reaping of bulk
  ARCv2: IOC: Use actual memory size to setup aperture size
  ARCv2: IOC: Adhere to progamming model guidelines to avoid DMA corruption
  ARCv2: IOC: refactor the IOC and SLC operations into own functions
  ARC: module: Fix !CONFIG_ARC_DW2_UNWIND builds
  ARCv2: save r30 on kernel entry as gcc uses it for code-gen
  ARCv2: IRQ: Call entry/exit functions for chained handlers in MCIP
  ARC: IRQ: Use hwirq instead of virq in mask/unmask
  ARC: mmu: clarify the MMUv3 programming model

Merge tag 'powerpc-4.10-2' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:
 "Two fixes for fallout from the hugetlb changes we merged this cycle.

  Ten other fixes, four only affect Power9, and the rest are a bit of a
  mixture though nothing terrible.

  Thanks to: Aneesh Kumar K.V, Anton Blanchard, Benjamin Herrenschmidt,
  Dave Martin, Gavin Shan, Madhavan Srinivasan, Nicholas Piggin, Reza
  Arbab"

* tag 'powerpc-4.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc: Ignore reserved field in DCSR and PVR reads and writes
  powerpc/ptrace: Preserve previous TM fprs/vsrs on short regset write
  powerpc/ptrace: Preserve previous fprs/vsrs on short regset write
  powerpc/perf: Use MSR to report privilege level on P9 DD1
  selftest/powerpc: Wrong PMC initialized in pmc56_overflow test
  powerpc/eeh: Enable IO path on permanent error
  powerpc/perf: Fix PM_BRU_CMPL event code for power9
  powerpc/mm: Fix little-endian 4K hugetlb
  powerpc/mm/hugetlb: Don't panic when we don't find the default huge page size
  powerpc: Fix pgtable pmd cache init
  powerpc/icp-opal: Fix missing KVM case and harden replay
  powerpc/mm: Fix memory hotplug BUG() on radix

platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT

The commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
starts refusing misconfigured interrupt handlers. This makes
intel_mid_powerbtn not working anymore.

Add a mandatory flag to a threaded IRQ request in the driver.

Fixes: 1c6c69525b40 ("genirq: Reject bogus threaded irq requests")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

platform/x86: surface3-wmi: fix uninitialized symbol

The patch 3dda3b3798f9: "platform/x86: Add custom surface3 platform
device for controlling LID" from Nov 25, 2016, leads to the following
static checker warning:

        drivers/platform/x86/surface3-wmi.c:168 s3_wmi_check_platform_device()
        error: uninitialized symbol 'ts_adev'.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

platform/x86: surface3-wmi: Shut up unused-function warning

The newly added driver guards its "resume" callback with an
warning in some configurations:

drivers/platform/x86/surface3-wmi.c:248:12: error: 's3_wmi_resume' defined but not used [-Werror=unused-function]

Using a __maybe_unused annotation without an #ifdef avoids the mistake more
reliably.

Fixes: 3dda3b3798f9 ("platform/x86: Add custom surface3 platform device for controlling LID")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>

platform/x86: mlx-platform: free first dev on error

There is an off-by-one error so we don't unregister priv->pdev_mux[0].
Also it's slightly simpler as a while loop instead of a for loop.

Fixes: 58cbbee2391c ("x86/platform/mellanox: Introduce support for Mellanox systems platform")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Vadim Pasternak <vadimp@mellanox.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>