1. 09 Jun, 2021 13 commits
  2. 08 Jun, 2021 5 commits
  3. 07 Jun, 2021 9 commits
  4. 06 Jun, 2021 3 commits
  5. 05 Jun, 2021 5 commits
  6. 04 Jun, 2021 1 commit
  7. 03 Jun, 2021 2 commits
  8. 02 Jun, 2021 2 commits
    • Dongliang Mu's avatar
      ALSA: control led: fix memory leak in snd_ctl_led_register · 3ae72f6a
      Dongliang Mu authored
      The snd_ctl_led_sysfs_add and snd_ctl_led_sysfs_remove should contain
      the refcount operations in pair. However, snd_ctl_led_sysfs_remove fails
      to decrease the refcount to zero, which causes device_release never to
      be invoked. This leads to memory leak to some resources, like struct
      device_private. In addition, we also free some other similar memory
      leaks in snd_ctl_led_init/snd_ctl_led_exit.
      
      Fix this by replacing device_del to device_unregister
      in snd_ctl_led_sysfs_remove/snd_ctl_led_init/snd_ctl_led_exit.
      
      Note that, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device will
      call kobject_release and delay the release of kobject, which will cause
      use-after-free when the memory backing the kobject is freed at once.
      
      Reported-by: syzbot+08a7d8b51ea048a74ffb@syzkaller.appspotmail.com
      Fixes: a135dfb5 ("ALSA: led control - add sysfs kcontrol LED marking layer")
      Signed-off-by: default avatarDongliang Mu <mudongliangabcd@gmail.com>
      Reviewed-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: default avatarJaroslav Kysela <perex@perex.cz>
      Link: https://lore.kernel.org/r/20210602034136.2762497-1-mudongliangabcd@gmail.comSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3ae72f6a
    • Takashi Iwai's avatar
      ALSA: usb-audio: Reduce latency at playback start · 9ce650a7
      Takashi Iwai authored
      USB-audio driver behaves a bit strangely for the playback stream --
      namely, it starts sending silent packets at PCM prepare state while
      the actual data is submitted at first when the trigger START is kicked
      off.  This is a workaround for the behavior where URBs are processed
      too quickly at the beginning.  That is, if we start submitting URBs at
      trigger START, the first few URBs will be immediately completed, and
      this would result in the immediate period-elapsed calls right after
      the start, which may confuse applications.
      
      OTOH, submitting the data after silent URBs would, of course, result
      in a certain delay of the actual data processing, and this is rather
      more serious problem on modern systems, in practice.
      
      This patch tries to revert the workaround and lets the URB submission
      starting at PCM trigger for the playback again.  As far as I've tested
      with various backends (native ALSA, PA, JACK, PW), I haven't seen any
      problems (famous last words :)
      
      Note that the capture stream handling needs no such workaround, since
      the capture is driven per received URB.
      
      Link: https://lore.kernel.org/r/20210601162457.4877-6-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9ce650a7