1. 13 May, 2022 1 commit
    • Javier Martinez Canillas's avatar
      fbdev: Restart conflicting fb removal loop when unregistering devices · 3367aa7d
      Javier Martinez Canillas authored
      Drivers that want to remove registered conflicting framebuffers prior to
      register their own framebuffer, call to remove_conflicting_framebuffers().
      
      This function takes the registration_lock mutex, to prevent a race when
      drivers register framebuffer devices. But if a conflicting framebuffer
      device is found, the underlaying platform device is unregistered and this
      will lead to the platform driver .remove callback to be called. Which in
      turn will call to unregister_framebuffer() that takes the same lock.
      
      To prevent this, a struct fb_info.forced_out field was used as indication
      to unregister_framebuffer() whether the mutex has to be grabbed or not.
      
      But this could be unsafe, since the fbdev core is making assumptions about
      what drivers may or may not do in their .remove callbacks. Allowing to run
      these callbacks with the registration_lock held can cause deadlocks, since
      the fbdev core has no control over what drivers do in their removal path.
      
      A better solution is to drop the lock before platform_device_unregister(),
      so unregister_framebuffer() can take it when called from the fbdev driver.
      The lock is acquired again after the device has been unregistered and at
      this point the removal loop can be restarted.
      
      Since the conflicting framebuffer device has already been removed, the
      loop would just finish when no more conflicting framebuffers are found.
      Suggested-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarJavier Martinez Canillas <javierm@redhat.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20220511113039.1252432-1-javierm@redhat.com
      3367aa7d
  2. 12 May, 2022 6 commits
  3. 11 May, 2022 6 commits
  4. 10 May, 2022 2 commits
  5. 09 May, 2022 1 commit
  6. 08 May, 2022 3 commits
  7. 06 May, 2022 2 commits
  8. 05 May, 2022 19 commits