Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 01 2月, 2017 2 次提交
  3. 31 1月, 2017 8 次提交
    • M
      drm/atomic: Fix double free in drm_atomic_state_default_clear · 92c715fc
      由 Maarten Lankhorst 提交于 
      drm_atomic_helper_page_flip and drm_atomic_ioctl set their own events
in crtc_state->event. But when it's set the event is freed in 2 places.

Solve this by only freeing the event in the atomic ioctl when it
allocated its own event.

This has been broken twice. The first time when the code was introduced,
but only in the corner case when an event is allocated, but more crtc's
were included by atomic check and then failing. This can mostly
happen when you do an atomic modeset in i915 and the display clock is
changed, which forces all crtc's to be included to the state.

This has been broken worse by adding in-fences support, which caused
the double free to be done unconditionally.

[IGT] kms_rotation_crc: starting subtest primary-rotation-180
=============================================================================
BUG kmalloc-128 (Tainted: G     U         ): Object already free
-----------------------------------------------------------------------------

Disabling lock debugging due to kernel taint
INFO: Allocated in drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper] age=0 cpu=3 pid=1529
 ___slab_alloc+0x308/0x3b0
 __slab_alloc+0xd/0x20
 kmem_cache_alloc_trace+0x92/0x1c0
 drm_atomic_helper_setup_commit+0x285/0x2f0 [drm_kms_helper]
 intel_atomic_commit+0x35/0x4f0 [i915]
 drm_atomic_commit+0x46/0x50 [drm]
 drm_mode_atomic_ioctl+0x7d4/0xab0 [drm]
 drm_ioctl+0x2b3/0x490 [drm]
 do_vfs_ioctl+0x69c/0x700
 SyS_ioctl+0x4e/0x80
 entry_SYSCALL_64_fastpath+0x13/0x94
INFO: Freed in drm_event_cancel_free+0xa3/0xb0 [drm] age=0 cpu=3 pid=1529
 __slab_free+0x48/0x2e0
 kfree+0x159/0x1a0
 drm_event_cancel_free+0xa3/0xb0 [drm]
 drm_mode_atomic_ioctl+0x86d/0xab0 [drm]
 drm_ioctl+0x2b3/0x490 [drm]
 do_vfs_ioctl+0x69c/0x700
 SyS_ioctl+0x4e/0x80
 entry_SYSCALL_64_fastpath+0x13/0x94
INFO: Slab 0xffffde1f0997b080 objects=17 used=2 fp=0xffff92fb65ec2578 flags=0x200000000008101
INFO: Object 0xffff92fb65ec2578 @offset=1400 fp=0xffff92fb65ec2ae8

Redzone ffff92fb65ec2570: bb bb bb bb bb bb bb bb                          ........
Object ffff92fb65ec2578: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
Object ffff92fb65ec2588: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
Object ffff92fb65ec2598: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
Object ffff92fb65ec25a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
Object ffff92fb65ec25b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
Object ffff92fb65ec25c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
Object ffff92fb65ec25d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk
Object ffff92fb65ec25e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  kkkkkkkkkkkkkkk.
Redzone ffff92fb65ec25f8: bb bb bb bb bb bb bb bb                          ........
Padding ffff92fb65ec2738: 5a 5a 5a 5a 5a 5a 5a 5a                          ZZZZZZZZ
CPU: 3 PID: 180 Comm: kworker/3:2 Tainted: G    BU          4.10.0-rc6-patser+ #5039
Hardware name:                  /NUC5PPYB, BIOS PYBSWCEL.86A.0031.2015.0601.1712 06/01/2015
Workqueue: events intel_atomic_helper_free_state [i915]
Call Trace:
 dump_stack+0x4d/0x6d
 print_trailer+0x20c/0x220
 free_debug_processing+0x1c6/0x330
 ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
 __slab_free+0x48/0x2e0
 ? drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
 kfree+0x159/0x1a0
 drm_atomic_state_default_clear+0xf7/0x1c0 [drm]
 ? drm_atomic_state_clear+0x30/0x30 [drm]
 intel_atomic_state_clear+0xd/0x20 [i915]
 drm_atomic_state_clear+0x1a/0x30 [drm]
 __drm_atomic_state_free+0x13/0x60 [drm]
 intel_atomic_helper_free_state+0x5d/0x70 [i915]
 process_one_work+0x260/0x4a0
 worker_thread+0x2d1/0x4f0
 kthread+0x127/0x130
 ? process_one_work+0x4a0/0x4a0
 ? kthread_stop+0x120/0x120
 ret_from_fork+0x29/0x40
FIX kmalloc-128: Object at 0xffff92fb65ec2578 not freed

