commit 51a2a68fde2035887c0d74aee1c9569c691dfd61
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Tue Dec 5 11:26:38 2017 +0100

    Linux 4.14.4

commit e49d722f26b904015077655bff47cdbde049226a
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Mon Dec 4 12:59:57 2017 +0100

    Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()"
    
    This reverts commit f9a64e23a9da528e7d8aa1bd2c7bb92be4ebb724 which is
    commit 0d794d0d018f23fb09c50f6ae26868bd6ae343d6 upstream.
    
    Andy writes:
    
            I think the thing to do is to revert the patch from -stable.
            The bug it fixes is very minor, and the regression is that it
            made a pre-existing bug in some nearly-undebuggable core resume
            code much easier to hit.  I don't feel comfortable with a
            backport of the latter fix until it has a good long soak in
            Linus' tree.
    
    Reported-by: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bpetkov@suse.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88e1bb2a24125747d48b5e2d60bccdb247b86eb9
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Nov 23 21:41:57 2017 +0200

    drm/i915: Prevent zero length "index" write
    
    commit 56350fb8978bbf4aafe08f21234e161dd128b417 upstream.
    
    The hardware always writes one or two bytes in the index portion of
    an indexed transfer. Make sure the message we send as the index
    doesn't have a zero length.
    
    Cc: Daniel Kurtz <djkurtz@chromium.org>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Sean Paul <seanpaul@chromium.org>
    Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.syrjala@linux.intel.com
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    (cherry picked from commit bb9e0d4bca50f429152e74a459160b41f3d60fb2)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e522b9247ce931a7319f1d7e9d0bdfa5817b9a4e
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Thu Nov 23 21:41:56 2017 +0200

    drm/i915: Don't try indexed reads to alternate slave addresses
    
    commit ae5c631e605a452a5a0e73205a92810c01ed954b upstream.
    
    We can only specify the one slave address to indexed reads/writes.
    Make sure the messages we check are destined to the same slave
    address before deciding to do an indexed transfer.
    
    Cc: Daniel Kurtz <djkurtz@chromium.org>
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Cc: Sean Paul <seanpaul@chromium.org>
    Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.syrjala@linux.intel.com
    Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
    (cherry picked from commit c4deb62d7821672265b87952bcd1c808f3bf3e8f)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c0d3d1d5908f5cd5c838c99663238cac201953b
