1. 12 Apr, 2022 26 commits
  2. 11 Apr, 2022 2 commits
  3. 08 Apr, 2022 2 commits
  4. 07 Apr, 2022 3 commits
  5. 05 Apr, 2022 2 commits
  6. 30 Mar, 2022 4 commits
    • Takashi Iwai's avatar
      ALSA: pcm: Fix potential AB/BA lock with buffer_mutex and mmap_lock · bc55cfd5
      Takashi Iwai authored
      syzbot caught a potential deadlock between the PCM
      runtime->buffer_mutex and the mm->mmap_lock.  It was brought by the
      recent fix to cover the racy read/write and other ioctls, and in that
      commit, I overlooked a (hopefully only) corner case that may take the
      revert lock, namely, the OSS mmap.  The OSS mmap operation
      exceptionally allows to re-configure the parameters inside the OSS
      mmap syscall, where mm->mmap_mutex is already held.  Meanwhile, the
      copy_from/to_user calls at read/write operations also take the
      mm->mmap_lock internally, hence it may lead to a AB/BA deadlock.
      
      A similar problem was already seen in the past and we fixed it with a
      refcount (in commit b2483716).  The former fix covered only the
      call paths with OSS read/write and OSS ioctls, while we need to cover
      the concurrent access via both ALSA and OSS APIs now.
      
      This patch addresses the problem above by replacing the buffer_mutex
      lock in the read/write operations with a refcount similar as we've
      used for OSS.  The new field, runtime->buffer_accessing, keeps the
      number of concurrent read/write operations.  Unlike the former
      buffer_mutex protection, this protects only around the
      copy_from/to_user() calls; the other codes are basically protected by
      the PCM stream lock.  The refcount can be a negative, meaning blocked
      by the ioctls.  If a negative value is seen, the read/write aborts
      with -EBUSY.  In the ioctl side, OTOH, they check this refcount, too,
      and set to a negative value for blocking unless it's already being
      accessed.
      
      Reported-by: syzbot+6e5c88838328e99c7e1c@syzkaller.appspotmail.com
      Fixes: dca947d4 ("ALSA: pcm: Fix races among concurrent read/write and buffer changes")
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/000000000000381a0d05db622a81@google.com
      Link: https://lore.kernel.org/r/20220330120903.4738-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      bc55cfd5
    • Takashi Iwai's avatar
      Merge tag 'asoc-fix-v5.18' of... · 21b5954d
      Takashi Iwai authored
      Merge tag 'asoc-fix-v5.18' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
      
      ASoC: Fixes for v5.18
      
      A few fixes that came in during the merge window, all fairly routine.
      21b5954d
    • Mohan Kumar's avatar
      ALSA: hda: Avoid unsol event during RPM suspending · 6ddc2f74
      Mohan Kumar authored
      There is a corner case with unsol event handling during codec runtime
      suspending state. When the codec runtime suspend call initiated, the
      codec->in_pm atomic variable would be 0, currently the codec runtime
      suspend function calls snd_hdac_enter_pm() which will just increments
      the codec->in_pm atomic variable. Consider unsol event happened just
      after this step and before snd_hdac_leave_pm() in the codec runtime
      suspend function. The snd_hdac_power_up_pm() in the unsol event
      flow in hdmi_present_sense_via_verbs() function would just increment
      the codec->in_pm atomic variable without calling pm_runtime_get_sync
      function.
      
      As codec runtime suspend flow is already in progress and in parallel
      unsol event is also accessing the codec verbs, as soon as codec
      suspend flow completes and clocks are  switched off before completing
      the unsol event handling as both functions doesn't wait for each other.
      This will result in below errors
      
      [  589.428020] tegra-hda 3510000.hda: azx_get_response timeout, switching
      to polling mode: last cmd=0x505f2f57
      [  589.428344] tegra-hda 3510000.hda: spurious response 0x80000074:0x5,
      last cmd=0x505f2f57
      [  589.428547] tegra-hda 3510000.hda: spurious response 0x80000065:0x5,
      last cmd=0x505f2f57
      
      To avoid this, the unsol event flow should not perform any codec verb
      related operations during RPM_SUSPENDING state.
      Signed-off-by: default avatarMohan Kumar <mkumard@nvidia.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20220329155940.26331-1-mkumard@nvidia.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6ddc2f74
    • Kai-Heng Feng's avatar
      ALSA: hda/realtek: Fix audio regression on Mi Notebook Pro 2020 · f30741cd
      Kai-Heng Feng authored
      Commit 5aec9891 ("ALSA: hda/realtek - ALC236 headset MIC recording
      issue") is to solve recording issue met on AL236, by matching codec
      variant ALC269_TYPE_ALC257 and ALC269_TYPE_ALC256.
      
      This match can be too broad and Mi Notebook Pro 2020 is broken by the
      patch.
      
      Instead, use codec ID to be narrow down the scope, in order to make
      ALC256 unaffected.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215484
      Fixes: 5aec9891 ("ALSA: hda/realtek - ALC236 headset MIC recording issue")
      Reported-by: default avatarkernel test robot <lkp@intel.com>
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Link: https://lore.kernel.org/r/20220330061335.1015533-1-kai.heng.feng@canonical.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      f30741cd
  7. 28 Mar, 2022 1 commit