Fixes: 3b24f7d6 ("drm/atomic: Add struct drm_crtc_commit to track async updates")
Fixes: 96260142 ("drm/fence: add in-fences support")
Cc: <stable@vger.kernel.org> # v4.8+
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1485854725-27640-1-git-send-email-maarten.lankhorst@linux.intel.com
      92c715fc
    • B
      drm/nouveau/kms/nv50: request vblank events for commits that send completion events · 2b507893
      由 Ben Skeggs 提交于 
      This somehow fixes an issue where sync-to-vblank longer works correctly
after resume from suspend.

From a HW perspective, we don't need the IRQs turned on to be able to
detect flip completion, so it's assumed that this is required for the
voodoo in the core DRM vblank core.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      2b507893
    • I
      drm/nouveau/nv1a,nv1f/disp: fix memory clock rate retrieval · 24bf7ae3
      由 Ilia Mirkin 提交于 
      Based on the xf86-video-nv code, NFORCE (NV1A) and NFORCE2 (NV1F) have a
different way of retrieving clocks. See the
nv_hw.c:nForceUpdateArbitrationSettings function in the original code
for how these clocks were accessed.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=54587
Cc: stable@vger.kernel.org
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      24bf7ae3
    • A
      drm/nouveau/disp/gt215: Fix HDA ELD handling (thus, HDMI audio) on gt215 · d347583a
      由 Alastair Bridgewater 提交于 
      Store the ELD correctly, not just enough copies of the first byte
to pad out the given ELD size.
Signed-off-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
Fixes: 120b0c39 ("drm/nv50-/disp: audit and version SOR_HDA_ELD method")
Cc: stable@vger.kernel.org # v3.17+
Reviewed-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      d347583a
    • M
      drm/nouveau/nouveau/led: prevent compiling the led-code if nouveau=y and leds=m · d72498ca
      由 Martin Peres 提交于 
      The proper fix would have been to select LEDS_CLASS but this can lead
to a circular dependency, as found out by Arnd.

This patch implements Arnd's suggestion instead, at the cost of some
auto-magic for a fringe feature.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Reported-by: Intel's 0-DAY
Fixes: 8d021d71 ("drm/nouveau/drm/nouveau: add a LED driver for the NVIDIA logo")
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      d72498ca
    • B
      drm/nouveau/disp/mcp7x: disable dptmds workaround · 7dfee682
      由 Ben Skeggs 提交于 
      The workaround appears to cause regressions on these boards, and from
inspection of RM traces, NVIDIA don't appear to do it on them either.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Tested-by: NRoy Spliet <nouveau@spliet.org>
      7dfee682
    • B
      drm/nouveau: prevent userspace from deleting client object · c966b627
      由 Ben Skeggs 提交于 
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      c966b627
    • B
      drm/nouveau/fence/g84-: protect against concurrent access to semaphore buffers · 96692b09
      由 Ben Skeggs 提交于 
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      96692b09
  5. 30 1月, 2017 3 次提交
    • D
      drm: Don't race connector registration · e6e7b48b
      由 Daniel Vetter 提交于 
      I was under the misconception that the sysfs dev stuff can be fully
set up, and then registered all in one step with device_add. That's
true for properties and property groups, but not for parents and child
devices. Those must be fully registered before you can register a
child.

Add a bit of tracking to make sure that asynchronous mst connector
hotplugging gets this right. For consistency we rely upon the implicit
barriers of the connector->mutex, which is taken anyway, to ensure
that at least either the connector or device registration call will
work out.

Mildly tested since I can't reliably reproduce this on my mst box
here.
Reported-by: NDave Hansen <dave.hansen@intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1484237756-2720-1-git-send-email-daniel.vetter@ffwll.ch
      e6e7b48b
    • D
      drm: prevent double-(un)registration for connectors · 4e5b54f1
      由 Daniel Vetter 提交于 
      If we're unlucky then the registration from a hotplugged connector
might race with the final registration step on driver load. And since
MST topology discover is asynchronous that's even somewhat likely.

v2: Also update the kerneldoc for @registered!

v3: Review from Chris:
- Improve kerneldoc for late_register/early_unregister callbacks.
- Use mutex_destroy.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218133545.2106-1-daniel.vetter@ffwll.ch
(cherry picked from commit e73ab00e)
      4e5b54f1
    • L
      drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj() · 39cb2c9a
      由 Linus Torvalds 提交于 
      I've seen this trigger twice now, where the i915_gem_object_to_ggtt()
call in intel_unpin_fb_obj() returns NULL, resulting in an oops
immediately afterwards as the (inlined) call to i915_vma_unpin_fence()
tries to dereference it.

