1. 30 Apr, 2018 1 commit
  2. 24 Apr, 2018 5 commits
  3. 12 Apr, 2018 1 commit
    • Philippe Gerum's avatar
      ipipe: add cpuidle control interface · 6c821c8f
      Philippe Gerum authored
      The co-kernel hook which should determine whether entering a sleep
      state is accepted is renamed to ipipe_cpuidle_control(), now receiving
      the cpuidle device and state information for enabling a smarter logic
      on the client side.
      
      ipipe_enter_idle_hook() that might be implemented by co-kernels
      conforming to the older interface won't be called anymore, which
      defaults to accepting the transition to idle
      unconditionally. Disabling CONFIG_CPU_IDLE or passing idle=poll would
      restore the original behavior, which is still the current
      recommendation to Xenomai users anyway.
      6c821c8f
  4. 27 Mar, 2018 1 commit
  5. 26 Mar, 2018 1 commit
  6. 05 Feb, 2018 8 commits
  7. 09 Dec, 2017 6 commits
  8. 05 Dec, 2017 17 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.14.4 · 51a2a68f
      Greg Kroah-Hartman authored
      51a2a68f
    • Greg Kroah-Hartman's avatar
      Revert "x86/entry/64: Add missing irqflags tracing to native_load_gs_index()" · e49d722f
      Greg Kroah-Hartman authored
      This reverts commit f9a64e23 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: default avatarAndy 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: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e49d722f
    • Ville Syrjälä's avatar
      drm/i915: Prevent zero length "index" write · 88e1bb2a
      Ville Syrjälä authored
      commit 56350fb8 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: 56f9eac0 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit bb9e0d4b)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88e1bb2a
    • Ville Syrjälä's avatar
      drm/i915: Don't try indexed reads to alternate slave addresses · e522b924
      Ville Syrjälä authored
      commit ae5c631e 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: 56f9eac0 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit c4deb62d)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e522b924
    • Xiong Zhang's avatar
      drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition · 6c0d3d1d
      Xiong Zhang authored
      commit b721b65a 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: 2707e444("drm/i915/gvt: vGPU graphics memory virtualization")
      Signed-off-by: default avatarXiong Zhang <xiong.y.zhang@intel.com>
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c0d3d1d
    • Chris Wilson's avatar
      drm/i915/fbdev: Serialise early hotplug events with async fbdev config · 7042c2b9
      Chris Wilson authored
      commit a45b30a6 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 934458c2
      ("Revert "drm/i915: Fix races on fbdev""), but the use after free is much
      older, commit 366e39b4 ("drm/i915: Tear down fbdev if initialization
      fails")
      
      Fixes: 366e39b4 ("drm/i915: Tear down fbdev if initialization fails")
      Fixes: 934458c2 ("Revert "drm/i915: Fix races on fbdev"")
      Signed-off-by: default avatarChris 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: default avatarLukas Wunner <lukas@wunner.de>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@chris-wilson.co.uk
      (cherry picked from commit ad88d7fc)
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7042c2b9
    • Hans de Goede's avatar
      drm/i915: Re-register PMIC bus access notifier on runtime resume · 569e3d1d
      Hans de Goede authored
      commit 294cf1af 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: default avatarImre Deak <imre.deak@intel.com>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoede@redhat.com
      (cherry picked from commit bedf4d79)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      569e3d1d
    • Hans de Goede's avatar
      drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2 · 6613dc72
      Hans de Goede authored
      commit f4359ced 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: default avatarFKr <bugs-freedesktop@ubermail.me>
      Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoede@redhat.com
      (cherry picked from commit ce30560c)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6613dc72
    • NeilBrown's avatar
      md: forbid a RAID5 from having both a bitmap and a journal. · a6793684
      NeilBrown authored
      commit 230b55fa 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: default avatarNeilBrown <neilb@suse.com>
      Tested-by: default avatarJoshua Kinard <kumba@gentoo.org>
      Acked-by: default avatarJoshua Kinard <kumba@gentoo.org>
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a6793684
    • Sasha Neftin's avatar
      e1000e: fix the use of magic numbers for buffer overrun issue · 635526b8
      Sasha Neftin authored
      commit c0f4b163 upstream.
      
      This is a follow on to commit b10effb9 ("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: default avatarSasha Neftin <sasha.neftin@intel.com>
      Reviewed-by: default avatarAlexander H Duyck <alexander.h.duyck@intel.com>
      Reviewed-by: default avatarDima Ruinskiy <dima.ruinskiy@intel.com>
      Reviewed-by: default avatarRaanan Avargil <raanan.avargil@intel.com>
      Tested-by: default avatarAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: default avatarJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      635526b8
    • Don Hiatt's avatar
      IB/hfi1: Do not warn on lid conversions for OPA · c48f3c04
      Don Hiatt authored
      commit 4988be58 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: 62ede777 ("Add OPA extended LID support")
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarDon Hiatt <don.hiatt@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c48f3c04
    • Don Hiatt's avatar
      IB/core: Do not warn on lid conversions for OPA · 2b24fdca
      Don Hiatt authored
      commit 6588e412 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: 62ede777 ("Add OPA extended LID support")
      Reviewed-by: default avatarMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: default avatarDon Hiatt <don.hiatt@intel.com>
      Signed-off-by: default avatarDennis Dalessandro <dennis.dalessandro@intel.com>
      Reviewed-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b24fdca
    • Sandipan Das's avatar
      include/linux/compiler-clang.h: handle randomizable anonymous structs · 75e63076
      Sandipan Das authored
      commit 4ca59b14 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.comSigned-off-by: default avatarSandipan 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      75e63076
    • Michel Dänzer's avatar
      drm/amdgpu: Set adev->vcn.irq.num_types for VCN · 248b0ec5
      Michel Dänzer authored
      commit 89ce6e0a upstream.
      
      We were setting adev->uvd.irq.num_types instead.
      
      Fixes: 9b257116 ("drm/amdgpu: add vcn enc irq support")
      Reviewed-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      248b0ec5
    • Leo Liu's avatar
      drm/amdgpu: move UVD/VCE and VCN structure out from union · 802328da
      Leo Liu authored
      commit b43aaee6 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: default avatarLeo Liu <leo.liu@amd.com>
      Acked-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Fixes: 95d0906f ("drm/amdgpu: add initial vcn support and decode tests")
      Reviewed-and-Tested-by: default avatarMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      802328da
    • Ville Syrjälä's avatar
      drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks · d8f74d70
      Ville Syrjälä authored
      commit 9271c0ca 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: default avatarNeil Kownacki <njkkow@gmail.com>
      Tested-by: default avatarNeil Kownacki <njkkow@gmail.com>
      Fixes: fcc8a22c ("drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101639Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171108152504.12596-1-ville.syrjala@linux.intel.comAcked-by: default avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d8f74d70
    • Laurent Pinchart's avatar
      drm/fsl-dcu: Don't set connector DPMS property · e685410c
      Laurent Pinchart authored
      commit daee5426 upstream.
      
      Since commit 4a97a3da ("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: 4a97a3da ("drm: Don't update property values for atomic drivers")
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e685410c