Author: Xiong Zhang <xiong.y.zhang@intel.com>
Date:   Tue Nov 28 07:29:54 2017 +0800

    drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition
    
    commit b721b65af4eb46df6a1d9e34b14003225e403565 upstream.
    
    For ADDR_4K_MASK, bit[45..12] should be 1, all other bits
    should be 0. The current definition wrongly set bit[46] as 1
    also. This path fixes this.
    
    v2: Add commit message, fixes and cc stable.(Zhenyu)
    
    Fixes: 2707e4446688("drm/i915/gvt: vGPU graphics memory virtualization")
    Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
    Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7042c2b9a19e74972f5783ab3b7ef98ebdee293f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sat Nov 25 19:41:55 2017 +0000

    drm/i915/fbdev: Serialise early hotplug events with async fbdev config
    
    commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643 upstream.
    
    As both the hotplug event and fbdev configuration run asynchronously, it
    is possible for them to run concurrently. If configuration fails, we were
    freeing the fbdev causing a use-after-free in the hotplug event.
    
    <7>[ 3069.935211] [drm:intel_fb_initial_config [i915]] Not using firmware configuration
    <7>[ 3069.935225] [drm:drm_setup_crtcs] looking for cmdline mode on connector 77
    <7>[ 3069.935229] [drm:drm_setup_crtcs] looking for preferred mode on connector 77 0
    <7>[ 3069.935233] [drm:drm_setup_crtcs] found mode 3200x1800
    <7>[ 3069.935236] [drm:drm_setup_crtcs] picking CRTCs for 8192x8192 config
    <7>[ 3069.935253] [drm:drm_setup_crtcs] desired mode 3200x1800 set on crtc 43 (0,0)
    <7>[ 3069.935323] [drm:intelfb_create [i915]] no BIOS fb, allocating a new one
    <4>[ 3069.967737] general protection fault: 0000 [#1] PREEMPT SMP
    <0>[ 3069.977453] ---------------------------------
    <4>[ 3069.977457] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii prime_numbers mei i2c_hid pinctrl_geminilake pinctrl_intel [last unloaded: i915]
    <4>[ 3069.977492] CPU: 1 PID: 15414 Comm: kworker/1:0 Tainted: G     U          4.14.0-CI-CI_DRM_3388+ #1
    <4>[ 3069.977497] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
    <4>[ 3069.977508] Workqueue: events output_poll_execute
    <4>[ 3069.977512] task: ffff880177734e40 task.stack: ffffc90001fe4000
    <4>[ 3069.977519] RIP: 0010:__lock_acquire+0x109/0x1b60
    <4>[ 3069.977523] RSP: 0018:ffffc90001fe7bb0 EFLAGS: 00010002
    <4>[ 3069.977526] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000282 RCX: 0000000000000000
    <4>[ 3069.977530] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880170d4efd0
    <4>[ 3069.977534] RBP: ffffc90001fe7c70 R08: 0000000000000001 R09: 0000000000000000
    <4>[ 3069.977538] R10: 0000000000000000 R11: ffffffff81899609 R12: ffff880170d4efd0
    <4>[ 3069.977542] R13: ffff880177734e40 R14: 0000000000000001 R15: 0000000000000000
    <4>[ 3069.977547] FS:  0000000000000000(0000) GS:ffff88017fc80000(0000) knlGS:0000000000000000
    <4>[ 3069.977551] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    <4>[ 3069.977555] CR2: 00007f7e8b7bcf04 CR3: 0000000003e0f000 CR4: 00000000003406e0
    <4>[ 3069.977559] Call Trace:
    <4>[ 3069.977565]  ? mark_held_locks+0x64/0x90
    <4>[ 3069.977571]  ? _raw_spin_unlock_irq+0x24/0x50
    <4>[ 3069.977575]  ? _raw_spin_unlock_irq+0x24/0x50
    <4>[ 3069.977579]  ? trace_hardirqs_on_caller+0xde/0x1c0
    <4>[ 3069.977583]  ? _raw_spin_unlock_irq+0x2f/0x50
    <4>[ 3069.977588]  ? finish_task_switch+0xa5/0x210
    <4>[ 3069.977592]  ? lock_acquire+0xaf/0x200
    <4>[ 3069.977596]  lock_acquire+0xaf/0x200
    <4>[ 3069.977600]  ? __mutex_lock+0x5e9/0x9b0
    <4>[ 3069.977604]  _raw_spin_lock+0x2a/0x40
    <4>[ 3069.977608]  ? __mutex_lock+0x5e9/0x9b0
    <4>[ 3069.977612]  __mutex_lock+0x5e9/0x9b0
    <4>[ 3069.977616]  ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
    <4>[ 3069.977621]  ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
    <4>[ 3069.977625]  drm_fb_helper_hotplug_event.part.19+0x16/0xa0
    <4>[ 3069.977630]  output_poll_execute+0x8d/0x180
    <4>[ 3069.977635]  process_one_work+0x22e/0x660
    <4>[ 3069.977640]  worker_thread+0x48/0x3a0
    <4>[ 3069.977644]  ? _raw_spin_unlock_irqrestore+0x4c/0x60
    <4>[ 3069.977649]  kthread+0x102/0x140
    <4>[ 3069.977653]  ? process_one_work+0x660/0x660
    <4>[ 3069.977657]  ? kthread_create_on_node+0x40/0x40
    <4>[ 3069.977662]  ret_from_fork+0x27/0x40
    <4>[ 3069.977666] Code: 8d 62 f8 c3 49 81 3c 24 e0 fa 3c 82 41 be 00 00 00 00 45 0f 45 f0 83 fe 01 77 86 89 f0 49 8b 44 c4 08 48 85 c0 0f 84 76 ff ff ff <f0> ff 80 38 01 00 00 8b 1d 62 f9 e8 01 45 8b 85 b8 08 00 00 85
    <1>[ 3069.977707] RIP: __lock_acquire+0x109/0x1b60 RSP: ffffc90001fe7bb0
    <4>[ 3069.977712] ---[ end trace 4ad012eb3af62df7 ]---
    
    In order to keep the dev_priv->ifbdev alive after failure, we have to
    avoid the free and leave it empty until we unload the module (which is
    less than ideal, but a necessary evil for simplicity). Then we can use
    intel_fbdev_sync() to serialise the hotplug event with the configuration.
    The serialisation between the two was removed in commit 934458c2c95d
    ("Revert "drm/i915: Fix races on fbdev""), but the use after free is much
    older, commit 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization
    fails")
    
    Fixes: 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization fails")
    Fixes: 934458c2c95d ("Revert "drm/i915: Fix races on fbdev"")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Lukas Wunner <lukas@wunner.de>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
    Reviewed-by: Lukas Wunner <lukas@wunner.de>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@chris-wilson.co.uk
    (cherry picked from commit ad88d7fc6c032ddfb32b8d496a070ab71de3a64f)
    Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 569e3d1de49f0896733de8e709fc1fd28034d7dc
Author: Hans de Goede <j.w.r.degoede@gmail.com>
Date:   Tue Nov 14 14:55:17 2017 +0100

    drm/i915: Re-register PMIC bus access notifier on runtime resume
    
    commit 294cf1af8cf2eb0d1eced377fdfb9a2d3f0e8b42 upstream.
    
    intel_uncore_suspend() unregisters the uncore code's PMIC bus access
    notifier and gets called on both normal and runtime suspend.
    
    intel_uncore_resume_early() re-registers the notifier, but only on
    normal resume. Add a new intel_uncore_runtime_resume() function which
    only re-registers the notifier and call that on runtime resume.
    
    Reported-by: Imre Deak <imre.deak@intel.com>
    Reviewed-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
    (cherry picked from commit bedf4d79c3654921839b62246b0965ddb308b201)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6613dc721fc232698aafd0f6e214137cfda61e35
Author: Hans de Goede <j.w.r.degoede@gmail.com>
Date:   Fri Nov 10 16:03:01 2017 +0100

    drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2
    
    commit f4359cedfb43b934f38c50d1604db21333abe57b upstream.
    
    assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
    even though it gets unregistered on (runtime) suspend, this is caused
    by a race happening under the following circumstances:
    
    intel_runtime_pm_put does:
    
       atomic_dec(&dev_priv->pm.wakeref_count);
    
       pm_runtime_mark_last_busy(kdev);
       pm_runtime_put_autosuspend(kdev);
    
    And pm_runtime_put_autosuspend calls intel_runtime_suspend from
    a workqueue, so there is ample of time between the atomic_dec() and
    intel_runtime_suspend() unregistering the notifier. If the notifier
    gets called in this windowd assert_rpm_wakelock_held falsely triggers
    (at this point we're not runtime-suspended yet).
    
    This commit adds disable_rpm_wakeref_asserts and
    enable_rpm_wakeref_asserts calls around the
    intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
    i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.
    
    Changes in v2:
    -Reword comment explaining why disabling the wakeref asserts is
     ok and necessary
    
    Reported-by: FKr <bugs-freedesktop@ubermail.me>
    Reviewed-by: Imre Deak <imre.deak@intel.com>
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
    (cherry picked from commit ce30560c80dead91e98a03d90fb8791e57a9b69d)
    Signed-off-by: Jani Nikula <jani.nikula@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a67936842ba66eb229e6322856fefd2310e0b3fb
Author: NeilBrown <neilb@suse.com>
Date:   Tue Oct 17 14:24:09 2017 +1100

    md: forbid a RAID5 from having both a bitmap and a journal.
    
    commit 230b55fa8d64007339319539f8f8e68114d08529 upstream.
    
    Having both a bitmap and a journal is pointless.
    Attempting to do so can corrupt the bitmap if the journal
    replay happens before the bitmap is initialized.
    Rather than try to avoid this corruption, simply
    refuse to allow arrays with both a bitmap and a journal.
    So:
     - if raid5_run sees both are present, fail.
     - if adding a bitmap finds a journal is present, fail
     - if adding a journal finds a bitmap is present, fail.
    
    Signed-off-by: NeilBrown <neilb@suse.com>
    Tested-by: Joshua Kinard <kumba@gentoo.org>
    Acked-by: Joshua Kinard <kumba@gentoo.org>
    Signed-off-by: Shaohua Li <shli@fb.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 635526b896ca34fff5487d3ac00d04afbee7e1e4
Author: Sasha Neftin <sasha.neftin@intel.com>
Date:   Mon Nov 6 08:31:59 2017 +0200

    e1000e: fix the use of magic numbers for buffer overrun issue
    
    commit c0f4b163a03e73055dd734eaca64b9580e72e7fb upstream.
    
    This is a follow on to commit b10effb92e27 ("fix buffer overrun while the
     I219 is processing DMA transactions") to address David Laights concerns
    about the use of "magic" numbers.  So define masks as well as add
    additional code comments to give a better understanding of what needs to
    be done to avoid a buffer overrun.
    
    Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
    Reviewed-by: Alexander H Duyck <alexander.h.duyck@intel.com>
    Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
    Reviewed-by: Raanan Avargil <raanan.avargil@intel.com>
    Tested-by: Aaron Brown <aaron.f.brown@intel.com>
    Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c48f3c04984557e34cf2b7194eb4d7947edccc5e
Author: Don Hiatt <don.hiatt@intel.com>
Date:   Mon Oct 2 11:04:55 2017 -0700

    IB/hfi1: Do not warn on lid conversions for OPA
    
    commit 4988be5813ff2afdc0d8bfa315ef34a577d3efbf upstream.
    
    On OPA devices opa_local_smp_check will receive 32Bit LIDs when the LID
    is Extended. In such cases, it is okay to lose the upper 16 bits of the
    LID as this information is obtained elsewhere. Do not issue a warning
    when calling ib_lid_cpu16() in this case by masking out the upper 16Bits.
    
    [75920.148985] ------------[ cut here ]------------
    [75920.154651] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3788 hfi1_process_mad+0x1c1f/0x1c80 [hfi1]
    [75920.166192] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core]
    [75920.246331] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G        W I E   4.13.0-rc7+ #1
    [75920.255907] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
    [75920.268158] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
    [75920.274934] task: ffff88084a718000 task.stack: ffffc9000a424000
    [75920.282123] RIP: 0010:hfi1_process_mad+0x1c1f/0x1c80 [hfi1]
    [75920.288881] RSP: 0018:ffffc9000a427c38 EFLAGS: 00010206
    [75920.295265] RAX: 0000000000010001 RBX: ffff8808361420e8 RCX: ffff880837811d80
    [75920.303784] RDX: 0000000000000002 RSI: 0000000000007fff RDI: ffff880837811d80
    [75920.312302] RBP: ffffc9000a427d38 R08: 0000000000000000 R09: ffff8808361420e8
    [75920.320819] R10: ffff88083841f0e8 R11: ffffc9000a427da8 R12: 0000000000000001
    [75920.329335] R13: ffff880837810000 R14: 0000000000000000 R15: ffff88084f1a4800
    [75920.337849] FS:  0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000
    [75920.347450] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [75920.354405] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0
    [75920.362947] Call Trace:
    [75920.366257]  ? ib_mad_recv_done+0x258/0x9b0 [ib_core]
    [75920.372457]  ? ib_mad_recv_done+0x258/0x9b0 [ib_core]
    [75920.378652]  ? __kmalloc+0x1df/0x210
    [75920.383229]  ib_mad_recv_done+0x305/0x9b0 [ib_core]
    [75920.389270]  __ib_process_cq+0x5d/0xb0 [ib_core]
    [75920.395032]  ib_cq_poll_work+0x20/0x60 [ib_core]
    [75920.400777]  process_one_work+0x149/0x360
    [75920.405836]  worker_thread+0x4d/0x3c0
    [75920.410505]  kthread+0x109/0x140
    [75920.414681]  ? rescuer_thread+0x380/0x380
    [75920.419731]  ? kthread_park+0x60/0x60
    [75920.424406]  ret_from_fork+0x25/0x30
    [75920.428972] Code: 4c 89 9d 58 ff ff ff 49 89 45 00 66 b8 00 02 49 89 45 08 e8 44 27 89 e0 4c 8b 9d 58 ff ff ff e9 d8 f6 ff ff 0f ff e9 55 e7 ff ff <0f> ff e9 3b e5 ff ff 0f ff 0f 1f 84 00 00 00 00 00 e9 4b e9 ff
    [75921.451269] ---[ end trace cf26df27c9597265 ]---
    
    Fixes: 62ede7779904 ("Add OPA extended LID support")
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Don Hiatt <don.hiatt@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2b24fdca153f0fd6c2d0f1f60c7606a53b6db575
Author: Don Hiatt <don.hiatt@intel.com>
Date:   Mon Oct 2 11:04:48 2017 -0700

    IB/core: Do not warn on lid conversions for OPA
    
    commit 6588e412fe872ed81f3fb8d9b4561a66ecb763d0 upstream.
    
    On OPA devices the user_mad recv_handler can receive 32Bit LIDs
    (e.g. OPA_PERMISSIVE_LID) and it is okay to lose the upper 16 bits
    of the LID as this information is obtained elsewhere. Do not issue
    a warning when calling ib_lid_be16() in this case by masking out
    the upper 16Bits.
    
    [75667.310846] ------------[ cut here ]------------
    [75667.316447] WARNING: CPU: 0 PID: 1718 at ./include/rdma/ib_verbs.h:3799 recv_handler+0x15a/0x170 [ib_umad]
    [75667.327640] Modules linked in: ib_ipoib hfi1(E) rdmavt(E) rdma_ucm(E) ib_ucm(E) rdma_cm(E) ib_cm(E) iw_cm(E) ib_umad(E) ib_uverbs(E) ib_core(E) libiscsi scsi_transport_iscsi dm_mirror dm_region_hash dm_log dm_mod dax x86_pkg_temp_thermal intel_powerclamp coretemp kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel mei_me ipmi_si iTCO_wdt iTCO_vendor_support crypto_simd ipmi_devintf pcspkr mei sg i2c_i801 glue_helper lpc_ich shpchp ioatdma mfd_core wmi ipmi_msghandler cryptd acpi_power_meter acpi_pad nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb ptp ahci libahci pps_core crc32c_intel libata dca i2c_algo_bit i2c_core [last unloaded: ib_core]
    [75667.407704] CPU: 0 PID: 1718 Comm: kworker/0:1H Tainted: G        W I E   4.13.0-rc7+ #1
    [75667.417310] Hardware name: Intel Corporation S2600WT2/S2600WT2, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015
    [75667.429555] Workqueue: ib-comp-wq ib_cq_poll_work [ib_core]
    [75667.436360] task: ffff88084a718000 task.stack: ffffc9000a424000
    [75667.443549] RIP: 0010:recv_handler+0x15a/0x170 [ib_umad]
    [75667.450090] RSP: 0018:ffffc9000a427ce8 EFLAGS: 00010286
    [75667.456508] RAX: 00000000ffffffff RBX: ffff88085159ce80 RCX: 0000000000000000
    [75667.465094] RDX: ffff88085a47b068 RSI: 0000000000000000 RDI: ffff88085159cf00
    [75667.473668] RBP: ffffc9000a427d38 R08: 000000000001efc0 R09: ffff88085159ce80
    [75667.482228] R10: ffff88085f007480 R11: ffff88084acf20e8 R12: ffff88085a47b020
    [75667.490824] R13: ffff881056842e10 R14: ffff881056840200 R15: ffff88104c8d0800
    [75667.499390] FS:  0000000000000000(0000) GS:ffff88085f400000(0000) knlGS:0000000000000000
    [75667.509028] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [75667.516080] CR2: 00007f9e4b3d9000 CR3: 0000000001c09000 CR4: 00000000001406f0
    [75667.524664] Call Trace:
    [75667.528044]  ? find_mad_agent+0x7c/0x1b0 [ib_core]
    [75667.534031]  ? ib_mark_mad_done+0x73/0xa0 [ib_core]
    [75667.540142]  ib_mad_recv_done+0x423/0x9b0 [ib_core]
    [75667.546215]  __ib_process_cq+0x5d/0xb0 [ib_core]
    [75667.552007]  ib_cq_poll_work+0x20/0x60 [ib_core]
    [75667.557766]  process_one_work+0x149/0x360
    [75667.562844]  worker_thread+0x4d/0x3c0
    [75667.567529]  kthread+0x109/0x140
    [75667.571713]  ? rescuer_thread+0x380/0x380
    [75667.576775]  ? kthread_park+0x60/0x60
    [75667.581447]  ret_from_fork+0x25/0x30
    [75667.586014] Code: 43 4a 0f b6 45 c6 88 43 4b 48 8b 45 b0 48 89 43 4c 48 8b 45 b8 48 89 43 54 8b 45 c0 0f c8 89 43 5c e9 79 ff ff ff e8 16 4e fa e0 <0f> ff e9 42 ff ff ff 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00
    [75667.608323] ---[ end trace cf26df27c9597264 ]---
    
    Fixes: 62ede7779904 ("Add OPA extended LID support")
    Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
    Signed-off-by: Don Hiatt <don.hiatt@intel.com>
    Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
    Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
    Signed-off-by: Doug Ledford <dledford@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 75e63076249aedd3a7a3c38677d135cc146f1f4b
Author: Sandipan Das <sandipan@linux.vnet.ibm.com>
Date:   Fri Nov 17 15:27:28 2017 -0800

    include/linux/compiler-clang.h: handle randomizable anonymous structs
    
    commit 4ca59b14e588f873795a11cdc77a25c686a29d23 upstream.
    
    The GCC randomize layout plugin can randomize the member offsets of
    sensitive kernel data structures.  To use this feature, certain
    annotations and members are added to the structures which affect the
    member offsets even if this plugin is not used.
    
    All of these structures are completely randomized, except for task_struct
    which leaves out some of its members.  All the other members are wrapped
    within an anonymous struct with the __randomize_layout attribute.  This is
    done using the randomized_struct_fields_start and
    randomized_struct_fields_end defines.
    
    When the plugin is disabled, the behaviour of this attribute can vary
    based on the GCC version.  For GCC 5.1+, this attribute maps to
    __designated_init otherwise it is just an empty define but the anonymous
    structure is still present.  For other compilers, both
    randomized_struct_fields_start and randomized_struct_fields_end default
    to empty defines meaning the anonymous structure is not introduced at
    all.
    
    So, if a module compiled with Clang, such as a BPF program, needs to
    access task_struct fields such as pid and comm, the offsets of these
    members as recognized by Clang are different from those recognized by
    modules compiled with GCC.  If GCC 4.6+ is used to build the kernel,
    this can be solved by introducing appropriate defines for Clang so that
    the anonymous structure is seen when determining the offsets for the
    members.
    
    Link: http://lkml.kernel.org/r/20171109064645.25581-1-sandipan@linux.vnet.ibm.com
    Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Cc: Kate Stewart <kstewart@linuxfoundation.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Cc: Alexei Starovoitov <ast@fb.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 248b0ec5ad2501a35f2603384f1c7c7cee79eb02
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Nov 22 15:55:21 2017 +0100

    drm/amdgpu: Set adev->vcn.irq.num_types for VCN
    
    commit 89ce6e0afee8eafa679093207dabd717af9d09c5 upstream.
    
    We were setting adev->uvd.irq.num_types instead.
    
    Fixes: 9b257116e784 ("drm/amdgpu: add vcn enc irq support")
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 802328da073a0ba36a1cde899c48a5f07732d4aa
Author: Leo Liu <leo.liu@amd.com>
Date:   Tue Nov 21 09:08:07 2017 -0500

    drm/amdgpu: move UVD/VCE and VCN structure out from union
    
    commit b43aaee69d4327d05e7624d9471c17d015b4d67d upstream.
    
    With the enablement of VCN Dec and Enc from user space, User space queries
    kernel for the IP information, if HW has UVD/VCE, the info comes from these
    IP blocks, but this could end up mis-interpret for VCN when they are in the
    union, the other way same when HW with VCN block.
    
    Signed-off-by: Leo Liu <leo.liu@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Fixes: 95d0906f8506 ("drm/amdgpu: add initial vcn support and decode tests")
    Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d8f74d70634aa0dfe063d0e445f683b0545fa5b8
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Nov 8 17:25:04 2017 +0200

    drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks
    
    commit 9271c0ca573e02a360b636ecd8cb408852f4e9f6 upstream.
    
    Apparently some sinks look at the YQ bits even when receiving RGB,
    and they get somehow confused when they see a non-zero YQ value.
    So we can't just blindly follow CEA-861-F and set YQ to match the
    RGB range.
    
    Unfortunately there is no good way to tell whether the sink
    designer claims to have read CEA-861-F. The CEA extension block
    revision number has generally been stuck at 3 since forever,
    and even a very recently manufactured sink might be based on
    an old design so the manufacturing date doesn't seem like
    something we can use. In lieu of better information let's
    follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is
    based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0.
    
    The alternative would of course be to always set YQ=0. And if
    we ever encounter a HDMI 2.0+ sink with this bug that's what
    we'll probably have to do.
    
    Cc: Jani Nikula <jani.nikula@intel.com>
    Cc: Eric Anholt <eric@anholt.net>
    Cc: Neil Kownacki <njkkow@gmail.com>
    Reported-by: Neil Kownacki <njkkow@gmail.com>
    Tested-by: Neil Kownacki <njkkow@gmail.com>
    Fixes: fcc8a22cc905 ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F")
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171108152504.12596-1-ville.syrjala@linux.intel.com
    Acked-by: Eric Anholt <eric@anholt.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e685410c5f30a19c54d652e033942ed270d31b61
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date:   Fri Nov 10 17:38:34 2017 +0100

    drm/fsl-dcu: Don't set connector DPMS property
    
    commit daee54263c1202cbdab85c5e15ae30b417602efb upstream.
    
    Since commit 4a97a3da420b ("drm: Don't update property values for atomic
    drivers") atomic drivers must not update property values as properties
    are read from the state instead. To catch remaining users, the
    drm_object_property_set_value() function now throws a warning when
    called by atomic drivers on non-immutable properties, and we hit that
    warning when creating connectors.
    
    The easy fix is to just remove the drm_object_property_set_value() as it
    is used here to set the initial value of the connector's DPMS property
    to OFF. The DPMS property applies on top of the connector's state crtc
    pointer (initialized to NULL) that is the main connector on/off control,
    and should thus default to ON.
    
    Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
    Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
    Signed-off-by: Stefan Agner <stefan@agner.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit dde499d3cf6edea946ff59cb5d72e4f9ef21f3fd
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Tue Nov 28 12:16:03 2017 +0100

    drm/fb_helper: Disable all crtc's when initial setup fails.
    
    commit 52dd06506e9bbc2a37b352df7dfc5468f8da21fd upstream.
    
    Some drivers like i915 start with crtc's enabled, but with deferred
    fbcon setup they were no longer disabled as part of fbdev setup.
    Headless units could no longer enter pc3 state because the crtc was
    still enabled.
    
    Fix this by calling restore_fbdev_mode when we would have called
    it otherwise once during initial fbdev setup.
    
    Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Fixes: ca91a2758fce ("drm/fb-helper: Support deferred setup")
    Reported-by: Thomas Voegtle <tv@lio96.de>
    Tested-by: Thomas Voegtle <tv@lio96.de>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171128111603.62757-1-maarten.lankhorst@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e4c84b504e02f6f7103cdc67b1adbe304910c104
Author: Rex Zhu <Rex.Zhu@amd.com>
Date:   Fri Nov 17 16:41:16 2017 +0800

    drm/amd/pp: fix typecast error in powerplay.
    
    commit 8d8258bdab735d9f3c4b78e091ecfbb2b2b1f2ca upstream.
    
    resulted in unexpected data truncation
    
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 78f4bb6e965ddd9f60f607dfaf6e20109da84f6d
Author: Christian König <christian.koenig@amd.com>
Date:   Mon Oct 30 14:57:43 2017 +0100

    drm/ttm: once more fix ttm_buffer_object_transfer
    
    commit 4d98e5ee6084f6d7bc578c5d5f86de7156aaa4cb upstream.
    
    When the mutex is locked just in the moment we copy it we end up with a
    warning that we release a locked mutex.
    
    Fix this by properly reinitializing the mutex.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5e69000aa80880491ca4a613679bd21c60b048b
Author: Peter Griffin <peter.griffin@linaro.org>
Date:   Tue Aug 15 15:14:25 2017 +0100

    drm/hisilicon: Ensure LDI regs are properly configured.
    
    commit a2f042430784d86eb2b7a6d2a869f552da30edba upstream.
    
    This patch fixes the following soft lockup:
      BUG: soft lockup - CPU#0 stuck for 23s! [weston:307]
    
    On weston idle-timeout the IP is powered down and reset
    asserted. On weston resume we get a massive vblank
    IRQ storm due to the LDI registers having lost some state.
    
    This state loss is caused by ade_crtc_atomic_begin() not
    calling ade_ldi_set_mode(). With this patch applied
    resuming from Weston idle-timeout works well.
    
    Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
    Tested-by: John Stultz <john.stultz@linaro.org>
    Reviewed-by: Xinliang Liu <xinliang.liu@linaro.org>
    Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 87139913c0e2d0a7270868a7a36d549dfd3fad5d
Author: Jonathan Liu <net147@gmail.com>
Date:   Mon Aug 7 21:55:45 2017 +1000

    drm/panel: simple: Add missing panel_simple_unprepare() calls
    
    commit f3621a8eb59a913612c8e6e37d81f16b649f8b6c upstream.
    
    During panel removal or system shutdown panel_simple_disable() is called
    which disables the panel backlight but the panel is still powered due to
    missing calls to panel_simple_unprepare().
    
    Fixes: d02fd93e2cd8 ("drm/panel: simple - Disable panel on shutdown")
    Signed-off-by: Jonathan Liu <net147@gmail.com>
    Signed-off-by: Thierry Reding <treding@nvidia.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20170807115545.27747-1-net147@gmail.com
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8153a0fc1212157a4bf8b303cbf51993ff87aa7c
Author: Roman Kapl <rka@sysgo.com>
Date:   Mon Oct 30 11:56:13 2017 +0100

    drm/radeon: fix atombios on big endian
    
    commit 4f626a4ac8f57ddabf06d03870adab91e463217f upstream.
    
    The function for byteswapping the data send to/from atombios was buggy for
    num_bytes not divisible by four. The function must be aware of the fact
    that after byte-swapping the u32 units, valid bytes might end up after the
    num_bytes boundary.
    
    This patch was tested on kernel 3.12 and allowed us to sucesfully use
    DisplayPort on and Radeon SI card. Namely it fixed the link training and
    EDID readout.
    
    The function is patched both in radeon and amd drivers, since the functions
    and the fixes are identical.
    
    Signed-off-by: Roman Kapl <rka@sysgo.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e3c5870862d95ff198a1902c3d7bd2a548b89ea7
Author: Jyri Sarha <jsarha@ti.com>
Date:   Thu Oct 12 12:19:46 2017 +0300

    drm/tilcdc: Precalculate total frametime in tilcdc_crtc_set_mode()
    
    commit ce99f7206c9105851d97202ed08c058af6f11ac4 upstream.
    
    We need the total frame refresh time to check if we are too close to
    vertical sync when updating the two framebuffer DMA registers and risk
    a collision. This new method is more accurate that the previous that
    based on mode's vrefresh value, which itself is inaccurate or may not
    even be initialized.
    
    Reported-by: Kevin Hao <kexin.hao@windriver.com>
    Fixes: 11abbc9f39e0 ("drm/tilcdc: Set framebuffer DMA address to HW only if CRTC is enabled")
    Signed-off-by: Jyri Sarha <jsarha@ti.com>
    Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a5851fdb17dda5f0854417f15a0c9c833a92dcc6
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Mon Oct 23 18:25:40 2017 +0300

    drm/vblank: Tune drm_crtc_accurate_vblank_count() WARN down to a debug
    
    commit a111fbc4c44d2981f1a8fef64418685be5e30280 upstream.
    
    Since commit 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
    even drivers that don't implement accurate vblank timestamps will end
    up using drm_crtc_accurate_vblank_count(). That leads to a WARN every
    time drm_crtc_arm_vblank_event() gets called. The could be as often
    as every frame for each active crtc.
    
    Considering drm_crtc_accurate_vblank_count() is never any worse than
    the drm_vblank_count() we used previously, let's just skip the WARN
    unless DRM_UT_VBL is enabled. That way people won't be bothered by
    this unless they're debugging vblank code. And let's also change it
    to WARN_ONCE() so that even when you're debugging vblank code you
    won't get drowned by constant WARNs.
    
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Cc: "Szyprowski, Marek" <m.szyprowski@samsung.com>
    Cc: Andrzej Hajda <a.hajda@samsung.com>
    Reported-by: Andrzej Hajda <a.hajda@samsung.com>
    Fixes: 632c6e4edef1 ("drm/vblank: Fix flip event vblank count")
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171023152540.15364-1-ville.syrjala@linux.intel.com
    Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
    Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7c33c32d39b9d11338624d4a7bad4e75bf64fbf8
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Tue Oct 10 16:33:22 2017 +0300

    drm/vblank: Fix flip event vblank count
    
    commit 632c6e4edef17c40bba3be67c980d959790d142f upstream.
    
    On machines where the vblank interrupt fires some time after the start
    of vblank (or we just manage to race with the vblank interrupt handler)
    we will currently stuff a stale vblank counter value into the flip event,
    and thus we'll prematurely complete the flip.
    
    Switch over to drm_crtc_accurate_vblank_count() to make sure we have an
    up to date counter value, crucially also remember to add the +1 so that
    the delayed vblank interrupt won't complete the flip prematurely.
    
    Cc: Daniel Vetter <daniel@ffwll.ch>
    Suggested-by: Daniel Vetter <daniel@ffwll.ch>
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20171010133322.24029-1-ville.syrjala@linux.intel.com
    Reviewed-by: Daniel Vetter <daniel@ffwll.ch> #irc
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6cd3e4a3e697cca84f27a0af68ba59a6ab00892f
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Fri Nov 3 16:00:35 2017 +0100

    drm/ttm: Always and only destroy bo->ttm_resv in ttm_bo_release_list
    
    commit e1fc12c5d9ad06a2a74e97a91f1b0c5f4c723b50 upstream.
    
    Fixes a use-after-free due to a race condition in
    ttm_bo_cleanup_refs_and_unlock, which allows one task to reserve a BO
    and destroy its ttm_resv while another task is waiting for it to signal
    in reservation_object_wait_timeout_rcu.
    
    v2:
    * Always initialize bo->ttm_resv in ttm_bo_init_reserved
     (Christian König)
    
    Fixes: 0d2bd2ae045d "drm/ttm: fix memory leak while individualizing BOs"
    Reviewed-by: Chunming Zhou <david1.zhou@amd.com> # v1
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 99b0ea0391d1b49ed4a944a07ad57ee448b0541c
Author: Christian König <christian.koenig@amd.com>
Date:   Fri Oct 13 17:24:31 2017 +0200

    drm/amdgpu: reserve root PD while releasing it
    
    commit 2642cf110d08a403f585a051e4cbf45a90b3adea upstream.
    
    Otherwise somebody could try to evict it at the same time and try to use
    half torn down structures.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 509536b227fb35ed34d144ff4280aa78605ab85e
Author: Christian König <christian.koenig@amd.com>
Date:   Mon Sep 4 21:02:45 2017 +0200

    dma-buf: make reservation_object_copy_fences rcu save
    
    commit 39e16ba16c147e662bf9fbcee9a99d70d420382f upstream.
    
    Stop requiring that the src reservation object is locked for this operation.
    
    Acked-by: Chunming Zhou <david1.zhou@amd.com>
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/1504551766-5093-1-git-send-email-deathsimple@vodafone.de
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 45d1765032b645a2e86a606f7d173d4bf97a9810
Author: Christian König <christian.koenig@amd.com>
Date:   Mon Sep 4 20:58:45 2017 +0200

    drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more
    
    commit 378e2d5b504fe0231c557751e58b80fcf717cc20 upstream.
    
    With shared reservation objects __ttm_bo_reserve() can easily fail even on
    destroyed BOs. This prevents correct handling when we need to individualize
    the reservation object.
    
    Fix this by individualizing the object before even trying to reserve it.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Acked-by: Chunming Zhou <david1.zhou@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Lyude Paul <lyude@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d48221f3399764748f706cc1126b5d6465e27d87
Author: Ken Wang <Ken.Wang@amd.com>
Date:   Wed Nov 8 14:48:50 2017 +0800

    drm/amdgpu: Remove check which is not valid for certain VBIOS
    
    commit ab6613b7eaefe85dadfc86025e901c55d71c0379 upstream.
    
    Fixes vbios fetching on certain headless boards.
    
    Signed-off-by: Ken Wang <Ken.Wang@amd.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ecd08e684cd1d138bf894e632e0d141f5e7c4140
Author: ozeng <oak.zeng@amd.com>
Date:   Tue Jun 6 10:53:28 2017 -0500

    drm/amdgpu: Properly allocate VM invalidate eng v2
    
    commit c5066129af4436ab0da8eefe4289774a5409706d upstream.
    
    v1: Properly allocate TLB invalidation engine to avoid conflict.
    v2: Added comments to codes
    
    Signed-off-by: Oak Zeng <Oak.Zeng@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Acked-by: Christian Konig <christian.koenig@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a00b7ea3df52da50097d22c9eb3b0eba3e504838
Author: Christian König <christian.koenig@amd.com>
Date:   Tue Oct 31 09:36:13 2017 +0100

    drm/amdgpu: fix error handling in amdgpu_bo_do_create
    
    commit a695e43712242c354748e9bae5d137d4337a7694 upstream.
    
    The bo structure is freed up in case of an error, so we can't do any
    accounting if that happens.
    
    Signed-off-by: Christian König <christian.koenig@amd.com>
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 402b1de75ce06404c96cf803e1fe0b5c685f7797
Author: Ken Wang <Ken.Wang@amd.com>
Date:   Fri Sep 29 15:41:43 2017 +0800

    drm/amdgpu: correct reference clock value on vega10
    
    commit 76d6172b6fab16455af4b67bb18a3f66011592f8 upstream.
    
    Old value from bringup was wrong.
    
    Signed-off-by: Ken Wang <Ken.Wang@amd.com>
    Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f182df2eacbe52100b82e193a7917fdbb4312dd1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Sep 30 11:14:13 2017 +0300

    drm/amdgpu: Potential uninitialized variable in amdgpu_vm_update_directories()
    
    commit 78aa02c713fcf19e9bc8511ab61a5fd6c877cc01 upstream.
    
    After commit ea09729c9302 ("drm/amdgpu: rework page directory filling
    v2") then it becomes a lot harder to verify that "r" is initialized.  My
    static checker complains and so I've reviewed the code.  It does look
    like it might be buggy... Anyway, it doesn't hurt to set "r" to zero
    at the start.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2d8b3a9b7853dbbf12c853674ef4403481ab1513
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Sat Sep 30 11:13:28 2017 +0300

    drm/amdgpu: potential uninitialized variable in amdgpu_vce_ring_parse_cs()
    
    commit 40a9960b046290939b56ce8e51f365258f27f264 upstream.
    
    We shifted some code around in commit 9cca0b8e5df0 ("drm/amdgpu: move
    amdgpu_cs_sysvm_access_required into find_mapping") and now my static
    checker complains that "r" might not be initialized at the end of the
    function.  I've reviewed the code, and that seems possible, but it's
    also possible I may have missed something.
    
    Reviewed-by: Christian König <christian.koenig@amd.com>
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 23506bc7fdb2313c63d8811967fcf82d5764b973
Author: Alex Deucher <alexander.deucher@amd.com>
Date:   Tue Nov 14 17:19:29 2017 -0500

    Revert "drm/radeon: dont switch vt on suspend"
    
    commit 18c437caa5b18a235dd65cec224eab54bebcee65 upstream.
    
    Fixes distorted colors on some cards on resume from suspend.
    
    This reverts commit b9729b17a414f99c61f4db9ac9f9ed987fa0cbfe.
    
    Bug: https://bugs.freedesktop.org/show_bug.cgi?id=98832
    Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99163
    Bug: https://bugzilla.kernel.org/show_bug.cgi?id=107001
    Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
    Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 5e19169a88be15d6c845e93d62e448ee06a14b2f
Author: Jeff Lien <jeff.lien@wdc.com>
Date:   Tue Nov 21 10:44:37 2017 -0600

    nvme-pci: add quirk for delay before CHK RDY for WDC SN200
    
    commit 8c97eeccf0ad8783c057830119467b877bdfced7 upstream.
    
    And increase the existing delay to cover this device as well.
    
    Signed-off-by: Jeff Lien <jeff.lien@wdc.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit de120fc9624162a3507091d6b92dd9037440c9d8
Author: Peter Rosin <peda@axentia.se>
Date:   Mon Nov 27 17:31:00 2017 +0100

    hwmon: (jc42) optionally try to disable the SMBUS timeout
    
    commit 68615eb01f82256c19e41967bfb3eef902f77033 upstream.
    
    With a nxp,se97 chip on an atmel sama5d31 board, the I2C adapter driver
    is not always capable of avoiding the 25-35 ms timeout as specified by
    the SMBUS protocol. This may cause silent corruption of the last bit of
    any transfer, e.g. a one is read instead of a zero if the sensor chip
    times out. This also affects the eeprom half of the nxp-se97 chip, where
    this silent corruption was originally noticed. Other I2C adapters probably
    suffer similar issues, e.g. bit-banging comes to mind as risky...
    
    The SMBUS register in the nxp chip is not a standard Jedec register, but
    it is not special to the nxp chips either, at least the atmel chips
    have the same mechanism. Therefore, do not special case this on the
    manufacturer, it is opt-in via the device property anyway.
    
    Signed-off-by: Peter Rosin <peda@axentia.se>
    Acked-by: Rob Herring <robh@kernel.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cafc451a955c44ec7eba47bae340d9ca5ccb483
Author: Rui Hua <huarui.dev@gmail.com>
Date:   Fri Nov 24 15:14:26 2017 -0800

    bcache: recover data from backing when data is clean
    
    commit e393aa2446150536929140739f09c6ecbcbea7f0 upstream.
    
    When we send a read request and hit the clean data in cache device, there
    is a situation called cache read race in bcache(see the commit in the tail
    of cache_look_up(), the following explaination just copy from there):
    The bucket we're reading from might be reused while our bio is in flight,
    and we could then end up reading the wrong data. We guard against this
    by checking (in bch_cache_read_endio()) if the pointer is stale again;
    if so, we treat it as an error (s->iop.error = -EINTR) and reread from
    the backing device (but we don't pass that error up anywhere)
    
    It should be noted that cache read race happened under normal
    circumstances, not the circumstance when SSD failed, it was counted
    and shown in  /sys/fs/bcache/XXX/internal/cache_read_races.
    
    Without this patch, when we use writeback mode, we will never reread from
    the backing device when cache read race happened, until the whole cache
    device is clean, because the condition
    (s->recoverable && (dc && !atomic_read(&dc->has_dirty))) is false in
    cached_dev_read_error(). In this situation, the s->iop.error(= -EINTR)
    will be passed up, at last, user will receive -EINTR when it's bio end,
    this is not suitable, and wield to up-application.
    
    In this patch, we use s->read_dirty_data to judge whether the read
    request hit dirty data in cache device, it is safe to reread data from
    the backing device when the read request hit clean data. This can not
    only handle cache read race, but also recover data when failed read
    request from cache device.
    
    [edited by mlyle to fix up whitespace, commit log title, comment
    spelling]
    
    Fixes: d59b23795933 ("bcache: only permit to recovery read error when cache device is clean")
    Signed-off-by: Hua Rui <huarui.dev@gmail.com>
    Reviewed-by: Michael Lyle <mlyle@lyle.org>
    Reviewed-by: Coly Li <colyli@suse.de>
    Signed-off-by: Michael Lyle <mlyle@lyle.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 260c6625c85e7e1a5db0b5ece9944a4010c9bade
Author: Coly Li <colyli@suse.de>
Date:   Mon Oct 30 14:46:31 2017 -0700

    bcache: only permit to recovery read error when cache device is clean
    
    commit d59b23795933678c9638fd20c942d2b4f3cd6185 upstream.
    
    When bcache does read I/Os, for example in writeback or writethrough mode,
    if a read request on cache device is failed, bcache will try to recovery
    the request by reading from cached device. If the data on cached device is
    not synced with cache device, then requester will get a stale data.
    
    For critical storage system like database, providing stale data from
    recovery may result an application level data corruption, which is
    unacceptible.
    
    With this patch, for a failed read request in writeback or writethrough
    mode, recovery a recoverable read request only happens when cache device
    is clean. That is to say, all data on cached device is up to update.
    
    For other cache modes in bcache, read request will never hit
    cached_dev_read_error(), they don't need this patch.
    
    Please note, because cache mode can be switched arbitrarily in run time, a
    writethrough mode might be switched from a writeback mode. Therefore
    checking dc->has_data in writethrough mode still makes sense.
    
    Changelog:
    V4: Fix parens error pointed by Michael Lyle.
    v3: By response from Kent Oversteet, he thinks recovering stale data is a
        bug to fix, and option to permit it is unnecessary. So this version
        the sysfs file is removed.
    v2: rename sysfs entry from allow_stale_data_on_failure  to
        allow_stale_data_on_failure, and fix the confusing commit log.
    v1: initial patch posted.
    
    [small change to patch comment spelling by mlyle]
    
    Signed-off-by: Coly Li <colyli@suse.de>
    Signed-off-by: Michael Lyle <mlyle@lyle.org>
    Reported-by: Arne Wolf <awolf@lenovo.com>
    Reviewed-by: Michael Lyle <mlyle@lyle.org>
    Cc: Kent Overstreet <kent.overstreet@gmail.com>
    Cc: Nix <nix@esperi.org.uk>
    Cc: Kai Krakow <hurikhan77@gmail.com>
    Cc: Eric Wheeler <bcache@lists.ewheeler.net>
    Cc: Junhui Tang <tang.junhui@zte.com.cn>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f5b41b366273ff51c7a62643f8667784eb349fba
Author: Huacai Chen <chenhc@lemote.com>
Date:   Fri Nov 24 15:14:25 2017 -0800

    bcache: Fix building error on MIPS
    
    commit cf33c1ee5254c6a430bc1538232b49c3ea13e613 upstream.
    
    This patch try to fix the building error on MIPS. The reason is MIPS
    has already defined the PTR macro, which conflicts with the PTR macro
    in include/uapi/linux/bcache.h.
    
    [fixed by mlyle: corrected a line-length issue]
    
    Signed-off-by: Huacai Chen <chenhc@lemote.com>
    Reviewed-by: Michael Lyle <mlyle@lyle.org>
    Signed-off-by: Michael Lyle <mlyle@lyle.org>
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6e8aca2095790b90217b759a0d5e2ec5138bbfd2
Author: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Date:   Thu Nov 23 09:08:57 2017 +0530

    cxl: Check if vphb exists before iterating over AFU devices
    
    commit 12841f87b7a8ceb3d54f171660f72a86941bfcb3 upstream.
    
    During an eeh a kernel-oops is reported if no vPHB is allocated to the
    AFU. This happens as during AFU init, an error in creation of vPHB is
    a non-fatal error. Hence afu->phb should always be checked for NULL
    before iterating over it for the virtual AFU pci devices.
    
    This patch fixes the kenel-oops by adding a NULL pointer check for
    afu->phb before it is dereferenced.
    
    Fixes: 9e8df8a21963 ("cxl: EEH support")
    Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
    Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
    Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c71f896bb8f3b7bb228ece70341b26b2ff32ae9
Author: Hans de Goede <hdegoede@redhat.com>
Date:   Wed Nov 22 12:28:17 2017 +0100

    i2c: i801: Fix Failed to allocate irq -2147483648 error
    
    commit 6e0c9507bf51e1517a80ad0ac171e5402528fcef upstream.
    
    On Apollo Lake devices the BIOS does not set up IRQ routing for the i801
    SMBUS controller IRQ, so we end up with dev->irq set to IRQ_NOTCONNECTED.
    
    Detect this and do not try to use the irq in this case silencing:
    i801_smbus 0000:00:1f.1: Failed to allocate irq -2147483648: -107
    
    BugLink: https://communities.intel.com/thread/114759
    Signed-off-by: Hans de Goede <hdegoede@redhat.com>
    Reviewed-by: Jean Delvare <jdelvare@suse.de>
    Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 52d9bb958f080f0a548139676dbf6a87a40af2a0
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Fri Nov 24 07:47:50 2017 +0100

    eeprom: at24: check at24_read/write arguments
    
    commit d9bcd462daf34aebb8de9ad7f76de0198bb5a0f0 upstream.
    
    So far we completely rely on the caller to provide valid arguments.
    To be on the safe side perform an own sanity check.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 656155d07658e84ac6ab6f6eceac67b807d6fedb
Author: Bartosz Golaszewski <brgl@bgdev.pl>
Date:   Mon Nov 27 22:06:13 2017 +0100

    eeprom: at24: correctly set the size for at24mac402
    
    commit 5478e478eee3b096b8d998d4ed445da30da2dfbc upstream.
    
    There's an ilog2() expansion in AT24_DEVICE_MAGIC() which rounds down
    the actual size of EUI-48 byte array in at24mac402 eeproms to 4 from 6,
    making it impossible to read it all.
    
    Fix it by manually adjusting the value in probe().
    
    This patch contains a temporary fix that is suitable for stable
    branches. Eventually we'll probably remove the call to ilog2() while
    converting the magic values to actual structs.
    
    Fixes: 0b813658c115 ("eeprom: at24: add support for at24mac series")
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ad53c57966a1a295c0ea5a8a7d6e85d3d75253a
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Mon Nov 27 20:46:22 2017 +0100

    eeprom: at24: fix reading from 24MAC402/24MAC602
    
    commit 644a1f19c6c8393d0c4168a5adf79056da6822eb upstream.
    
    Chip datasheet mentions that word addresses other than the actual
    start position of the MAC delivers undefined results. So fix this.
    Current implementation doesn't work due to this wrong offset.
    
    Fixes: 0b813658c115 ("eeprom: at24: add support for at24mac series")
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 450d75882552d59bb03b1ccb0999e98f5b227532
Author: Lv Zheng <lv.zheng@intel.com>
Date:   Tue Sep 26 16:54:09 2017 +0800

    ACPI / EC: Fix regression related to PM ops support in ECDT device
    
    commit a64a62ce9a380213dc9e192f762266d70c9b40ec upstream.
    
    On platforms (ASUS X550ZE and possibly all ASUS X series) with valid ECDT
    EC but invalid DSDT EC, EC PM ops won't be invoked as ECDT EC is not an
    ACPI device. Thus the following commit actually removed post-resume
    acpi_ec_enable_event() invocation for such platforms, and triggered a
    regression on them that after being resumed, EC (actually should be ECDT)
    driver stops handling EC events:
    
     Commit: c2b46d679b30c5c0d7eb47a21085943242bdd8dc
     Subject: ACPI / EC: Add PM operations to improve event handling for resume process
    
    Notice that the root cause actually is "ECDT is not an ACPI device" rather
    than "the timing of acpi_ec_enable_event() invocation", this patch fixes
    this issue by enumerating ECDT EC as an ACPI device. Due to the existence
    of the noirq stage, the ability of tuning the timing of
    acpi_ec_enable_event() invocation is still meaningful.
    
    This patch is a little bit different from the posted fix by moving
    acpi_config_boot_ec() from acpi_ec_ecdt_start() to acpi_ec_add() to make
    sure that EC event handling won't be stopped as long as the ACPI EC driver
    is bound. Thus the following sequence shouldn't disable EC event handling:
    unbind,suspend,resume,bind.
    
    Fixes: c2b46d679b30 (ACPI / EC: Add PM operations to improve event handling for resume process)
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=196847
    Reported-by: Luya Tshimbalanga <luya@fedoraproject.org>
    Tested-by: Luya Tshimbalanga <luya@fedoraproject.org>
    Signed-off-by: Lv Zheng <lv.zheng@intel.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1ef1173c4864c06b6104f386c2694aa740cf02ee
Author: Bastian Stender <bst@pengutronix.de>
Date:   Tue Nov 28 09:24:07 2017 +0100

    mmc: core: prepend 0x to OCR entry in sysfs
    
    commit c892b0d81705c566f575e489efc3c50762db1bde upstream.
    
    The sysfs entry "ocr" was missing the 0x prefix to identify it as hex
    formatted.
    
    Fixes: 5fb06af7a33b ("mmc: core: Extend sysfs with OCR register")
    Signed-off-by: Bastian Stender <bst@pengutronix.de>
    [Ulf: Amended change to also cover SD-cards]
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e6aa6389263d0db52ea674ed45eb591d21585eca
Author: Bastian Stender <bst@pengutronix.de>
Date:   Tue Nov 28 09:24:06 2017 +0100

    mmc: core: prepend 0x to pre_eol_info entry in sysfs
    
    commit 80a780a167d9267c72867b806142bd6ec69ba123 upstream.
    
    The sysfs entry "pre_eol_info" was missing the 0x prefix to identify it
    as hex formatted.
    
    Fixes: 46bc5c408e4e ("mmc: core: Export device lifetime information through sysfs")
    Signed-off-by: Bastian Stender <bst@pengutronix.de>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 64d1df6f018e728774bdf5d1aeb576d1c8d1872d
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Nov 21 15:42:30 2017 +0200

    mmc: block: Ensure that debugfs files are removed
    
    commit f9f0da98819503b06b35e61869d18cf3a8cd3323 upstream.
    
    The card is not necessarily being removed, but the debugfs files must be
    removed when the driver is removed, otherwise they will continue to exist
    after unbinding the card from the driver. e.g.
    
      # echo "mmc1:0001" > /sys/bus/mmc/drivers/mmcblk/unbind
      # cat /sys/kernel/debug/mmc1/mmc1\:0001/ext_csd
      [  173.634584] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      [  173.643356] IP: mmc_ext_csd_open+0x5e/0x170
    
    A complication is that the debugfs_root may have already been removed, so
    check for that too.
    
    Fixes: 627c3ccfb46a ("mmc: debugfs: Move block debugfs into block module")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 94497458fbb519dbc230e5156f58d4b3a49ba0c1
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Nov 21 15:42:29 2017 +0200

    mmc: core: Do not leave the block driver in a suspended state
    
    commit ebe7dd45cf49e3b49cacbaace17f9f878f21fbea upstream.
    
    The block driver must be resumed if the mmc bus fails to suspend the card.
    
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 957c27d45611ad4ef924840346bc338b8f3c870b
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Nov 21 15:42:28 2017 +0200

    mmc: block: Check return value of blk_get_request()
    
    commit fb8e456e547ed2c699f64665bd8a3b9bde7b9728 upstream.
    
    blk_get_request() can fail, always check the return value.
    
    Fixes: 0493f6fe5bde ("mmc: block: Move boot partition locking into a driver op")
    Fixes: 3ecd8cf23f88 ("mmc: block: move multi-ioctl() to use block layer")
    Fixes: 614f0388f580 ("mmc: block: move single ioctl() commands to block requests")
    Fixes: 627c3ccfb46a ("mmc: debugfs: Move block debugfs into block module")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0d8d2b6373c19f85bab6af1702563b50e17b2cf6
Author: Adrian Hunter <adrian.hunter@intel.com>
Date:   Tue Nov 21 15:42:27 2017 +0200

    mmc: block: Fix missing blk_put_request()
    
    commit 34c089e806793a66e450b11bd167db6047399fcd upstream.
    
    Ensure blk_get_request() is paired with blk_put_request().
    
    Fixes: 0493f6fe5bde ("mmc: block: Move boot partition locking into a driver op")
    Fixes: 627c3ccfb46a ("mmc: debugfs: Move block debugfs into block module")
    Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
    Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4162b2973c1c6e49d7b193e572dec691233115c3
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Mon Nov 27 11:28:50 2017 +0100

    mmc: sdhci: Avoid swiotlb buffer being full
    
    commit 250dcd11466e06df64b92520e2c56bdae453581b upstream.
    
    The commit de3ee99b097d ("mmc: Delete bounce buffer handling") deletes the
    bounce buffer handling, but also causes the max_req_size for sdhci to be
    increased, in case when max_segs == 1. This causes errors for sdhci-pci
    Ricoh variant, about the swiotlb buffer to become full.
    
    Fix the issue, by taking IO_TLB_SEGSIZE and IO_TLB_SHIFT into account when
    deciding the max_req_size for sdhci.
    
    Reported-by: Jiri Slaby <jslaby@suse.cz>
    Fixes: de3ee99b097d ("mmc: Delete bounce buffer handling")
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Tested-by: Jiri Slaby <jslaby@suse.cz>
    Acked-by: Adrian Hunter <adrian.hunter@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 81b3019c35d650e7570ff016ba0732ba6d62c466
Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Date:   Fri Nov 17 11:52:50 2017 +0000

    KVM: lapic: Fixup LDR on load in x2apic
    
    commit 12806ba937382fdfdbad62a399aa2dce65c10fcd upstream.
    
    In x2apic mode the LDR is fixed based on the ID rather
    than separately loadable like it was before x2.
    When kvm_apic_set_state is called, the base is set, and if
    it has the X2APIC_ENABLE flag set then the LDR is calculated;
    however that value gets overwritten by the memcpy a few lines
    below overwriting it with the value that came from userland.
    
    The symptom is a lack of EOI after loading the state
    (e.g. after a QEMU migration) and is due to the EOI bitmap
    being wrong due to the incorrect LDR.  This was seen with
    a Win2016 guest under Qemu with irqchip=split whose USB mouse
    didn't work after a VM migration.
    
    This corresponds to RH bug:
      https://bugzilla.redhat.com/show_bug.cgi?id=1502591
    
    Reported-by: Yiqian Wei <yiwei@redhat.com>
    Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    [Applied fixup from Liran Alon. - Paolo]
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 47b35d190b4676953a5ce25572e031d842264194
Author: Dr. David Alan Gilbert <dgilbert@redhat.com>
Date:   Fri Nov 17 11:52:49 2017 +0000

    KVM: lapic: Split out x2apic ldr calculation
    
    commit e872fa94662d0644057c7c80b3071bdb9249e5ab upstream.
    
    Split out the ldr calculation from kvm_apic_set_x2apic_id
    since we're about to reuse it in the following patch.
    
    Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bb98bd9733b5b54b0de67e171b0057dcc6fb98de
Author: Paolo Bonzini <pbonzini@redhat.com>
Date:   Fri Nov 10 10:49:38 2017 +0100

    KVM: x86: inject exceptions produced by x86_decode_insn
    
    commit 6ea6e84309ca7e0e850b3083e6b09344ee15c290 upstream.
    
    Sometimes, a processor might execute an instruction while another
    processor is updating the page tables for that instruction's code page,
    but before the TLB shootdown completes.  The interesting case happens
    if the page is in the TLB.
    
    In general, the processor will succeed in executing the instruction and
    nothing bad happens.  However, what if the instruction is an MMIO access?
    If *that* happens, KVM invokes the emulator, and the emulator gets the
    updated page tables.  If the update side had marked the code page as non
    present, the page table walk then will fail and so will x86_decode_insn.
    
    Unfortunately, even though kvm_fetch_guest_virt is correctly returning
    X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as
    a fatal error if the instruction cannot simply be reexecuted (as is the
    case for MMIO).  And this in fact happened sometimes when rebooting
    Windows 2012r2 guests.  Just checking ctxt->have_exception and injecting
    the exception if true is enough to fix the case.
    
    Thanks to Eduardo Habkost for helping in the debugging of this issue.
    
    Reported-by: Yanan Fu <yfu@redhat.com>
    Cc: Eduardo Habkost <ehabkost@redhat.com>
    Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 15cc35bc76f95d22d1e3e42617f6103568f19931
Author: Liran Alon <liran.alon@oracle.com>
Date:   Sun Nov 5 16:56:32 2017 +0200

    KVM: x86: Exit to user-mode on #UD intercept when emulator requires
    
    commit 61cb57c9ed631c95b54f8e9090c89d18b3695b3c upstream.
    
    Instruction emulation after trapping a #UD exception can result in an
    MMIO access, for example when emulating a MOVBE on a processor that
    doesn't support the instruction.  In this case, the #UD vmexit handler
    must exit to user mode, but there wasn't any code to do so.  Add it for
    both VMX and SVM.
    
    Signed-off-by: Liran Alon <liran.alon@oracle.com>
    Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Wanpeng Li <wanpeng.li@hotmail.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c4eaffbad3701f037f1d60ca892dcbe7641ff74
Author: Liran Alon <liran.alon@oracle.com>
Date:   Sun Nov 5 16:11:30 2017 +0200

    KVM: x86: pvclock: Handle first-time write to pvclock-page contains random junk
    
    commit 51c4b8bba674cfd2260d173602c4dac08e4c3a99 upstream.
    
    When guest passes KVM it's pvclock-page GPA via WRMSR to
    MSR_KVM_SYSTEM_TIME / MSR_KVM_SYSTEM_TIME_NEW, KVM don't initialize
    pvclock-page to some start-values. It just requests a clock-update which
    will happen before entering to guest.
    
    The clock-update logic will call kvm_setup_pvclock_page() to update the
    pvclock-page with info. However, kvm_setup_pvclock_page() *wrongly*
    assumes that the version-field is initialized to an even number. This is
    wrong because at first-time write, field could be any-value.
    
    Fix simply makes sure that if first-time version-field is odd, increment
    it once more to make it even and only then start standard logic.
    This follows same logic as done in other pvclock shared-pages (See
    kvm_write_wall_clock() and record_steal_time()).
    
    Signed-off-by: Liran Alon <liran.alon@oracle.com>
    Reviewed-by: Nikita Leshenko <nikita.leshchenko@oracle.com>
    Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
    Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
    Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c12e358867d2656b10ccccc36240d6ce93e0e497
Author: Michael Ellerman <mpe@ellerman.id.au>
Date:   Fri Nov 24 14:51:02 2017 +1100

    powerpc/kexec: Fix kexec/kdump in P9 guest kernels
    
    commit 2621e945fbf1d6df5f3f0ba7be5bae3d2cf9b6a5 upstream.
    
    The code that cleans up the IAMR/AMOR before kexec'ing failed to
    remember that when we're running as a guest AMOR is not writable, it's
    hypervisor privileged.
    
    They symptom is that the kexec stops before entering purgatory and
    nothing else is seen on the console. If you examine the state of the
    system all threads will be in the 0x700 program check handler.
    
    Fix it by making the write to AMOR dependent on HV mode.
    
    Fixes: 1e2a516e89fc ("powerpc/kexec: Fix radix to hash kexec due to IAMR/AMOR")
    Reported-by: Yilin Zhang <yilzhang@redhat.com>
    Debugged-by: David Gibson <david@gibson.dropbear.id.au>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Acked-by: Balbir Singh <bsingharora@gmail.com>
    Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
    Tested-by: David Gibson <david@gibson.dropbear.id.au>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 3bfbf2b1bc18f76dc88064b4d6354b2e4424478c
Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Date:   Wed Nov 22 23:02:07 2017 +0530

    powerpc/powernv: Fix kexec crashes caused by tlbie tracing
    
    commit a3961f824cdbe7eb431254dc7d8f6f6767f474aa upstream.
    
    Rebooting into a new kernel with kexec fails in trace_tlbie() which is
    called from native_hpte_clear(). This happens if the running kernel
    has CONFIG_LOCKDEP enabled. With lockdep enabled, the tracepoints
    always execute few RCU checks regardless of whether tracing is on or
    off. We are already in the last phase of kexec sequence in real mode
    with HILE_BE set. At this point the RCU check ends up in
    RCU_LOCKDEP_WARN and causes kexec to fail.
    
    Fix this by not calling trace_tlbie() from native_hpte_clear().
    
    mpe: It's not safe to call trace points at this point in the kexec
    path, even if we could avoid the RCU checks/warnings. The only
    solution is to not call them.
    
    Fixes: 0428491cba92 ("powerpc/mm: Trace tlbie(l) instructions")
    Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
    Reported-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
    Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
    Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e9b2a6680fb6173819598cba411522d37cb4585a
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Mon Nov 20 17:41:30 2017 +0000

    arm64: ftrace: emit ftrace-mod.o contents through code
    
    commit be0f272bfc83797f70d44faca86954df62e2bbc0 upstream.
    
    When building the arm64 kernel with both CONFIG_ARM64_MODULE_PLTS and
    CONFIG_DYNAMIC_FTRACE enabled, the ftrace-mod.o object file is built
    with the kernel and contains a trampoline that is linked into each
    module, so that modules can be loaded far away from the kernel and
    still reach the ftrace entry point in the core kernel with an ordinary
    relative branch, as is emitted by the compiler instrumentation code
    dynamic ftrace relies on.
    
    In order to be able to build out of tree modules, this object file
    needs to be included into the linux-headers or linux-devel packages,
    which is undesirable, as it makes arm64 a special case (although a
    precedent does exist for 32-bit PPC).
    
    Given that the trampoline essentially consists of a PLT entry, let's
    not bother with a source or object file for it, and simply patch it
    in whenever the trampoline is being populated, using the existing
    PLT support routines.
    
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e1b4e001b22a12b67c890f4611bcf55285fd0fc5
Author: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Mon Nov 20 17:41:29 2017 +0000

    arm64: module-plts: factor out PLT generation code for ftrace
    
    commit 7e8b9c1d2e2f5f45db7d40b50d14f606097c25de upstream.
    
    To allow the ftrace trampoline code to reuse the PLT entry routines,
    factor it out and move it into asm/module.h.
    
    Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 69af22696bc737dfe3444d2ece5db000fbff5c35
Author: John Johansen <john.johansen@canonical.com>
Date:   Wed Nov 22 07:33:38 2017 -0800

    apparmor: fix oops in audit_signal_cb hook
    
    commit b12cbb21586277f72533769832c24cc6c1d60ab3 upstream.
    
    The apparmor_audit_data struct ordering got messed up during a merge
    conflict, resulting in the signal integer and peer pointer being in
    a union instead of a struct.
    
    For most of the 4.13 and 4.14 life cycle, this was hidden by
    commit 651e28c5537a ("apparmor: add base infastructure for socket
    mediation") which fixed the apparmor_audit_data struct when its data
    was added. When that commit was reverted in -rc7 the signal audit bug
    was exposed, and unfortunately it never showed up in any of the
    testing until after 4.14 was released. Shaun Khan, Zephaniah
    E. Loss-Cutler-Hull filed nearly simultaneous bug reports (with
    different oopes, the smaller of which is included below).
    
    Full credit goes to Tetsuo Handa for jumping on this as well and
    noticing the audit data struct problem and reporting it.
    
    [   76.178568] BUG: unable to handle kernel paging request at
    ffffffff0eee3bc0
    [   76.178579] IP: audit_signal_cb+0x6c/0xe0
    [   76.178581] PGD 1a640a067 P4D 1a640a067 PUD 0
    [   76.178586] Oops: 0000 [#1] PREEMPT SMP
    [   76.178589] Modules linked in: fuse rfcomm bnep usblp uvcvideo btusb
    btrtl btbcm btintel bluetooth ecdh_generic ip6table_filter ip6_tables
    xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack
    iptable_filter ip_tables x_tables intel_rapl joydev wmi_bmof serio_raw
    iwldvm iwlwifi shpchp kvm_intel kvm irqbypass autofs4 algif_skcipher
    nls_iso8859_1 nls_cp437 crc32_pclmul ghash_clmulni_intel
    [   76.178620] CPU: 0 PID: 10675 Comm: pidgin Not tainted
    4.14.0-f1-dirty #135
    [   76.178623] Hardware name: Hewlett-Packard HP EliteBook Folio
    9470m/18DF, BIOS 68IBD Ver. F.62 10/22/2015
    [   76.178625] task: ffff9c7a94c31dc0 task.stack: ffffa09b02a4c000
    [   76.178628] RIP: 0010:audit_signal_cb+0x6c/0xe0
    [   76.178631] RSP: 0018:ffffa09b02a4fc08 EFLAGS: 00010292
    [   76.178634] RAX: ffffa09b02a4fd60 RBX: ffff9c7aee0741f8 RCX:
    0000000000000000
    [   76.178636] RDX: ffffffffee012290 RSI: 0000000000000006 RDI:
    ffff9c7a9493d800
    [   76.178638] RBP: ffffa09b02a4fd40 R08: 000000000000004d R09:
    ffffa09b02a4fc46
    [   76.178641] R10: ffffa09b02a4fcb8 R11: ffff9c7ab44f5072 R12:
    ffffa09b02a4fd40
    [   76.178643] R13: ffffffff9e447be0 R14: ffff9c7a94c31dc0 R15:
    0000000000000001
    [   76.178646] FS:  00007f8b11ba2a80(0000) GS:ffff9c7afea00000(0000)
    knlGS:0000000000000000
    [   76.178648] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   76.178650] CR2: ffffffff0eee3bc0 CR3: 00000003d5209002 CR4:
    00000000001606f0
    [   76.178652] Call Trace:
    [   76.178660]  common_lsm_audit+0x1da/0x780
    [   76.178665]  ? d_absolute_path+0x60/0x90
    [   76.178669]  ? aa_check_perms+0xcd/0xe0
    [   76.178672]  aa_check_perms+0xcd/0xe0
    [   76.178675]  profile_signal_perm.part.0+0x90/0xa0
    [   76.178679]  aa_may_signal+0x16e/0x1b0
    [   76.178686]  apparmor_task_kill+0x51/0x120
    [   76.178690]  security_task_kill+0x44/0x60
    [   76.178695]  group_send_sig_info+0x25/0x60
    [   76.178699]  kill_pid_info+0x36/0x60
    [   76.178703]  SYSC_kill+0xdb/0x180
    [   76.178707]  ? preempt_count_sub+0x92/0xd0
    [   76.178712]  ? _raw_write_unlock_irq+0x13/0x30
    [   76.178716]  ? task_work_run+0x6a/0x90
    [   76.178720]  ? exit_to_usermode_loop+0x80/0xa0
    [   76.178723]  entry_SYSCALL_64_fastpath+0x13/0x94
    [   76.178727] RIP: 0033:0x7f8b0e58b767
    [   76.178729] RSP: 002b:00007fff19efd4d8 EFLAGS: 00000206 ORIG_RAX:
    000000000000003e
    [   76.178732] RAX: ffffffffffffffda RBX: 0000557f3e3c2050 RCX:
    00007f8b0e58b767
    [   76.178735] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
    000000000000263b
    [   76.178737] RBP: 0000000000000000 R08: 0000557f3e3c2270 R09:
    0000000000000001
    [   76.178739] R10: 000000000000022d R11: 0000000000000206 R12:
    0000000000000000
    [   76.178741] R13: 0000000000000001 R14: 0000557f3e3c13c0 R15:
    0000000000000000
    [   76.178745] Code: 48 8b 55 18 48 89 df 41 b8 20 00 08 01 5b 5d 48 8b
    42 10 48 8b 52 30 48 63 48 4c 48 8b 44 c8 48 31 c9 48 8b 70 38 e9 f4 fd
    00 00 <48> 8b 14 d5 40 27 e5 9e 48 c7 c6 7d 07 19 9f 48 89 df e8 fd 35
    [   76.178794] RIP: audit_signal_cb+0x6c/0xe0 RSP: ffffa09b02a4fc08
    [   76.178796] CR2: ffffffff0eee3bc0
    [   76.178799] ---[ end trace 514af9529297f1a3 ]---
    
    Fixes: cd1dbf76b23d ("apparmor: add the ability to mediate signals")
    Reported-by: Zephaniah E. Loss-Cutler-Hull <warp-spam_kernel@aehallh.com>
    Reported-by: Shuah Khan <shuahkh@osg.samsung.com>
    Suggested-by: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
    Tested-by: Ivan Kozik <ivan@ludios.org>
    Tested-by: Zephaniah E. Loss-Cutler-Hull <warp-spam_kernel@aehallh.com>
    Tested-by: Christian Boltz <apparmor@cboltz.de>
    Tested-by: Shuah Khan <shuahkh@osg.samsung.com>
    Signed-off-by: John Johansen <john.johansen@canonical.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a3ed24cd28f2db6f6f5b2009565a2463c0df4af0
Author: Peter Ujfalusi <peter.ujfalusi@ti.com>
Date:   Mon Nov 20 11:51:40 2017 +0200

    omapdrm: hdmi4: Correct the SoC revision matching
    
    commit 23970e150a0a49f9a966c46e5d22fed06226098f upstream.
    
    I believe the intention of the commit 2c9fc9bf45f8
    ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
    was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions,
    like omap4460.
    
    By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a
    same way as it would treat omap4430 ES1.x
    
    This breaks HDMI audio on OMAP4460 devices (PandaES for example).
    
    Correct the match rule so we are not going to get false positive match.
    
    Fixes: 2c9fc9bf45f8 ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver")
    
    Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
    Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4479ade38b14f53673b0843308fe24344b37cba5
Author: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Date:   Thu Nov 16 09:50:19 2017 +0100

    drm: omapdrm: Fix DPI on platforms using the DSI VDDS
    
    commit bf25dac38f71d392a31ec074f55cbc941f1eaf1d upstream.
    
    Commit d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature
    to dpi code") replaced usage of platform data version with SoC matching
    to configure DPI VDDS. The SoC match entries were incorrect, they should
    have matched on the machine name instead of the SoC family. Fix it.
    
    The result was observed on OpenPandora with OMAP3530 where the panel only
    had the Blue channel and Red&Green were missing. It was not observed on
    GTA04 with DM3730.
    
    Fixes: d178e034d565 ("drm: omapdrm: Move FEAT_DPI_USES_VDDS_DSI feature to dpi code")
    Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
    Reported-by: H. Nikolaus Schaller <hns@goldelico.com>
    Tested-by: H. Nikolaus Schaller <hns@goldelico.com>
    Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b367ea94535dbdede5e00110339b3e4c9bdc617d
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date:   Fri Nov 24 16:23:15 2017 +0100

    s390: revert ELF_ET_DYN_BASE base changes
    
    commit 345f8f34bb473241d62803951c18a844dd705f8d upstream.
    
    This reverts commit a73dc5370e153ac63718d850bddf0c9aa9d871e6.
    
    Reducing the base address for 31-bit PIE executables from
    (STACK_TOP/3)*2 to 4MB broke several compat programs which
    use -fpie to move the executable out of the lower 16MB.
    
    Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 84779085fa10014b9e8208d7e71b54bced73075c
Author: Vasily Averin <vvs@virtuozzo.com>
Date:   Thu Nov 2 13:03:42 2017 +0300

    lockd: lost rollback of set_grace_period() in lockd_down_net()
    
    commit 3a2b19d1ee5633f76ae8a88da7bc039a5d1732aa upstream.
    
    Commit efda760fe95ea ("lockd: fix lockd shutdown race") is incorrect,
    it removes lockd_manager and disarm grace_period_end for init_net only.
    
    If nfsd was started from another net namespace lockd_up_net() calls
    set_grace_period() that adds lockd_manager into per-netns list
    and queues grace_period_end delayed work.
    
    These action should be reverted in lockd_down_net().
    Otherwise it can lead to double list_add on after restart nfsd in netns,
    and to use-after-free if non-disarmed delayed work will be executed after netns destroy.
    
    Fixes: efda760fe95e ("lockd: fix lockd shutdown race")
    Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 861eae231b0437427676a4ed323d31097002d5a2
Author: Ondrej Mosnáček <omosnacek@gmail.com>
Date:   Thu Nov 23 13:49:06 2017 +0100

    crypto: skcipher - Fix skcipher_walk_aead_common
    
    commit c14ca8386539a298c1c19b003fe55e37d0f0e89c upstream.
    
    The skcipher_walk_aead_common function calls scatterwalk_copychunks on
    the input and output walks to skip the associated data. If the AD end
    at an SG list entry boundary, then after these calls the walks will
    still be pointing to the end of the skipped region.
    
    These offsets are later checked for alignment in skcipher_walk_next,
    so the skcipher_walk may detect the alignment incorrectly.
    
    This patch fixes it by calling scatterwalk_done after the copychunks
    calls to ensure that the offsets refer to the right SG list entry.
    
    Fixes: b286d8b1a690 ("crypto: skcipher - Add skcipher walk interface")
    Signed-off-by: Ondrej Mosnacek <omosnacek@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 7f21961a2d7bfe45f734eab5b0ce6a40ee128b17
Author: Stephan Mueller <smueller@chronox.de>
Date:   Fri Nov 10 13:20:55 2017 +0100

    crypto: af_alg - remove locking in async callback
    
    commit 7d2c3f54e6f646887d019faa45f35d6fe9fe82ce upstream.
    
    The code paths protected by the socket-lock do not use or modify the
    socket in a non-atomic fashion. The actions pertaining the socket do not
    even need to be handled as an atomic operation. Thus, the socket-lock
    can be safely ignored.
    
    This fixes a bug regarding scheduling in atomic as the callback function
    may be invoked in interrupt context.
    
    In addition, the sock_hold is moved before the AIO encrypt/decrypt
    operation to ensure that the socket is always present. This avoids a
    tiny race window where the socket is unprotected and yet used by the AIO
    operation.
    
    Finally, the release of resources for a crypto operation is moved into a
    common function of af_alg_free_resources.
    
    Fixes: e870456d8e7c8 ("crypto: algif_skcipher - overhaul memory management")
    Fixes: d887c52d6ae43 ("crypto: algif_aead - overhaul memory management")
    Reported-by: Romain Izard <romain.izard.pro@gmail.com>
    Signed-off-by: Stephan Mueller <smueller@chronox.de>
    Tested-by: Romain Izard <romain.izard.pro@gmail.com>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 721872a1997c4b8aae80ed2e6ef9dc05c53383f6
Author: Stephan Mueller <smueller@chronox.de>
Date:   Fri Nov 10 11:04:52 2017 +0100

    crypto: algif_aead - skip SGL entries with NULL page
    
    commit 8e1fa89aa8bc2870009b4486644e4a58f2e2a4f5 upstream.
    
    The TX SGL may contain SGL entries that are assigned a NULL page. This
    may happen if a multi-stage AIO operation is performed where the data
    for each stage is pointed to by one SGL entry. Upon completion of that
    stage, af_alg_pull_tsgl will assign NULL to the SGL entry.
    
    The NULL cipher used to copy the AAD from TX SGL to the destination
    buffer, however, cannot handle the case where the SGL starts with an SGL
    entry having a NULL page. Thus, the code needs to advance the start
    pointer into the SGL to the first non-NULL entry.
    
    This fixes a crash visible on Intel x86 32 bit using the libkcapi test
    suite.
    
    Fixes: 72548b093ee38 ("crypto: algif_aead - copy AAD from src to dst")
    Signed-off-by: Stephan Mueller <smueller@chronox.de>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b78da96d2882bea2ec7184dc1eba3e07e829364d
Author: Naofumi Honda <honda@math.sci.hokudai.ac.jp>
Date:   Thu Nov 9 10:57:16 2017 -0500

    nfsd: fix panic in posix_unblock_lock called from nfs4_laundromat
    
    commit 64ebe12494fd5d193f014ce38e1fd83cc57883c8 upstream.
    
    From kernel 4.9, my two nfsv4 servers sometimes suffer from
        "panic: unable to handle kernel page request"
    in posix_unblock_lock() called from nfs4_laundromat().
    
    These panics diseappear if we revert the commit "nfsd: add a LRU list
    for blocked locks".
    
    The cause appears to be a typo in nfs4_laundromat(), which is also
    present in nfs4_state_shutdown_net().
    
    Fixes: 7919d0a27f1e "nfsd: add a LRU list for blocked locks"
    Cc: jlayton@redhat.com
    Reveiwed-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73cfeab6755ccd442b689ea15769b7e9342c471e
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Fri Nov 3 08:00:11 2017 -0400

    nfsd: Fix another OPEN stateid race
    
    commit d8a1a000555ecd1b824ac1ed6df8fe364dfbbbb0 upstream.
    
    If nfsd4_process_open2() is initialising a new stateid, and yet the
    call to nfs4_get_vfs_file() fails for some reason, then we must
    declare the stateid closed, and unhash it before dropping the mutex.
    
    Right now, we unhash the stateid after dropping the mutex, and without
    changing the stateid type, meaning that another OPEN could theoretically
    look it up and attempt to use it.
    
    Reported-by: Andrew W Elble <aweits@rit.edu>
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit db77ab54a5e2f740d1ae39326f90c06d5c5a26d4
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Fri Nov 3 08:00:10 2017 -0400

    nfsd: Fix stateid races between OPEN and CLOSE
    
    commit 15ca08d3299682dc49bad73251677b2c5017ef08 upstream.
    
    Open file stateids can linger on the nfs4_file list of stateids even
    after they have been closed. In order to avoid reusing such a
    stateid, and confusing the client, we need to recheck the
    nfs4_stid's type after taking the mutex.
    Otherwise, we risk reusing an old stateid that was already closed,
    which will confuse clients that expect new stateids to conform to
    RFC7530 Sections 9.1.4.2 and 16.2.5 or RFC5661 Sections 8.2.2 and 18.2.4.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 28580e75734b8bfc10d0c23ba026737c71c551c8
Author: Josef Bacik <jbacik@fb.com>
Date:   Fri Nov 17 14:50:46 2017 -0500

    btrfs: clear space cache inode generation always
    
    commit 8e138e0d92c6c9d3d481674fb14e3439b495be37 upstream.
    
    We discovered a box that had double allocations, and suspected the space
    cache may be to blame.  While auditing the write out path I noticed that
    if we've already setup the space cache we will just carry on.  This
    means that any error we hit after cache_save_setup before we go to
    actually write the cache out we won't reset the inode generation, so
    whatever was already written will be considered correct, except it'll be
    stale.  Fix this by _always_ resetting the generation on the block group
    inode, this way we only ever have valid or invalid cache.
    
    With this patch I was no longer able to reproduce cache corruption with
    dm-log-writes and my bpf error injection tool.
    
    Signed-off-by: Josef Bacik <jbacik@fb.com>
    Signed-off-by: David Sterba <dsterba@suse.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit be75ad849b9f3b0512e976a81e31a0beea1419ab
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Wed Nov 29 16:11:30 2017 -0800

    mm/hugetlb: fix NULL-pointer dereference on 5-level paging machine
    
    commit f4f0a3d85b50a65a348e2b8635041d6b30f01deb upstream.
    
    I made a mistake during converting hugetlb code to 5-level paging: in
    huge_pte_alloc() we have to use p4d_alloc(), not p4d_offset().
    
    Otherwise it leads to crash -- NULL-pointer dereference in pud_alloc()
    if p4d table is not yet allocated.
    
    It only can happen in 5-level paging mode.  In 4-level paging mode
    p4d_offset() always returns pgd, so we are fine.
    
    Link: http://lkml.kernel.org/r/20171122121921.64822-1-kirill.shutemov@linux.intel.com
    Fixes: c2febafc6773 ("mm: convert generic code to 5-level paging")
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit f354f4ffe6a371a4ae27a682cea56a7e4e1d74d9
Author: Ian Kent <raven@themaw.net>
Date:   Wed Nov 29 16:11:26 2017 -0800

    autofs: revert "autofs: fix AT_NO_AUTOMOUNT not being honored"
    
    commit 5d38f049cee1e1c4a7ac55aa79d37d01ddcc3860 upstream.
    
    Commit 42f461482178 ("autofs: fix AT_NO_AUTOMOUNT not being honored")
    allowed the fstatat(2) system call to properly honor the AT_NO_AUTOMOUNT
    flag but introduced a semantic change.
    
    In order to honor AT_NO_AUTOMOUNT a semantic change was made to the
    negative dentry case for stat family system calls in follow_automount().
    
    This changed the unconditional triggering of an automount in this case
    to no longer be done and an error returned instead.
    
    This has caused more problems than I expected so reverting the change is
    needed.
    
    In a discussion with Neil Brown it was concluded that the automount(8)
    daemon can implement this change without kernel modifications.  So that
    will be done instead and the autofs module documentation updated with a
    description of the problem and what needs to be done by module users for
    this specific case.
    
    Link: http://lkml.kernel.org/r/151174730120.6162.3848002191530283984.stgit@pluto.themaw.net
    Fixes: 42f4614821 ("autofs: fix AT_NO_AUTOMOUNT not being honored")
    Signed-off-by: Ian Kent <raven@themaw.net>
    Cc: Neil Brown <neilb@suse.com>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Colin Walters <walters@redhat.com>
    Cc: Ondrej Holy <oholy@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 793a07bef9eb557ebad28cdf9ca30ba41d082c9f
Author: Ian Kent <raven@themaw.net>
Date:   Wed Nov 29 16:11:23 2017 -0800

    autofs: revert "autofs: take more care to not update last_used on path walk"
    
    commit 43694d4bf843ddd34519e8e9de983deefeada699 upstream.
    
    While commit 092a53452bb7 ("autofs: take more care to not update
    last_used on path walk") helped (partially) resolve a problem where
    automounts were not expiring due to aggressive accesses from user space
    it has a side effect for very large environments.
    
    This change helps with the expire problem by making the expire more
    aggressive but, for very large environments, that means more mount
    requests from clients.  When there are a lot of clients that can mean
    fairly significant server load increases.
    
    It turns out I put the last_used in this position to solve this very
    problem and failed to update my own thinking of the autofs expire
    policy.  So the patch being reverted introduces a regression which
    should be fixed.
    
    Link: http://lkml.kernel.org/r/151174729420.6162.1832622523537052460.stgit@pluto.themaw.net
    Fixes: 092a53452b ("autofs: take more care to not update last_used on path walk")
    Signed-off-by: Ian Kent <raven@themaw.net>
    Reviewed-by: NeilBrown <neilb@suse.com>
    Cc: Al Viro <viro@ZenIV.linux.org.uk>
    Cc: Colin Walters <walters@redhat.com>
    Cc: David Howells <dhowells@redhat.com>
    Cc: Ondrej Holy <oholy@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit fa2a9894733bdeaa93c750735b7fdc581ef10024
Author: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Date:   Wed Nov 29 16:11:19 2017 -0800

    fs/fat/inode.c: fix sb_rdonly() change
    
    commit b6e8e12c0aeb5fbf1bf46c84d58cc93aedede385 upstream.
    
    Commit bc98a42c1f7d ("VFS: Convert sb->s_flags & MS_RDONLY to
    sb_rdonly(sb)") converted fat_remount():new_rdonly from a bool to an
    int.
    
    However fat_remount() depends upon the compiler's conversion of a
    non-zero integer into boolean `true'.
    
    Fix it by switching `new_rdonly' back into a bool.
    
    Link: http://lkml.kernel.org/r/87mv3d5x51.fsf@mail.parknet.co.jp
    Fixes: bc98a42c1f7d0f8 ("VFS: Convert sb->s_flags & MS_RDONLY to sb_rdonly(sb)")
    Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Cc: Joe Perches <joe@perches.com>
    Cc: David Howells <dhowells@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit d983b6251c5535b5c5eb02ce48bf8eeb7417ef65
Author: Shakeel Butt <shakeelb@google.com>
Date:   Wed Nov 29 16:11:15 2017 -0800

    mm, memcg: fix mem_cgroup_swapout() for THPs
    
    commit d08afa149acfd00871484ada6dabc3880524cd1c upstream.
    
    Commit d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout()
    support THP") changed mem_cgroup_swapout() to support transparent huge
    page (THP).
    
    However the patch missed one location which should be changed for
    correctly handling THPs.  The resulting bug will cause the memory
    cgroups whose THPs were swapped out to become zombies on deletion.
    
    Link: http://lkml.kernel.org/r/20171128161941.20931-1-shakeelb@google.com
    Fixes: d6810d730022 ("memcg, THP, swap: make mem_cgroup_swapout() support THP")
    Signed-off-by: Shakeel Butt <shakeelb@google.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Huang Ying <ying.huang@intel.com>
    Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
    Cc: Greg Thelen <gthelen@google.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

commit 13167cf417ddf105d2822eebe775547ed35d1a08
Author: Zi Yan <zi.yan@cs.rutgers.edu>
Date:   Wed Nov 29 16:11:12 2017 -0800

    mm: migrate: fix an incorrect call of prep_transhuge_page()
    
    commit 40a899ed16486455f964e46d1af31fd4fded21c1 upstream.
    
    In https://lkml.org/lkml/2017/11/20/411, Andrea reported that during
    memory hotplug/hot remove prep_transhuge_page() is called incorrectly on
    non-THP pages for migration, when THP is on but THP migration is not
    enabled.  This leads to a bad state of target pages for migration.
    
    By inspecting the code, if called on a non-THP, prep_transhuge_page()
    will
    
     1) change the value of the mapping of (page + 2), since it is used for
        THP deferred list;
    
     2) change the lru value of (page + 1), since it is used for THP's dtor.
    
    Both can lead to data corruption of these two pages.
    
    Andrea said:
     "Pragmatically and from the point of view of the memory_hotplug subsys,
      the effect is a kernel crash when pages are being migrated during a
      memory hot remove offline and migration target pages are found in a
      bad state"
    
    This patch fixes it by only calling prep_transhuge_page() when we are
    certain that the target page is THP.
    
    Link: http://lkml.kernel.org/r/20171121021855.50525-1-zi.yan@sent.com
    Fixes: 8135d8926c08 ("mm: memory_hotplug: memory hotremove supports thp migration")
    Signed-off-by: Zi Yan <zi.yan@cs.rutgers.edu>
    Reported-by: Andrea Reale <ar@linux.vnet.ibm.com>
    Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
    Cc: Michal Hocko <mhocko@kernel.org>
    Cc: "Jérôme Glisse" <jglisse@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8a0bb9ebaa8b8faee61f095757662fe5d7fd8da6
Author: chenjie <chenjie6@huawei.com>
Date:   Wed Nov 29 16:10:54 2017 -0800

    mm/madvise.c: fix madvise() infinite loop under special circumstances
    
    commit 6ea8d958a2c95a1d514015d4e29ba21a8c0a1a91 upstream.
    
    MADVISE_WILLNEED has always been a noop for DAX (formerly XIP) mappings.
    Unfortunately madvise_willneed() doesn't communicate this information
    properly to the generic madvise syscall implementation.  The calling
    convention is quite subtle there.  madvise_vma() is supposed to either
    return an error or update &prev otherwise the main loop will never
    advance to the next vma and it will keep looping for ever without a way
    to get out of the kernel.
    
    It seems this has been broken since introduction.  Nobody has noticed
    because nobody seems to be using MADVISE_WILLNEED on these DAX mappings.
    
    [mhocko@suse.com: rewrite changelog]
    Link: http://lkml.kernel.org/r/20171127115318.911-1-guoxuenan@huawei.com
    Fixes: fe77ba6f4f97 ("[PATCH] xip: madvice/fadvice: execute in place")
    Signed-off-by: chenjie <chenjie6@huawei.com>
    Signed-off-by: guoxuenan <guoxuenan@huawei.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: zhangyi (F) <yi.zhang@huawei.com>
    Cc: Miao Xie <miaoxie@huawei.com>
    Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
    Cc: Shaohua Li <shli@fb.com>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Cc: Mel Gorman <mgorman@techsingularity.net>
    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: David Rientjes <rientjes@google.com>
    Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Carsten Otte <cotte@de.ibm.com>
    Cc: Dan Williams <dan.j.williams@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c16a65582a72d3adea145b9b0a737c6c35ce89fc
Author: Kees Cook <keescook@chromium.org>
Date:   Wed Nov 29 16:10:51 2017 -0800

    exec: avoid RLIMIT_STACK races with prlimit()
    
    commit 04e35f4495dd560db30c25efca4eecae8ec8c375 upstream.
    
    While the defense-in-depth RLIMIT_STACK limit on setuid processes was
    protected against races from other threads calling setrlimit(), I missed
    protecting it against races from external processes calling prlimit().
    This adds locking around the change and makes sure that rlim_max is set
    too.
    
    Link: http://lkml.kernel.org/r/20171127193457.GA11348@beast
    Fixes: 64701dee4178e ("exec: Use sane stack rlimit under secureexec")
    Signed-off-by: Kees Cook <keescook@chromium.org>
    Reported-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
    Reported-by: Brad Spengler <spender@grsecurity.net>
    Acked-by: Serge Hallyn <serge@hallyn.com>
    Cc: James Morris <james.l.morris@oracle.com>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Jiri Slaby <jslaby@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit aab681eb8f3bfe2950c8493f39cef6ae34b731b3
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Nov 29 16:10:47 2017 -0800

    IB/core: disable memory registration of filesystem-dax vmas
    
    commit 5f1d43de54164dcfb9bfa542fcc92c1e1a1b6c1d upstream.
    
    Until there is a solution to the dma-to-dax vs truncate problem it is
    not safe to allow RDMA to create long standing memory registrations
    against filesytem-dax vmas.
    
    Link: http://lkml.kernel.org/r/151068941011.7446.7766030590347262502.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reported-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Acked-by: Jason Gunthorpe <jgg@mellanox.com>
    Acked-by: Doug Ledford <dledford@redhat.com>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Inki Dae <inki.dae@samsung.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Joonyoung Shim <jy0922.shim@samsung.com>
    Cc: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e13ee3368ee1cbf4d2a9a70af20cdf519fd8bb3c
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Nov 29 16:10:43 2017 -0800

    v4l2: disable filesystem-dax mapping support
    
    commit b70131de648c2b997d22f4653934438013f407a1 upstream.
    
    V4L2 memory registrations are incompatible with filesystem-dax that
    needs the ability to revoke dma access to a mapping at will, or
    otherwise allow the kernel to wait for completion of DMA.  The
    filesystem-dax implementation breaks the traditional solution of
    truncate of active file backed mappings since there is no page-cache
    page we can orphan to sustain ongoing DMA.
    
    If v4l2 wants to support long lived DMA mappings it needs to arrange to
    hold a file lease or use some other mechanism so that the kernel can
    coordinate revoking DMA access when the filesystem needs to truncate
    mappings.
    
    Link: http://lkml.kernel.org/r/151068940499.7446.12846708245365671207.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reported-by: Jan Kara <jack@suse.cz>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Doug Ledford <dledford@redhat.com>
    Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
    Cc: Inki Dae <inki.dae@samsung.com>
    Cc: Jason Gunthorpe <jgg@mellanox.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Joonyoung Shim <jy0922.shim@samsung.com>
    Cc: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit daac045736edf0e4ec21d7b39b3633537246f9c8
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Nov 29 16:10:39 2017 -0800

    mm: fail get_vaddr_frames() for filesystem-dax mappings
    
    commit b7f0554a56f21fb3e636a627450a9add030889be upstream.
    
    Until there is a solution to the dma-to-dax vs truncate problem it is
    not safe to allow V4L2, Exynos, and other frame vector users to create
    long standing / irrevocable memory registrations against filesytem-dax
    vmas.
    
    [dan.j.williams@intel.com: add comment for vma_is_fsdax() check in get_vaddr_frames(), per Jan]
      Link: http://lkml.kernel.org/r/151197874035.26211.4061781453123083667.stgit@dwillia2-desk3.amr.corp.intel.com
    Link: http://lkml.kernel.org/r/151068939985.7446.15684639617389154187.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Jan Kara <jack@suse.cz>
    Cc: Inki Dae <inki.dae@samsung.com>
    Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
    Cc: Joonyoung Shim <jy0922.shim@samsung.com>
    Cc: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Doug Ledford <dledford@redhat.com>
    Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
    Cc: Jason Gunthorpe <jgg@mellanox.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 40aa9d2998ca55d9011e75a0fa526ed52e0a4bce
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Nov 29 16:10:35 2017 -0800

    mm: introduce get_user_pages_longterm
    
    commit 2bb6d2837083de722bfdc369cb0d76ce188dd9b4 upstream.
    
    Patch series "introduce get_user_pages_longterm()", v2.
    
    Here is a new get_user_pages api for cases where a driver intends to
    keep an elevated page count indefinitely.  This is distinct from usages
    like iov_iter_get_pages where the elevated page counts are transient.
    The iov_iter_get_pages cases immediately turn around and submit the
    pages to a device driver which will put_page when the i/o operation
    completes (under kernel control).
    
    In the longterm case userspace is responsible for dropping the page
    reference at some undefined point in the future.  This is untenable for
    filesystem-dax case where the filesystem is in control of the lifetime
    of the block / page and needs reasonable limits on how long it can wait
    for pages in a mapping to become idle.
    
    Fixing filesystems to actually wait for dax pages to be idle before
    blocks from a truncate/hole-punch operation are repurposed is saved for
    a later patch series.
    
    Also, allowing longterm registration of dax mappings is a future patch
    series that introduces a "map with lease" semantic where the kernel can
    revoke a lease and force userspace to drop its page references.
    
    I have also tagged these for -stable to purposely break cases that might
    assume that longterm memory registrations for filesystem-dax mappings
    were supported by the kernel.  The behavior regression this policy
    change implies is one of the reasons we maintain the "dax enabled.
    Warning: EXPERIMENTAL, use at your own risk" notification when mounting
    a filesystem in dax mode.
    
    It is worth noting the device-dax interface does not suffer the same
    constraints since it does not support file space management operations
    like hole-punch.
    
    This patch (of 4):
    
    Until there is a solution to the dma-to-dax vs truncate problem it is
    not safe to allow long standing memory registrations against
    filesytem-dax vmas.  Device-dax vmas do not have this problem and are
    explicitly allowed.
    
    This is temporary until a "memory registration with layout-lease"
    mechanism can be implemented for the affected sub-systems (RDMA and
    V4L2).
    
    [akpm@linux-foundation.org: use kcalloc()]
    Link: http://lkml.kernel.org/r/151068939435.7446.13560129395419350737.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Suggested-by: Christoph Hellwig <hch@lst.de>
    Cc: Doug Ledford <dledford@redhat.com>
    Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
    Cc: Inki Dae <inki.dae@samsung.com>
    Cc: Jan Kara <jack@suse.cz>
    Cc: Jason Gunthorpe <jgg@mellanox.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Cc: Joonyoung Shim <jy0922.shim@samsung.com>
    Cc: Kyungmin Park <kyungmin.park@samsung.com>
    Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Sean Hefty <sean.hefty@intel.com>
    Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
    Cc: Vlastimil Babka <vbabka@suse.cz>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 61586a2286140935fe711b3410c53ee1141633b2
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Nov 29 16:10:32 2017 -0800

    device-dax: implement ->split() to catch invalid munmap attempts
    
    commit 9702cffdbf2129516db679e4467db81e1cd287da upstream.
    
    Similar to how device-dax enforces that the 'address', 'offset', and
    'len' parameters to mmap() be aligned to the device's fundamental
    alignment, the same constraints apply to munmap().  Implement ->split()
    to fail munmap calls that violate the alignment constraint.
    
    Otherwise, we later fail VM_BUG_ON checks in the unmap_page_range() path
    with crash signatures of the form:
    
        vma ffff8800b60c8a88 start 00007f88c0000000 end 00007f88c0e00000
        next           (null) prev           (null) mm ffff8800b61150c0
        prot 8000000000000027 anon_vma           (null) vm_ops ffffffffa0091240
        pgoff 0 file ffff8800b638ef80 private_data           (null)
        flags: 0x380000fb(read|write|shared|mayread|maywrite|mayexec|mayshare|softdirty|mixedmap|hugepage)
        ------------[ cut here ]------------
        kernel BUG at mm/huge_memory.c:2014!
        [..]
        RIP: 0010:__split_huge_pud+0x12a/0x180
        [..]
        Call Trace:
         unmap_page_range+0x245/0xa40
         ? __vma_adjust+0x301/0x990
         unmap_vmas+0x4c/0xa0
         unmap_region+0xae/0x120
         ? __vma_rb_erase+0x11a/0x230
         do_munmap+0x276/0x410
         vm_munmap+0x6a/0xa0
         SyS_munmap+0x1d/0x30
    
    Link: http://lkml.kernel.org/r/151130418681.4029.7118245855057952010.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reported-by: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c6c78a1d4561880c744d3ec932264b264a879e7c
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Nov 29 16:10:28 2017 -0800

    mm, hugetlbfs: introduce ->split() to vm_operations_struct
    
    commit 31383c6865a578834dd953d9dbc88e6b19fe3997 upstream.
    
    Patch series "device-dax: fix unaligned munmap handling"
    
    When device-dax is operating in huge-page mode we want it to behave like
    hugetlbfs and fail attempts to split vmas into unaligned ranges.  It
    would be messy to teach the munmap path about device-dax alignment
    constraints in the same (hstate) way that hugetlbfs communicates this
    constraint.  Instead, these patches introduce a new ->split() vm
    operation.
    
    This patch (of 2):
    
    The device-dax interface has similar constraints as hugetlbfs in that it
    requires the munmap path to unmap in huge page aligned units.  Rather
    than add more custom vma handling code in __split_vma() introduce a new
    vm operation to perform this vma specific check.
    
    Link: http://lkml.kernel.org/r/151130418135.4029.6783191281930729710.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: dee410792419 ("/dev/dax, core: file operations and dax-mmap")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Cc: Jeff Moyer <jmoyer@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit bf55918cb4fb374000ad1d063b207a17a93e8726
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Nov 29 16:10:06 2017 -0800

    mm: fix device-dax pud write-faults triggered by get_user_pages()
    
    commit 1501899a898dfb5477c55534bdfd734c046da06d upstream.
    
    Currently only get_user_pages_fast() can safely handle the writable gup
    case due to its use of pud_access_permitted() to check whether the pud
    entry is writable.  In the gup slow path pud_write() is used instead of
    pud_access_permitted() and to date it has been unimplemented, just calls
    BUG_ON().
    
        kernel BUG at ./include/linux/hugetlb.h:244!
        [..]
        RIP: 0010:follow_devmap_pud+0x482/0x490
        [..]
        Call Trace:
         follow_page_mask+0x28c/0x6e0
         __get_user_pages+0xe4/0x6c0
         get_user_pages_unlocked+0x130/0x1b0
         get_user_pages_fast+0x89/0xb0
         iov_iter_get_pages_alloc+0x114/0x4a0
         nfs_direct_read_schedule_iovec+0xd2/0x350
         ? nfs_start_io_direct+0x63/0x70
         nfs_file_direct_read+0x1e0/0x250
         nfs_file_read+0x90/0xc0
    
    For now this just implements a simple check for the _PAGE_RW bit similar
    to pmd_write.  However, this implies that the gup-slow-path check is
    missing the extra checks that the gup-fast-path performs with
    pud_access_permitted.  Later patches will align all checks to use the
    'access_permitted' helper if the architecture provides it.
    
    Note that the generic 'access_permitted' helper fallback is the simple
    _PAGE_RW check on architectures that do not define the
    'access_permitted' helper(s).
    
    [dan.j.williams@intel.com: fix powerpc compile error]
      Link: http://lkml.kernel.org/r/151129126165.37405.16031785266675461397.stgit@dwillia2-desk3.amr.corp.intel.com
    Link: http://lkml.kernel.org/r/151043109938.2842.14834662818213616199.stgit@dwillia2-desk3.amr.corp.intel.com
    Fixes: a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent hugepages")
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Acked-by: Thomas Gleixner <tglx@linutronix.de>  [x86]
    Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: "David S. Miller" <davem@davemloft.net>
    Cc: Dave Hansen <dave.hansen@intel.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b4c8fce668423c0dde23fe57682e5bd8df5bbeb9
Author: Mike Kravetz <mike.kravetz@oracle.com>
Date:   Wed Nov 29 16:10:01 2017 -0800

    mm/cma: fix alloc_contig_range ret code/potential leak
    
    commit 63cd448908b5eb51d84c52f02b31b9b4ccd1cb5a upstream.
    
    If the call __alloc_contig_migrate_range() in alloc_contig_range returns
    -EBUSY, processing continues so that test_pages_isolated() is called
    where there is a tracepoint to identify the busy pages.  However, it is
    possible for busy pages to become available between the calls to these
    two routines.  In this case, the range of pages may be allocated.
    Unfortunately, the original return code (ret == -EBUSY) is still set and
    returned to the caller.  Therefore, the caller believes the pages were
    not allocated and they are leaked.
    
    Update the comment to indicate that allocation is still possible even if
    __alloc_contig_migrate_range returns -EBUSY.  Also, clear return code in
    this case so that it is not accidentally used or returned to caller.
    
    Link: http://lkml.kernel.org/r/20171122185214.25285-1-mike.kravetz@oracle.com
    Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure")
    Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
    Acked-by: Vlastimil Babka <vbabka@suse.cz>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: Johannes Weiner <hannes@cmpxchg.org>
    Acked-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
    Cc: Michal Nazarewicz <mina86@mina86.com>
    Cc: Laura Abbott <labbott@redhat.com>
    Cc: Michal Hocko <mhocko@suse.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>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 01ca9727457a167463a47e35b6fe5a5173b4e341
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Mon Nov 27 06:21:25 2017 +0300

    mm, thp: Do not make page table dirty unconditionally in touch_p[mu]d()
    
    commit a8f97366452ed491d13cf1e44241bc0b5740b1f0 upstream.
    
    Currently, we unconditionally make page table dirty in touch_pmd().
    It may result in false-positive can_follow_write_pmd().
    
    We may avoid the situation, if we would only make the page table entry
    dirty if caller asks for write access -- FOLL_WRITE.
    
    The patch also changes touch_pud() in the same way.
    
    Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
    Cc: Michal Hocko <mhocko@suse.com>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 786b924d39bad16ff99aacdb4076df027cc2f8b8
Author: Wang Nan <wangnan0@huawei.com>
Date:   Wed Nov 29 16:09:58 2017 -0800

    mm, oom_reaper: gather each vma to prevent leaking TLB entry
    
    commit 687cb0884a714ff484d038e9190edc874edcf146 upstream.
    
    tlb_gather_mmu(&tlb, mm, 0, -1) means gathering the whole virtual memory
    space.  In this case, tlb->fullmm is true.  Some archs like arm64
    doesn't flush TLB when tlb->fullmm is true:
    
      commit 5a7862e83000 ("arm64: tlbflush: avoid flushing when fullmm == 1").
    
    Which causes leaking of tlb entries.
    
    Will clarifies his patch:
     "Basically, we tag each address space with an ASID (PCID on x86) which
      is resident in the TLB. This means we can elide TLB invalidation when
      pulling down a full mm because we won't ever assign that ASID to
      another mm without doing TLB invalidation elsewhere (which actually
      just nukes the whole TLB).
    
      I think that means that we could potentially not fault on a kernel
      uaccess, because we could hit in the TLB"
    
    There could be a window between complete_signal() sending IPI to other
    cores and all threads sharing this mm are really kicked off from cores.
    In this window, the oom reaper may calls tlb_flush_mmu_tlbonly() to
    flush TLB then frees pages.  However, due to the above problem, the TLB
    entries are not really flushed on arm64.  Other threads are possible to
    access these pages through TLB entries.  Moreover, a copy_to_user() can
    also write to these pages without generating page fault, causes
    use-after-free bugs.
    
    This patch gathers each vma instead of gathering full vm space.  In this
    case tlb->fullmm is not true.  The behavior of oom reaper become similar
    to munmapping before do_exit, which should be safe for all archs.
    
    Link: http://lkml.kernel.org/r/20171107095453.179940-1-wangnan0@huawei.com
    Fixes: aac453635549 ("mm, oom: introduce oom reaper")
    Signed-off-by: Wang Nan <wangnan0@huawei.com>
    Acked-by: Michal Hocko <mhocko@suse.com>
    Acked-by: David Rientjes <rientjes@google.com>
    Cc: Minchan Kim <minchan@kernel.org>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Bob Liu <liubo95@huawei.com>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Roman Gushchin <guro@fb.com>
    Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
    Cc: Andrea Arcangeli <aarcange@redhat.com>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b8d0c953d928fbdc3207f741a2b77055d34fd0b9
Author: Michal Hocko <mhocko@suse.com>
Date:   Wed Nov 29 16:09:54 2017 -0800

    mm, memory_hotplug: do not back off draining pcp free pages from kworker context
    
    commit 4b81cb2ff69c8a8e297a147d2eb4d9b5e8d7c435 upstream.
    
    drain_all_pages backs off when called from a kworker context since
    commit 0ccce3b92421 ("mm, page_alloc: drain per-cpu pages from workqueue
    context") because the original IPI based pcp draining has been replaced
    by a WQ based one and the check wanted to prevent from recursion and
    inter workers dependencies.  This has made some sense at the time
    because the system WQ has been used and one worker holding the lock
    could be blocked while waiting for new workers to emerge which can be a
    problem under OOM conditions.
    
    Since then commit ce612879ddc7 ("mm: move pcp and lru-pcp draining into
    single wq") has moved draining to a dedicated (mm_percpu_wq) WQ with a
    rescuer so we shouldn't depend on any other WQ activity to make a
    forward progress so calling drain_all_pages from a worker context is
    safe as long as this doesn't happen from mm_percpu_wq itself which is
    not the case because all workers are required to _not_ depend on any MM
    locks.
    
    Why is this a problem in the first place? ACPI driven memory hot-remove
    (acpi_device_hotplug) is executed from the worker context.  We end up
    calling __offline_pages to free all the pages and that requires both
    lru_add_drain_all_cpuslocked and drain_all_pages to do their job
    otherwise we can have dangling pages on pcp lists and fail the offline
    operation (__test_page_isolated_in_pageblock would see a page with 0 ref
    count but without PageBuddy set).
    
    Fix the issue by removing the worker check in drain_all_pages.
    lru_add_drain_all_cpuslocked doesn't have this restriction so it works
    as expected.
    
    Link: http://lkml.kernel.org/r/20170828093341.26341-1-mhocko@kernel.org
    Fixes: 0ccce3b924212 ("mm, page_alloc: drain per-cpu pages from workqueue context")
    Signed-off-by: Michal Hocko <mhocko@suse.com>
    Cc: Mel Gorman <mgorman@suse.de>
    Cc: Tejun Heo <tj@kernel.org>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 2cbd866dd858ceebe2b735e3d8cd8eb702ca1f88
Author: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Date:   Fri Nov 3 03:01:53 2017 +0100

    platform/x86: hp-wmi: Fix tablet mode detection for convertibles
    
    commit 9968e12a291e639dd51d1218b694d440b22a917f upstream.
    
    Commit f9cf3b2880cc ("platform/x86: hp-wmi: Refactor dock and tablet
    state fetchers") consolidated the methods for docking and laptop mode
    detection, but omitted to apply the correct mask for the laptop mode
    (it always uses the constant for docking).
    
    Fixes: f9cf3b2880cc ("platform/x86: hp-wmi: Refactor dock and tablet state fetchers")
    Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
    Cc: Michel Dänzer <michel@daenzer.net>
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>