It seems to be some race condition where the object is going away at
shutdown time, since both times happened when shutting down the X
server.  The call chains were different:

 - VT ioctl(KDSETMODE, KD_TEXT):

    intel_cleanup_plane_fb+0x5b/0xa0 [i915]
    drm_atomic_helper_cleanup_planes+0x6f/0x90 [drm_kms_helper]
    intel_atomic_commit_tail+0x749/0xfe0 [i915]
    intel_atomic_commit+0x3cb/0x4f0 [i915]
    drm_atomic_commit+0x4b/0x50 [drm]
    restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper]
    drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper]
    drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper]
    intel_fbdev_set_par+0x18/0x70 [i915]
    fb_set_var+0x236/0x460
    fbcon_blank+0x30f/0x350
    do_unblank_screen+0xd2/0x1a0
    vt_ioctl+0x507/0x12a0
    tty_ioctl+0x355/0xc30
    do_vfs_ioctl+0xa3/0x5e0
    SyS_ioctl+0x79/0x90
    entry_SYSCALL_64_fastpath+0x13/0x94

 - i915 unpin_work workqueue:

    intel_unpin_work_fn+0x58/0x140 [i915]
    process_one_work+0x1f1/0x480
    worker_thread+0x48/0x4d0
    kthread+0x101/0x140

and this patch purely papers over the issue by adding a NULL pointer
check and a WARN_ON_ONCE() to avoid the oops that would then generally
make the machine unresponsive.

Other callers of i915_gem_object_to_ggtt() seem to also check for the
returned pointer being NULL and warn about it, so this clearly has
happened before in other places.

[ Reported it originally to the i915 developers on Jan 8, applying the
  ugly workaround on my own now after triggering the problem for the
  second time with no feedback.

  This is likely to be the same bug reported as

     https://bugs.freedesktop.org/show_bug.cgi?id=98829
     https://bugs.freedesktop.org/show_bug.cgi?id=99134

  which has a patch for the underlying problem, but it hasn't gotten to
  me, so I'm applying the workaround. ]

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      39cb2c9a
  7. 27 1月, 2017 3 次提交
    • L
      drm/nouveau: Handle fbcon suspend/resume in seperate worker · 15266ae3
      由 Lyude Paul 提交于 
      Resuming from RPM can happen while already holding
dev->mode_config.mutex. This means we can't actually handle fbcon in
any RPM resume workers, since restoring fbcon requires grabbing
dev->mode_config.mutex again. So move the fbcon suspend/resume code into
it's own worker, and rely on that instead to avoid deadlocking.

This fixes more deadlocks for runtime suspending the GPU on the ThinkPad
W541. Reproduction recipe:

 - Get a machine with both optimus and a nvidia card with connectors
   attached to it
 - Wait for the nvidia GPU to suspend
 - Attempt to manually reprobe any of the connectors on the nvidia GPU
   using sysfs
 - *deadlock*

[airlied: use READ_ONCE to address Hans's comment]
Signed-off-by: NLyude <lyude@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: David Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      15266ae3
    • L
      drm/nouveau: Don't enabling polling twice on runtime resume · cae9ff03
      由 Lyude Paul 提交于 
      As it turns out, on cards that actually have CRTCs on them we're already
calling drm_kms_helper_poll_enable(drm_dev) from
nouveau_display_resume() before we call it in
nouveau_pmops_runtime_resume(). This leads us to accidentally trying to
enable polling twice, which results in a potential deadlock between the
RPM locks and drm_dev->mode_config.mutex if we end up trying to enable
polling the second time while output_poll_execute is running and holding
the mode_config lock. As such, make sure we only enable polling in
nouveau_pmops_runtime_resume() if we need to.

This fixes hangs observed on the ThinkPad W541
Signed-off-by: NLyude <lyude@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Kilian Singer <kilian.singer@quantumtechnology.info>
Cc: Lukas Wunner <lukas@wunner.de>
Cc: David Airlie <airlied@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      cae9ff03
    • Y
      drm/ast: Fixed system hanged if disable P2A · 6c971c09
      由 Y.C. Chen 提交于 
      The original ast driver will access some BMC configuration through P2A bridge
that can be disabled since AST2300 and after.
It will cause system hanged if P2A bridge is disabled.
Here is the update to fix it.
Signed-off-by: NY.C. Chen <yc_chen@aspeedtech.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      6c971c09
  9. 26 1月, 2017 2 次提交
  11. 25 1月, 2017 11 次提交
  13. 24 1月, 2017 2 次提交
  15. 20 1月, 2017 3 次提交
  17. 18 1月, 2017 6 次提交