1. 26 Apr, 2016 3 commits
    • Lyude's avatar
      drm/dp/mst: Restore primary hub guid on resume · 9dc0487d
      Lyude authored
      Some hubs are forgetful, and end up forgetting whatever GUID we set
      previously after we do a suspend/resume cycle. This can lead to
      hotplugging breaking (along with probably other things) since the hub
      will start sending connection notifications with the wrong GUID. As
      such, we need to check on resume whether or not the GUID the hub is
      giving us is valid.
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Reviewed-by: default avatarHarry Wentland <harry.wentland@amd.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      9dc0487d
    • cpaul@redhat.com's avatar
      drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1() · 263efde3
      cpaul@redhat.com authored
      We can thank KASAN for finding this, otherwise I probably would have spent
      hours on it. This fixes a somewhat harder to trigger kernel panic, occuring
      while enabling MST where the port we were currently updating the payload on
      would have all of it's refs dropped before we finished what we were doing:
      
      ==================================================================
      BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018
      Read of size 4 by task Xorg/973
      =============================================================================
      BUG kmalloc-2048 (Tainted: G    B   W      ): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175
      	___slab_alloc+0x472/0x490
      	__slab_alloc+0x20/0x40
      	kmem_cache_alloc_trace+0x151/0x190
      	drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper]
      	drm_dp_send_link_address+0x526/0x960 [drm_kms_helper]
      	drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper]
      	drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper]
      	process_one_work+0x562/0x1350
      	worker_thread+0xd9/0x1390
      	kthread+0x1c5/0x260
      	ret_from_fork+0x22/0x40
      INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175
      	__slab_free+0x17f/0x2d0
      	kfree+0x169/0x180
      	drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper]
      	drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper]
      	process_one_work+0x562/0x1350
      	worker_thread+0xd9/0x1390
      	kthread+0x1c5/0x260
      	ret_from_fork+0x22/0x40
      
      which on this T460s, would eventually lead to kernel panics in somewhat
      random places later in intel_mst_enable_dp() if we got lucky enough.
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      263efde3
    • Dave Airlie's avatar
      Merge branch 'drm-etnaviv-fixes' of git://git.pengutronix.de:/git/lst/linux into drm-fixes · bd0b560a
      Dave Airlie authored
      just a single fix to not move the GPU linear window on cores where it
      might lead to inconsistent views of the memory by different engines in
      the core, thus breaking relocs and possibly causing other fun.
      
      * 'drm-etnaviv-fixes' of git://git.pengutronix.de:/git/lst/linux:
        drm/etnaviv: don't move linear memory window on 3D cores without MC2.0
      bd0b560a
  2. 24 Apr, 2016 2 commits
  3. 23 Apr, 2016 10 commits
  4. 22 Apr, 2016 24 commits
  5. 21 Apr, 2016 1 commit
    • cpaul@redhat.com's avatar
      drm/dp/mst: Validate port in drm_dp_payload_send_msg() · deba0a2a
      cpaul@redhat.com authored
      With the joys of things running concurrently, there's always a chance
      that the port we get passed in drm_dp_payload_send_msg() isn't actually
      valid anymore. Because of this, we need to make sure we validate the
      reference to the port before we use it otherwise we risk running into
      various race conditions. For instance, on the Dell MST monitor I have
      here for testing, hotplugging it enough times causes us to kernel panic:
      
      [drm:intel_mst_enable_dp] 1
      [drm:drm_dp_update_payload_part2] payload 0 1
      [drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x10101011, pins 0x00000020
      [drm:intel_hpd_irq_handler] digital hpd port B - short
      [drm:intel_dp_hpd_pulse] got hpd irq on port B - short
      [drm:intel_dp_check_mst_status] got esi 00 10 00
      [drm:drm_dp_update_payload_part2] payload 1 1
      general protection fault: 0000 [#1] SMP
      …
      Call Trace:
       [<ffffffffa012b632>] drm_dp_update_payload_part2+0xc2/0x130 [drm_kms_helper]
       [<ffffffffa032ef08>] intel_mst_enable_dp+0xf8/0x180 [i915]
       [<ffffffffa0310dbd>] haswell_crtc_enable+0x3ed/0x8c0 [i915]
       [<ffffffffa030c84d>] intel_atomic_commit+0x5ad/0x1590 [i915]
       [<ffffffffa01db877>] ? drm_atomic_set_crtc_for_connector+0x57/0xe0 [drm]
       [<ffffffffa01dc4e7>] drm_atomic_commit+0x37/0x60 [drm]
       [<ffffffffa0130a3a>] drm_atomic_helper_set_config+0x7a/0xb0 [drm_kms_helper]
       [<ffffffffa01cc482>] drm_mode_set_config_internal+0x62/0x100 [drm]
       [<ffffffffa01d02ad>] drm_mode_setcrtc+0x3cd/0x4e0 [drm]
       [<ffffffffa01c18e3>] drm_ioctl+0x143/0x510 [drm]
       [<ffffffffa01cfee0>] ? drm_mode_setplane+0x1b0/0x1b0 [drm]
       [<ffffffff810f79a7>] ? hrtimer_start_range_ns+0x1b7/0x3a0
       [<ffffffff81212962>] do_vfs_ioctl+0x92/0x570
       [<ffffffff81590852>] ? __sys_recvmsg+0x42/0x80
       [<ffffffff81212eb9>] SyS_ioctl+0x79/0x90
       [<ffffffff816b4e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4
      RIP  [<ffffffffa012b026>] drm_dp_payload_send_msg+0x146/0x1f0 [drm_kms_helper]
      
      Which occurs because of the hotplug event shown in the log, which ends
      up causing DRM's dp helpers to drop the port we're updating the payload
      on and panic.
      
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Reviewed-by: default avatarDavid Airlie <airlied@linux.ie>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      deba0a2a