1. 11 Jan, 2024 2 commits
    • Maíra Canal's avatar
      drm/vc4: don't check if plane->state->fb == state->fb · 5ee0d47d
      Maíra Canal authored
      Currently, when using non-blocking commits, we can see the following
      kernel warning:
      
      [  110.908514] ------------[ cut here ]------------
      [  110.908529] refcount_t: underflow; use-after-free.
      [  110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0
      [  110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6
      [  110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G         C         6.1.66-v8+ #32
      [  110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
      [  110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      [  110.909132] pc : refcount_dec_not_one+0xb8/0xc0
      [  110.909152] lr : refcount_dec_not_one+0xb4/0xc0
      [  110.909170] sp : ffffffc00913b9c0
      [  110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60
      [  110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480
      [  110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78
      [  110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000
      [  110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004
      [  110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003
      [  110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00
      [  110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572
      [  110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000
      [  110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001
      [  110.909434] Call trace:
      [  110.909441]  refcount_dec_not_one+0xb8/0xc0
      [  110.909461]  vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]
      [  110.909903]  vc4_cleanup_fb+0x44/0x50 [vc4]
      [  110.910315]  drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]
      [  110.910669]  vc4_atomic_commit_tail+0x390/0x9dc [vc4]
      [  110.911079]  commit_tail+0xb0/0x164 [drm_kms_helper]
      [  110.911397]  drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]
      [  110.911716]  drm_atomic_commit+0xb0/0xdc [drm]
      [  110.912569]  drm_mode_atomic_ioctl+0x348/0x4b8 [drm]
      [  110.913330]  drm_ioctl_kernel+0xec/0x15c [drm]
      [  110.914091]  drm_ioctl+0x24c/0x3b0 [drm]
      [  110.914850]  __arm64_sys_ioctl+0x9c/0xd4
      [  110.914873]  invoke_syscall+0x4c/0x114
      [  110.914897]  el0_svc_common+0xd0/0x118
      [  110.914917]  do_el0_svc+0x38/0xd0
      [  110.914936]  el0_svc+0x30/0x8c
      [  110.914958]  el0t_64_sync_handler+0x84/0xf0
      [  110.914979]  el0t_64_sync+0x18c/0x190
      [  110.914996] ---[ end trace 0000000000000000 ]---
      
      This happens because, although `prepare_fb` and `cleanup_fb` are
      perfectly balanced, we cannot guarantee consistency in the check
      plane->state->fb == state->fb. This means that sometimes we can increase
      the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The
      opposite can also be true.
      
      In fact, the struct drm_plane .state shouldn't be accessed directly
      but instead, the `drm_atomic_get_new_plane_state()` helper function should
      be used. So, we could stick to this check, but using
      `drm_atomic_get_new_plane_state()`. But actually, this check is not really
      needed. We can increase and decrease the refcount symmetrically without
      problems.
      
      This is going to make the code more simple and consistent.
      Signed-off-by: default avatarMaíra Canal <mcanal@igalia.com>
      Acked-by: default avatarMaxime Ripard <mripard@kernel.org>
      Link: https://patchwork.freedesktop.org/patch/msgid/20240105175908.242000-1-mcanal@igalia.com
      5ee0d47d
    • chenxuebing's avatar
      drm/edid: Clean up errors in drm_edid.c · cbe7cea7
      chenxuebing authored
      Fix the following errors reported by checkpatch:
      
      ERROR: do not use assignment in if condition
      Signed-off-by: default avatarchenxuebing <chenxb_99091@126.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarJani Nikula <jani.nikula@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20240111063921.8701-1-chenxb_99091@126.com
      cbe7cea7
  2. 10 Jan, 2024 3 commits
  3. 09 Jan, 2024 5 commits
  4. 08 Jan, 2024 12 commits
  5. 05 Jan, 2024 2 commits
  6. 04 Jan, 2024 14 commits
  7. 03 Jan, 2024 1 commit
  8. 02 Jan, 2024 1 commit