1. 28 4月, 2017 3 次提交
    • J
      drm/i915: Eliminate HAS_HW_CONTEXTS · f2e4d76e
      Joonas Lahtinen 提交于
      HAS_HW_CONTEXTS is misleading condition for GPU reset and CCID,
      replace it with Gen specific (to be updated in next patches).
      
      HAS_HW_CONTEXTS in i915_l3_write is bogus because each HAS_L3_DPF
      match also has .has_hw_contexts = 1 set.
      
      This leads to us being able to get rid of the property completely.
      
      v2:
      - Keep the checks at Gen6 for no functional change (Ville)
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      f2e4d76e
    • J
      drm/i915: Sanitize engine context sizes · 63ffbcda
      Joonas Lahtinen 提交于
      Pre-calculate engine context size based on engine class and device
      generation and store it in the engine instance.
      
      v2:
      - Squash and get rid of hw_context_size (Chris)
      
      v3:
      - Move after MMIO init for probing on Gen7 and 8 (Chris)
      - Retained rounding (Tvrtko)
      v4:
      - Rebase for deferred legacy context allocation
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Oscar Mateo <oscar.mateo@intel.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: intel-gvt-dev@lists.freedesktop.org
      Acked-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      63ffbcda
    • T
      drm/i915/guc: Fix sleep under spinlock during reset · a3662830
      Tvrtko Ursulin 提交于
      Looks like intel_guc_reset had the ability to sleep under the
      uncore spinlock since forever but it wasn't detected until the
      recent changes annotated the wait for register with might_sleep.
      
      I have fixed it by removing holding of the uncore spinlock over
      the call to gen6_hw_domain_reset, since I do not see that is
      really needed. But there is always a possibility I am missing
      some nasty detail so please double check.
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Oscar Mateo <oscar.mateo@intel.com>
      Acked-by: NMichel Thierry <michel.thierry@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      a3662830
  2. 27 4月, 2017 4 次提交
  3. 26 4月, 2017 1 次提交
  4. 25 4月, 2017 3 次提交
  5. 24 4月, 2017 1 次提交
  6. 22 4月, 2017 1 次提交
    • C
      drm/i915: Confirm the request is still active before adding it to the await · ade0b0c9
      Chris Wilson 提交于
      Although we do check the completion-status of the request before
      actually adding a wait on it (either to its submit fence or its
      completion dma-fence), we currently do not check before adding it to the
      dependency lists.
      
      In fact, without checking for a completed request we may try to use the
      signaler after it has been retired and its dependency tree freed:
      
      [   60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0
      [   60.044118] Read of size 8 by task gem_exec_fence/530
      [   60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G            E   4.11.0-rc7+ #46
      [   60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
      [   60.044290] Call Trace:
      [   60.044337]  dump_stack+0x4d/0x6a
      [   60.044383]  kasan_object_err+0x21/0x70
      [   60.044435]  kasan_report+0x225/0x4e0
      [   60.044488]  ? __list_add_valid+0x1d/0xd0
      [   60.044534]  ? kasan_kmalloc+0xad/0xe0
      [   60.044587]  __asan_load8+0x5e/0x70
      [   60.044639]  __list_add_valid+0x1d/0xd0
      [   60.044788]  __i915_priotree_add_dependency+0x67/0x130 [i915]
      [   60.044895]  i915_gem_request_await_request+0xa8/0x370 [i915]
      [   60.044974]  i915_gem_request_await_dma_fence+0x129/0x140 [i915]
      [   60.045049]  i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
      [   60.045077]  ? save_stack+0xb1/0xd0
      [   60.045105]  ? save_stack_trace+0x1b/0x20
      [   60.045132]  ? save_stack+0x46/0xd0
      [   60.045158]  ? kasan_kmalloc+0xad/0xe0
      [   60.045184]  ? __kmalloc+0xd8/0x670
      [   60.045229]  ? drm_ioctl+0x359/0x640 [drm]
      [   60.045256]  ? SyS_ioctl+0x41/0x70
      [   60.045330]  ? i915_vma_move_to_active+0x540/0x540 [i915]
      [   60.045360]  ? tty_insert_flip_string_flags+0xa1/0xf0
      [   60.045387]  ? tty_flip_buffer_push+0x63/0x70
      [   60.045414]  ? remove_wait_queue+0xa9/0xc0
      [   60.045441]  ? kasan_unpoison_shadow+0x35/0x50
      [   60.045467]  ? kasan_kmalloc+0xad/0xe0
      [   60.045494]  ? kasan_check_write+0x14/0x20
      [   60.045568]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
      [   60.045616]  drm_ioctl+0x359/0x640 [drm]
      [   60.045705]  ? i915_gem_execbuffer+0x5a0/0x5a0 [i915]
      [   60.045751]  ? drm_version+0x150/0x150 [drm]
      [   60.045778]  ? compat_start_thread+0x60/0x60
      [   60.045805]  ? plist_del+0xda/0x1a0
      [   60.045833]  do_vfs_ioctl+0x12e/0x910
      [   60.045860]  ? ioctl_preallocate+0x130/0x130
      [   60.045886]  ? pci_mmcfg_check_reserved+0xc0/0xc0
      [   60.045913]  ? vfs_write+0x196/0x240
      [   60.045939]  ? __fget_light+0xa7/0xc0
      [   60.045965]  SyS_ioctl+0x41/0x70
      [   60.045991]  entry_SYSCALL_64_fastpath+0x17/0x98
      [   60.046017] RIP: 0033:0x7feb2baefc47
      [   60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [   60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47
      [   60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003
      [   60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600
      [   60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469
      [   60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099
      [   60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64
      [   60.046225] Allocated:
      [   60.046246] PID = 530
      [   60.046269]  save_stack_trace+0x1b/0x20
      [   60.046292]  save_stack+0x46/0xd0
      [   60.046318]  kasan_kmalloc+0xad/0xe0
      [   60.046343]  kasan_slab_alloc+0x12/0x20
      [   60.046368]  kmem_cache_alloc+0xab/0x650
      [   60.046445]  i915_gem_request_await_request+0x88/0x370 [i915]
      [   60.046559]  i915_gem_request_await_dma_fence+0x129/0x140 [i915]
      [   60.046705]  i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
      [   60.046849]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
      [   60.046936]  drm_ioctl+0x359/0x640 [drm]
      [   60.046987]  do_vfs_ioctl+0x12e/0x910
      [   60.047038]  SyS_ioctl+0x41/0x70
      [   60.047090]  entry_SYSCALL_64_fastpath+0x17/0x98
      [   60.047139] Freed:
      [   60.047179] PID = 530
      [   60.047223]  save_stack_trace+0x1b/0x20
      [   60.047269]  save_stack+0x46/0xd0
      [   60.047317]  kasan_slab_free+0x72/0xc0
      [   60.047366]  kmem_cache_free+0x39/0x160
      [   60.047512]  i915_gem_request_retire+0x83f/0x930 [i915]
      [   60.047657]  i915_gem_request_alloc+0x166/0x600 [i915]
      [   60.047799]  i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915]
      [   60.047897]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
      [   60.047942]  drm_ioctl+0x359/0x640 [drm]
      [   60.047968]  do_vfs_ioctl+0x12e/0x910
      [   60.047993]  SyS_ioctl+0x41/0x70
      [   60.048019]  entry_SYSCALL_64_fastpath+0x17/0x98
      [   60.048044] Memory state around the buggy address:
      [   60.048066]  ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      [   60.048105]  ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      [   60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [   60.048170]                                ^
      [   60.048191]  ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      [   60.048225]  ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      
      Note to hit the use-after-free requires us to be passed back a request
      via a fence-array, that is from explicit fencing accumulated into a
      sync-file fence-array.
      
      Fixes: 52e54209 ("drm/i915/scheduler: Record all dependencies upon request construction")
      Testcase: igt/gem_exec_fence/expired-history
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk
      ade0b0c9
  7. 21 4月, 2017 2 次提交
    • C
      drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio · 3dd14c04
      Chris Wilson 提交于
      The busy-spin, as the first stage of intel_wait_for_register(), is
      currently under suspicion for causing:
      
      [   62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
      [   62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper prime_numbers
      [   62.034932] CPU: 1 PID: 183 Comm: kworker/1:2 Not tainted 4.11.0-rc7+ #471
      [   62.034933] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
      [   62.034934] Workqueue: pm pm_runtime_work
      [   62.034936] task: ffff880275a04ec0 task.stack: ffffc900002d8000
      [   62.034936] RIP: 0010:__intel_wait_for_register_fw+0x77/0x1a0 [i915]
      [   62.034937] RSP: 0018:ffffc900002dbc38 EFLAGS: 00000082
      [   62.034939] RAX: ffffc90003530094 RBX: 0000000000130094 RCX: 0000000000000001
      [   62.034940] RDX: 00000000000000a1 RSI: ffff88027fd15e58 RDI: 0000000000000000
      [   62.034941] RBP: ffffc900002dbc78 R08: 0000000000000002 R09: 0000000000000000
      [   62.034942] R10: ffffc900002dbc18 R11: ffff880276429dd0 R12: ffff8802707c0000
      [   62.034943] R13: 00000000000000a0 R14: 0000000000000000 R15: 00000000fffefc10
      [   62.034945] FS:  0000000000000000(0000) GS:ffff88027fd00000(0000) knlGS:0000000000000000
      [   62.034945] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   62.034947] CR2: 00007ffd3cd98ff8 CR3: 0000000274c19000 CR4: 00000000001006e0
      [   62.034947] Call Trace:
      [   62.034948]  intel_wait_for_register+0x77/0x140 [i915]
      [   62.034949]  vlv_suspend_complete+0x23/0x5b0 [i915]
      [   62.034950]  intel_runtime_suspend+0x16c/0x2a0 [i915]
      [   62.034950]  pci_pm_runtime_suspend+0x50/0x180
      [   62.034951]  ? pci_pm_runtime_resume+0xa0/0xa0
      [   62.034952]  __rpm_callback+0xc5/0x210
      [   62.034953]  rpm_callback+0x1f/0x80
      [   62.034953]  ? pci_pm_runtime_resume+0xa0/0xa0
      [   62.034954]  rpm_suspend+0x118/0x580
      [   62.034955]  pm_runtime_work+0x64/0x90
      [   62.034956]  process_one_work+0x1bb/0x3e0
      [   62.034956]  worker_thread+0x46/0x4f0
      [   62.034957]  ? __schedule+0x18b/0x610
      [   62.034958]  kthread+0xff/0x140
      [   62.034958]  ? process_one_work+0x3e0/0x3e0
      [   62.034959]  ? kthread_create_on_node+
      
      and related hard lockups in CI for byt and bsw.
      
      Note this effectively reverts commits 41ce405e and b2736695
      ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
      
      v2: Convert bool allow into a u32 mask for clarity and repeat the
      comment on vlv rc6 timing to justify the 3ms timeout used for the wait (Ville)
      
      Fixes: 41ce405e ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
      Fixes: b2736695 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100718Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.ukTested-by: NTomi Sarvela <tomi.p.sarvela@intel.com>
      3dd14c04
    • C
      drm/i915: Stop touching hangcheck.seqno from intel_engine_init_global_seqno() · 546cdbc7
      Chris Wilson 提交于
      The hangcheck runs independently to the main flow of seqno through the
      driver. However, we have an odd coupling of the seqno reset that is
      unwelcome, and if poked at just the right rate can cause spurious hangs
      (e.g. gem_exec_whisper) on an apparently idle engine.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170421083113.21321-1-chris@chris-wilson.co.uk
      546cdbc7
  8. 20 4月, 2017 2 次提交
  9. 19 4月, 2017 2 次提交
  10. 18 4月, 2017 2 次提交
  11. 15 4月, 2017 2 次提交
  12. 14 4月, 2017 2 次提交
    • D
      drm/i915: checking for NULL instead of IS_ERR() in mock selftests · be02f755
      Dan Carpenter 提交于
      i915_gem_request_alloc() uses error pointers.  It never returns NULLs.
      
      Fixes: 0daf0113 ("drm/i915: Mock infrastructure for request emission")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170413195217.GA26108@mwandaReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      be02f755
    • M
      drm/i915: Implement Link Rate fallback on Link training failure · 9301397a
      Manasi Navare 提交于
      If link training at a link rate optimal for a particular
      mode fails during modeset's atomic commit phase, then we
      let the modeset complete and then retry. We save the link rate
      value at which link training failed, update the link status property
      to "BAD" and use a lower link rate to prune the modes. It will redo
      the modeset on the current mode at lower link rate or if the current
      mode gets pruned due to lower link constraints then, it will send a
      hotplug uevent for userspace to handle it.
      
      This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
      4.3.1.6.
      
      This patch is a resend of the original commit id (233ce881
      "drm/i915: Implement Link Rate fallback on Link training failure")
      which got reverted in this commit id (afc1ebf4 Revert
      "drm/i915: Implement Link Rate fallback on Link training failure")
      due to CI failures.
      
      After investigating the CI failures it was found that these
      were essentially the failures which were always there but hidden because
      they used to be DRM_DEBUG_KMS messages for link failures so never got
      caught by CI. But now this patch actually throws DRM_ERROR if the link
      training fails at RBR and 1 lane. So it caught these link train failures.
      
      There were two failures:
      1. On SKL 6700k this was because the machine in CI lab is a SKL desktop
      without eDP on Port A. But our VBT initialization code in the driver writes
      VBT defaults in a way that it always sets DP flag on Port A and this does
      not get cleared after parsing the VBT outputs. This has been fixed in
      commit id (bb1d1329 "drm/i915/vbt: split out defaults that are set
      when there is no VBT) and (66578857 "drm/i915/vbt: don't propagate
      errors from intel_bios_init())
      
      2. On ILK-650 desktop - This was happening because of a bad monitor desktop
      combination. I switched the monitor in the CI lab and that helped get rid
      of the link failures on ILK system.
      
      v10:
      * Rebase on drm-tip and resend after revert
      v9:
      * Use the trimmed max values of link rate/lane count based on
      link train fallback (Daniel Vetter)
      v8:
      * Set link_status to BAD first and then call mode_valid (Jani Nikula)
      v7:
      Remove the redundant variable in previous patch itself
      v6:
      * Obtain link rate index from fallback_link_rate using
      the helper intel_dp_link_rate_index (Jani Nikula)
      * Include fallback within intel_dp_start_link_train (Jani Nikula)
      v5:
      * Move set link status to drm core (Daniel Vetter, Jani Nikula)
      v4:
      * Add fallback support for non DDI platforms too
      * Set connector->link status inside set_link_status function
      (Jani Nikula)
      v3:
      * Set link status property to BAd unconditionally (Jani Nikula)
      * Dont use two separate variables link_train_failed and link_status
      to indicate same thing (Jani Nikula)
      v2:
      * Squashed a few patches (Jani Nikula)
      Acked-by: NTony Cheng <tony.cheng@amd.com>
      Acked-by: NHarry Wentland <Harry.wentland@amd.com>
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@intel.com>
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
      Reviewed-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
      9301397a
  13. 13 4月, 2017 3 次提交
    • V
      drm/i915: Perform link quality check unconditionally during long pulse · 1a36147b
      Ville Syrjälä 提交于
      Apparently some DP sinks are a little nuts and cause HPD to drop
      intermittently during modesets. This happens eg. on an ASUS PB287Q.
      In oder to recover from this we can't really use the previous
      connector status to determine if the link needs retraining, so let's
      just ignore that piece of information and do the retrain
      unconditionally. We do of course still check whether the link is
      supposed to be running or not.
      
      To actually get read out the EDID and update things properly we
      also need to nuke the goto out added by commit 7d23e3c3
      ("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure
      why that was there. Perhaps to avoid an EDID read if the connector
      status didn't appear to change, but that sort of thing is quite racy
      and would have failed anyway if we failed to keep up with the
      hotplugs (if we missed the HPD down in between two HPD ups). And
      now that we take this codepath unconditionally we definitely need
      to drop the goto as otherwise we would never do the EDID read.
      
      v2: Drop the goto that made us skip EDID reads entirely. Doh!
      v3: Rebase due to locking changes
          s/apparely/apparently/ in the comment (Chris)
      
      Cc: stable@vger.kernel.org
      Cc: Manasi Navare <manasi.d.navare@intel.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Reported-by: NPalmer Dabbelt <palmer@dabbelt.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766
      References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.htmlSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
      1a36147b
    • D
      drm/i915/guc: write wopcm related register once during uc init · 13f6c719
      daniele.ceraolospurio@intel.com 提交于
      The wopcm registers are write-once, so any write after the first one
      will just be ignored. The registers survive a GPU reset but not
      always a suspend/resume cycle, so to keep things simple keep the
      writes in the intel_uc_init_hw function instead of moving it earlier
      to make sure we attempt them every time we try to load GuC.
      
      Cc: Jeff McGee <jeff.mcgee@intel.com>
      Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
      Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1491524332-23860-1-git-send-email-daniele.ceraolospurio@intel.com
      13f6c719
    • C
      drm/i915: Fix use after free in lpe_audio_platdev_destroy() · 48ae8074
      Chris Wilson 提交于
      [31908.547136] BUG: KASAN: use-after-free in intel_lpe_audio_teardown+0x78/0xb0 [i915] at addr ffff8801f7788358
      [31908.547297] Read of size 8 by task drv_selftest/3781
      [31908.547405] CPU: 0 PID: 3781 Comm: drv_selftest Tainted: G    BU  W       4.10.0+ #451
      [31908.547553] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
      [31908.547682] Call Trace:
      [31908.547772]  dump_stack+0x68/0x9f
      [31908.547857]  kasan_object_err+0x1c/0x70
      [31908.547947]  kasan_report_error+0x1f1/0x4f0
      [31908.548038]  ? kfree+0xaa/0x170
      [31908.548121]  kasan_report+0x34/0x40
      [31908.548211]  ? klist_children_get+0x20/0x30
      [31908.548472]  ? intel_lpe_audio_teardown+0x78/0xb0 [i915]
      [31908.548567]  __asan_load8+0x5e/0x70
      [31908.548824]  intel_lpe_audio_teardown+0x78/0xb0 [i915]
      [31908.549080]  intel_audio_deinit+0x28/0x80 [i915]
      [31908.549315]  i915_driver_unload+0xe4/0x360 [i915]
      [31908.549551]  ? i915_driver_load+0x1d70/0x1d70 [i915]
      [31908.549651]  ? trace_hardirqs_on+0xd/0x10
      [31908.549885]  i915_pci_remove+0x23/0x30 [i915]
      [31908.549978]  pci_device_remove+0x5c/0x100
      [31908.550069]  device_release_driver_internal+0x1db/0x2e0
      [31908.550165]  driver_detach+0x68/0xc0
      [31908.550256]  bus_remove_driver+0x8b/0x150
      [31908.550346]  driver_unregister+0x3e/0x60
      [31908.550439]  pci_unregister_driver+0x1d/0x110
      [31908.550531]  ? find_module_all+0x7a/0xa0
      [31908.550791]  i915_exit+0x1a/0x87 [i915]
      [31908.550881]  SyS_delete_module+0x264/0x2c0
      [31908.550971]  ? free_module+0x430/0x430
      [31908.551064]  ? trace_hardirqs_off_caller+0x16/0x110
      [31908.551159]  ? trace_hardirqs_on_caller+0x16/0x280
      [31908.551256]  ? trace_hardirqs_on_thunk+0x1a/0x1c
      [31908.551350]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [31908.551440] RIP: 0033:0x7f1d67312ec7
      [31908.551520] RSP: 002b:00007ffebe34e888 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
      [31908.551650] RAX: ffffffffffffffda RBX: ffffffff811123f6 RCX: 00007f1d67312ec7
      [31908.551743] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000560d0af476b8
      [31908.551837] RBP: ffff880233d87f98 R08: 0000000000000000 R09: 00007ffebe34e8b8
      [31908.551930] R10: 00007f1d68adf8c0 R11: 0000000000000206 R12: 0000000000000000
      [31908.552023] R13: 0000560d0af46440 R14: 0000000000000034 R15: 00007ffebe34d860
      [31908.552121]  ? trace_hardirqs_off_caller+0x16/0x110
      [31908.552217] Object at ffff8801f7788000, in cache kmalloc-2048 size: 2048
      [31908.552306] Allocated:
      [31908.552377] PID = 3781
      [31908.552456]  save_stack_trace+0x16/0x20
      [31908.552539]  kasan_kmalloc+0xee/0x190
      [31908.552627]  __kmalloc+0xdb/0x1b0
      [31908.552713]  platform_device_alloc+0x27/0x90
      [31908.552804]  platform_device_register_full+0x36/0x220
      [31908.553066]  intel_lpe_audio_init+0x41e/0x570 [i915]
      [31908.553320]  intel_audio_init+0xd/0x40 [i915]
      [31908.553552]  i915_driver_load+0x13f5/0x1d70 [i915]
      [31908.553788]  i915_pci_probe+0x65/0xe0 [i915]
      [31908.553881]  pci_device_probe+0xda/0x140
      [31908.553969]  driver_probe_device+0x400/0x660
      [31908.554058]  __driver_attach+0x11c/0x120
      [31908.554147]  bus_for_each_dev+0xe6/0x150
      [31908.554237]  driver_attach+0x26/0x30
      [31908.554325]  bus_add_driver+0x26b/0x3b0
      [31908.554412]  driver_register+0xce/0x190
      [31908.554502]  __pci_register_driver+0xaf/0xc0
      [31908.554589]  0xffffffffa0550063
      [31908.554675]  do_one_initcall+0x8b/0x1e0
      [31908.554764]  do_init_module+0x102/0x325
      [31908.554852]  load_module+0x3aad/0x45e0
      [31908.554944]  SyS_finit_module+0x169/0x1a0
      [31908.555033]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [31908.555119] Freed:
      [31908.555188] PID = 3781
      [31908.555266]  save_stack_trace+0x16/0x20
      [31908.555349]  kasan_slab_free+0xb0/0x180
      [31908.555436]  kfree+0xaa/0x170
      [31908.555520]  platform_device_release+0x76/0x80
      [31908.555610]  device_release+0x45/0xe0
      [31908.555698]  kobject_put+0x11f/0x260
      [31908.555785]  put_device+0x12/0x20
      [31908.555871]  platform_device_unregister+0x1b/0x20
      [31908.556135]  intel_lpe_audio_teardown+0x5c/0xb0 [i915]
      [31908.556390]  intel_audio_deinit+0x28/0x80 [i915]
      [31908.556622]  i915_driver_unload+0xe4/0x360 [i915]
      [31908.556858]  i915_pci_remove+0x23/0x30 [i915]
      [31908.556948]  pci_device_remove+0x5c/0x100
      [31908.557037]  device_release_driver_internal+0x1db/0x2e0
      [31908.557129]  driver_detach+0x68/0xc0
      [31908.557217]  bus_remove_driver+0x8b/0x150
      [31908.557304]  driver_unregister+0x3e/0x60
      [31908.557394]  pci_unregister_driver+0x1d/0x110
      [31908.557653]  i915_exit+0x1a/0x87 [i915]
      [31908.557741]  SyS_delete_module+0x264/0x2c0
      [31908.557834]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [31908.557919] Memory state around the buggy address:
      [31908.558005]  ffff8801f7788200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [31908.558127]  ffff8801f7788280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [31908.558255] >ffff8801f7788300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [31908.558374]                                                     ^
      [31908.558467]  ffff8801f7788380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      [31908.558595]  ffff8801f7788400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      
      v2: Just leak the memory (8 bytes) as freeing it ourselves is not safe,
      and we need to coordinate a proper fix in platform_device itself.
      
      Fixes: eef57324 ("drm/i915: setup bridge for HDMI LPE audio driver")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99952Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Cc: Jerome Anand <jerome.anand@intel.com>
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170412080251.30648-1-chris@chris-wilson.co.ukReviewed-by: NTakashi Iwai <tiwai@suse.de>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      48ae8074
  14. 12 4月, 2017 12 次提交