1. 17 Oct, 2019 10 commits
  2. 16 Oct, 2019 7 commits
    • Chris Wilson's avatar
      drm/i915: Fixup preempt-to-busy vs resubmission of a virtual request · 0a544a2a
      Chris Wilson authored
      As preempt-to-busy leaves the request on the HW as the resubmission is
      processed, that request may complete in the background and even cause a
      second virtual request to enter queue. This second virtual request
      breaks our "single request in the virtual pipeline" assumptions.
      Furthermore, as the virtual request may be completed and retired, we
      lose the reference the virtual engine assumes is held. Normally, just
      removing the request from the scheduler queue removes it from the
      engine, but the virtual engine keeps track of its singleton request via
      its ve->request. This pointer needs protecting with a reference.
      
      v2: Drop unnecessary motion of rq->engine = owner
      
      Fixes: 22b7a426 ("drm/i915/execlists: Preempt-to-busy")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190923152844.8914-1-chris@chris-wilson.co.uk
      (cherry picked from commit b647c7df)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      0a544a2a
    • Chris Wilson's avatar
      drm/i915/userptr: Never allow userptr into the mappable GGTT · 4f2a572e
      Chris Wilson authored
      Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to
      invalidate userptr objects which also happen to be pulled into GGTT
      mmaps. That is when we unbind the userptr object (on mmu invalidation),
      we revoke all CPU mmaps, which may then recurse into mmu invalidation.
      
      We looked for ways of breaking the cycle, but the revocation on
      invalidation is required and cannot be avoided. The only solution we
      could see was to not allow such GGTT bindings of userptr objects in the
      first place. In practice, no one really wants to use a GGTT mmapping of
      a CPU pointer...
      
      Just before Daniel's explosive lockdep patches land in v5.4-rc1, we got
      a genuine blip from CI:
      
      <4>[  246.793958] ======================================================
      <4>[  246.793972] WARNING: possible circular locking dependency detected
      <4>[  246.793989] 5.3.0-gbd6c56f50d15-drmtip_372+ #1 Tainted: G     U
      <4>[  246.794003] ------------------------------------------------------
      <4>[  246.794017] kswapd0/145 is trying to acquire lock:
      <4>[  246.794030] 000000003f565be6 (&dev->struct_mutex/1){+.+.}, at: userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
      <4>[  246.794250]
                        but task is already holding lock:
      <4>[  246.794263] 000000001799cef9 (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe6/0x2a0
      <4>[  246.794291]
                        which lock already depends on the new lock.
      
      <4>[  246.794307]
                        the existing dependency chain (in reverse order) is:
      <4>[  246.794322]
                        -> #3 (&anon_vma->rwsem){++++}:
      <4>[  246.794344]        down_write+0x33/0x70
      <4>[  246.794357]        __vma_adjust+0x3d9/0x7b0
      <4>[  246.794370]        __split_vma+0x16a/0x180
      <4>[  246.794385]        mprotect_fixup+0x2a5/0x320
      <4>[  246.794399]        do_mprotect_pkey+0x208/0x2e0
      <4>[  246.794413]        __x64_sys_mprotect+0x16/0x20
      <4>[  246.794429]        do_syscall_64+0x55/0x1c0
      <4>[  246.794443]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4>[  246.794456]
                        -> #2 (&mapping->i_mmap_rwsem){++++}:
      <4>[  246.794478]        down_write+0x33/0x70
      <4>[  246.794493]        unmap_mapping_pages+0x48/0x130
      <4>[  246.794519]        i915_vma_revoke_mmap+0x81/0x1b0 [i915]
      <4>[  246.794519]        i915_vma_unbind+0x11d/0x4a0 [i915]
      <4>[  246.794519]        i915_vma_destroy+0x31/0x300 [i915]
      <4>[  246.794519]        __i915_gem_free_objects+0xb8/0x4b0 [i915]
      <4>[  246.794519]        drm_file_free.part.0+0x1e6/0x290
      <4>[  246.794519]        drm_release+0xa6/0xe0
      <4>[  246.794519]        __fput+0xc2/0x250
      <4>[  246.794519]        task_work_run+0x82/0xb0
      <4>[  246.794519]        do_exit+0x35b/0xdb0
      <4>[  246.794519]        do_group_exit+0x34/0xb0
      <4>[  246.794519]        __x64_sys_exit_group+0xf/0x10
      <4>[  246.794519]        do_syscall_64+0x55/0x1c0
      <4>[  246.794519]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4>[  246.794519]
                        -> #1 (&vm->mutex){+.+.}:
      <4>[  246.794519]        i915_gem_shrinker_taints_mutex+0x6d/0xe0 [i915]
      <4>[  246.794519]        i915_address_space_init+0x9f/0x160 [i915]
      <4>[  246.794519]        i915_ggtt_init_hw+0x55/0x170 [i915]
      <4>[  246.794519]        i915_driver_probe+0xc9f/0x1620 [i915]
      <4>[  246.794519]        i915_pci_probe+0x43/0x1b0 [i915]
      <4>[  246.794519]        pci_device_probe+0x9e/0x120
      <4>[  246.794519]        really_probe+0xea/0x3d0
      <4>[  246.794519]        driver_probe_device+0x10b/0x120
      <4>[  246.794519]        device_driver_attach+0x4a/0x50
      <4>[  246.794519]        __driver_attach+0x97/0x130
      <4>[  246.794519]        bus_for_each_dev+0x74/0xc0
      <4>[  246.794519]        bus_add_driver+0x13f/0x210
      <4>[  246.794519]        driver_register+0x56/0xe0
      <4>[  246.794519]        do_one_initcall+0x58/0x300
      <4>[  246.794519]        do_init_module+0x56/0x1f6
      <4>[  246.794519]        load_module+0x25bd/0x2a40
      <4>[  246.794519]        __se_sys_finit_module+0xd3/0xf0
      <4>[  246.794519]        do_syscall_64+0x55/0x1c0
      <4>[  246.794519]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4>[  246.794519]
                        -> #0 (&dev->struct_mutex/1){+.+.}:
      <4>[  246.794519]        __lock_acquire+0x15d8/0x1e90
      <4>[  246.794519]        lock_acquire+0xa6/0x1c0
      <4>[  246.794519]        __mutex_lock+0x9d/0x9b0
      <4>[  246.794519]        userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
      <4>[  246.794519]        __mmu_notifier_invalidate_range_start+0x85/0x110
      <4>[  246.794519]        try_to_unmap_one+0x76b/0x860
      <4>[  246.794519]        rmap_walk_anon+0x104/0x280
      <4>[  246.794519]        try_to_unmap+0xc0/0xf0
      <4>[  246.794519]        shrink_page_list+0x561/0xc10
      <4>[  246.794519]        shrink_inactive_list+0x220/0x440
      <4>[  246.794519]        shrink_node_memcg+0x36e/0x740
      <4>[  246.794519]        shrink_node+0xcb/0x490
      <4>[  246.794519]        balance_pgdat+0x241/0x580
      <4>[  246.794519]        kswapd+0x16c/0x530
      <4>[  246.794519]        kthread+0x119/0x130
      <4>[  246.794519]        ret_from_fork+0x24/0x50
      <4>[  246.794519]
                        other info that might help us debug this:
      
      <4>[  246.794519] Chain exists of:
                          &dev->struct_mutex/1 --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem
      
      <4>[  246.794519]  Possible unsafe locking scenario:
      
      <4>[  246.794519]        CPU0                    CPU1
      <4>[  246.794519]        ----                    ----
      <4>[  246.794519]   lock(&anon_vma->rwsem);
      <4>[  246.794519]                                lock(&mapping->i_mmap_rwsem);
      <4>[  246.794519]                                lock(&anon_vma->rwsem);
      <4>[  246.794519]   lock(&dev->struct_mutex/1);
      <4>[  246.794519]
                         *** DEADLOCK ***
      
      v2: Say no to mmap_ioctl
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111744
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111870Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190928082546.3473-1-chris@chris-wilson.co.uk
      (cherry picked from commit a4311745)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      4f2a572e
    • Ville Syrjälä's avatar
      drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin · 0336ab58
      Ville Syrjälä authored
      The first come first served apporoach to handling the VBT
      child device AUX ch conflicts has backfired. We have machines
      in the wild where the VBT specifies both port A eDP and
      port E DP (in that order) with port E being the real one.
      
      So let's try to flip the preference around and let the last
      child device win once again.
      
      Cc: stable@vger.kernel.org
      Cc: Jani Nikula <jani.nikula@intel.com>
      Tested-by: default avatarMasami Ichikawa <masami256@gmail.com>
      Tested-by: default avatarTorsten <freedesktop201910@liggy.de>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111966
      Fixes: 36a0f920 ("drm/i915/bios: make child device order the priority order")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191011202030.8829-1-ville.syrjala@linux.intel.comAcked-by: default avatarJani Nikula <jani.nikula@intel.com>
      (cherry picked from commit 41e35ffb)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      0336ab58
    • Chris Wilson's avatar
      drm/i915/execlists: Refactor -EIO markup of hung requests · 128260a4
      Chris Wilson authored
      Pull setting -EIO on the hung requests into its own utility function.
      Having allowed ourselves to short-circuit submission of completed
      requests, we can now do the mark_eio() prior to submission and avoid
      some redundant operations.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190923110056.15176-4-chris@chris-wilson.co.uk
      (cherry picked from commit 0d7cf7bc)
      Signed-off-by: default avatarRodrigo Vivi <rodrigo.vivi@intel.com>
      128260a4
    • Ben Dooks's avatar
      kthread: make __kthread_queue_delayed_work static · bc88f85c
      Ben Dooks authored
      The __kthread_queue_delayed_work is not exported so
      make it static, to avoid the following sparse warning:
      
        kernel/kthread.c:869:6: warning: symbol '__kthread_queue_delayed_work' was not declared. Should it be static?
      Signed-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      bc88f85c
    • Max Filippov's avatar
      xtensa: fix change_bit in exclusive access option · 775fd6bf
      Max Filippov authored
      change_bit implementation for XCHAL_HAVE_EXCLUSIVE case changes all bits
      except the one required due to copy-paste error from clear_bit.
      
      Cc: stable@vger.kernel.org # v5.2+
      Fixes: f7c34874 ("xtensa: add exclusive atomics support")
      Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
      775fd6bf
    • Kai-Heng Feng's avatar
      Revert "Input: elantech - enable SMBus on new (2018+) systems" · c324345c
      Kai-Heng Feng authored
      This reverts commit 883a2a80.
      
      Apparently use dmi_get_bios_year() as manufacturing date isn't accurate
      and this breaks older laptops with new BIOS update.
      
      So let's revert this patch.
      
      There are still new HP laptops still need to use SMBus to support all
      features, but it'll be enabled via a whitelist.
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Acked-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Cc: stable@vger.kernel.org
      Link: https://lore.kernel.org/r/20191001070845.9720-1-kai.heng.feng@canonical.comSigned-off-by: default avatarDmitry Torokhov <dmitry.torokhov@gmail.com>
      c324345c
  3. 15 Oct, 2019 8 commits
  4. 14 Oct, 2019 15 commits