1. 13 Nov, 2019 1 commit
    • Henry Lin's avatar
      ALSA: usb-audio: not submit urb for stopped endpoint · 52869931
      Henry Lin authored
      While output urb's snd_complete_urb() is executing, calling
      prepare_outbound_urb() may cause endpoint stopped before
      prepare_outbound_urb() returns and result in next urb submitted
      to stopped endpoint. usb-audio driver cannot re-use it afterwards as
      the urb is still hold by usb stack.
      
      This change checks EP_FLAG_RUNNING flag after prepare_outbound_urb() again
      to let snd_complete_urb() know the endpoint already stopped and does not
      submit next urb. Below kind of error will be fixed:
      
      [  213.153103] usb 1-2: timeout: still 1 active urbs on EP #1
      [  213.164121] usb 1-2: cannot submit urb 0, error -16: unknown error
      Signed-off-by: default avatarHenry Lin <henryl@nvidia.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20191113021420.13377-1-henryl@nvidia.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      52869931
  2. 11 Nov, 2019 2 commits
  3. 09 Nov, 2019 1 commit
  4. 07 Nov, 2019 1 commit
  5. 06 Nov, 2019 2 commits
  6. 05 Nov, 2019 4 commits
  7. 04 Nov, 2019 2 commits
  8. 30 Oct, 2019 2 commits
    • Takashi Iwai's avatar
      ALSA: timer: Fix mutex deadlock at releasing card · a3933186
      Takashi Iwai authored
      When a card is disconnected while in use, the system waits until all
      opened files are closed then releases the card.  This is done via
      put_device() of the card device in each device release code.
      
      The recently reported mutex deadlock bug happens in this code path;
      snd_timer_close() for the timer device deals with the global
      register_mutex and it calls put_device() there.  When this timer
      device is the last one, the card gets freed and it eventually calls
      snd_timer_free(), which has again the protection with the global
      register_mutex -- boom.
      
      Basically put_device() call itself is race-free, so a relative simple
      workaround is to move this put_device() call out of the mutex.  For
      achieving that, in this patch, snd_timer_close_locked() got a new
      argument to store the card device pointer in return, and each caller
      invokes put_device() with the returned object after the mutex unlock.
      Reported-and-tested-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a3933186
    • Takashi Iwai's avatar
      ALSA: hda - Fix mutex deadlock in HDMI codec driver · 302d5a80
      Takashi Iwai authored
      The commit ade49db3 ("ALSA: hda/hdmi - Allow audio component for
      AMD/ATI and Nvidia HDMI") introduced the spec->pcm_lock mutex lock to
      the whole generic_hdmi_init() function for avoiding the race with the
      audio component registration.  However, this caused a dead lock when
      the unsolicited event is handled without the audio component, as the
      codec gets runtime-resumed in hdmi_present_sense() which is already
      inside the spec->pcm_lock in its caller.
      
      For avoiding this deadlock, add a new mutex only for the audio
      component binding that is used in both generic_hdmi_init() and the
      audio notifier registration where the jack callbacks are handled /
      re-registered.
      
      Fixes: ade49db3 ("ALSA: hda/hdmi - Allow audio component for AMD/ATI and Nvidia HDMI")
      Reported-and-tested-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://lore.kernel.org/r/s5himo7i89i.wl-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      302d5a80
  9. 28 Oct, 2019 6 commits
  10. 26 Oct, 2019 1 commit
  11. 24 Oct, 2019 3 commits
  12. 23 Oct, 2019 5 commits
  13. 22 Oct, 2019 1 commit
  14. 21 Oct, 2019 4 commits
  15. 18 Oct, 2019 4 commits
  16. 17 Oct, 2019 1 commit