1. 28 Apr, 2017 29 commits
  2. 26 Apr, 2017 11 commits
    • Arnd Bergmann's avatar
      drm: mali-dp: use div_u64 for expensive 64-bit divisions · 763656d3
      Arnd Bergmann authored
      On 32-bit machines, we can't divide 64-bit integers:
      
      drivers/gpu/drm/arm/malidp_crtc.o: In function `malidp_crtc_atomic_check':
      malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3c0): undefined reference to `__aeabi_uldivmod'
      malidp_crtc.c:(.text.malidp_crtc_atomic_check+0x3dc): undefined reference to `__aeabi_uldivmod'
      
      This calls the div_u64 function explicitly instead.
      
      Fixes: 4cea4e9f6690 ("drm: mali-dp: Add plane upscaling support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      763656d3
    • Chris Wilson's avatar
      drm/i915: Confirm the request is still active before adding it to the await · 88326ef0
      Chris Wilson authored
      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: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMichał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: default avatarJoonas 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
      (cherry picked from commit ade0b0c9)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      88326ef0
    • Chris Wilson's avatar
      drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio · 96dabe99
      Chris Wilson authored
      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: default avatarChris 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: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.ukTested-by: default avatarTomi Sarvela <tomi.p.sarvela@intel.com>
      (cherry picked from commit 3dd14c04)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      96dabe99
    • Chris Wilson's avatar
      drm/i915/selftests: Allocate inode/file dynamically · b162d47e
      Chris Wilson authored
      Avoid having too large a stack by creating the fake struct inode/file on
      the heap instead.
      
      drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
      drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
      drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file_free':
      drivers/gpu/drm/i915/selftests/mock_drm.c:54:1: error: the frame size of 1312 bytes is larger than 1280 bytes [-Werror=frame-larger-than=]
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Fixes: 66d9cb5d ("drm/i915: Mock the GEM device for self-testing")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170419094143.16922-2-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit 2310b3c9)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      b162d47e
    • Mika Kuoppala's avatar
      drm/i915: Fix system hang with EI UP masked on Haswell · acf2dc22
      Mika Kuoppala authored
      Previously with commit a9c1f90c
      ("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain,
      seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed
      to be unmasked for IVB and SNB in order to prevent system hang
      with chained batchbuffers.
      
      Our CI was seeing incomplete results with tests that used
      chained batches and it was found out that HSW needs to have this
      same bit unmasked to reliably survive chained batches.
      
      Always unmask GEN6_PM_RP_UP_EI_EXPIRED on Haswell to
      prevent system hang with batch chaining.
      
      Testcase: igt/gem_exec_fence/nb-await-default
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100672
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Acked-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/1492082127-29007-1-git-send-email-mika.kuoppala@intel.com
      (cherry picked from commit 3396a273)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      acf2dc22
    • Dan Carpenter's avatar
      drm/i915: checking for NULL instead of IS_ERR() in mock selftests · 5af9e672
      Dan Carpenter authored
      i915_gem_request_alloc() uses error pointers.  It never returns NULLs.
      
      Fixes: 0daf0113 ("drm/i915: Mock infrastructure for request emission")
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170413195217.GA26108@mwandaReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      (cherry picked from commit be02f755)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      5af9e672
    • Ville Syrjälä's avatar
      drm/i915: Perform link quality check unconditionally during long pulse · dea65593
      Ville Syrjälä authored
      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: default avatarPalmer 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: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
      (cherry picked from commit 1a36147b)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      dea65593
    • Chris Wilson's avatar
      drm/i915: Fix use after free in lpe_audio_platdev_destroy() · dde7b00e
      Chris Wilson authored
      [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: default avatarChris 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: default avatarTakashi Iwai <tiwai@suse.de>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      (cherry picked from commit 48ae8074)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      dde7b00e
    • Chris Wilson's avatar
      drm/i915: Use the right mapping_gfp_mask for final shmem allocation · bdb57b8d
      Chris Wilson authored
      Many sightings report the greater prevalence of allocation failures.
      This is all due to the incorrect use of mapping_gfp_constraint(), so
      remove it in favour of just querying the mapping_gfp_mask() which are
      the exact gfp_t we wanted in the first place.
      
      We still do expect a higher chance of reporting ENOMEM, as that is the
      intention of using __GFP_NORETRY -- to fail rather than oom after having
      reclaimed from our bo caches, and having done a direct|kswapd reclaim
      pass.
      Reported-by: default avatarJason Ekstrand <jason.ekstrand@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100594
      Fixes: 24f8e00a ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170405221514.23251-1-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      (cherry picked from commit b268d9fe)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      bdb57b8d
    • Ville Syrjälä's avatar
      drm/i915: Make legacy cursor updates more unsynced · 440df938
      Ville Syrjälä authored
      We're clearing the legacy_cursor_update flag before calling
      drm_atomic_helper_setup_commit() which means the helper will
      wait for the flip to complete before cleaning up the framebuffers.
      That's not what we want for the legacy cursor, so let's clear
      the flag after setting up the commit.
      
      Also toss in a FIXME about solving these problems in a nicer
      way using the fabled vblank workers.
      
      v2: Also unsync with legacy page flips
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
      Cc: Rafael Ristovski <rafael.ristovski@gmail.com>
      Fixes: a5509abd ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170329142123.5923-1-ville.syrjala@linux.intel.comReviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      (cherry picked from commit 89520304)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      440df938
    • Chris Wilson's avatar
      drm/i915: Apply a cond_resched() to the saturated signaler · d445aaaa
      Chris Wilson authored
      If the engine is continually completing nops, we can saturate the
      signaler and keep it working indefinitely. This angers the NMI watchdog!
      
      A good example is to disable semaphores on snb and run igt/gem_exec_nop -
      the parallel, multi-engine workloads are more than sufficient to hog the
      CPU, preventing the system from even processing ICMP echo replies.
      
      v2: Tvrtko dug into cond_resched() on x86 and found that it only
      depended upon preempt_count and not tif_need_resched() - which means
      that we would always call schedule() at that point.
      
      Fixes: c81d4613 ("drm/i915: Convert trace-irq to the breadcrumb waiter")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170404120531.10737-1-chris@chris-wilson.co.ukReviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      (cherry picked from commit a7980a64)
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      d445aaaa