1. 07 Jun, 2017 6 commits
    • Takashi Iwai's avatar
      ALSA: timer: Improve user queue reallocation · 890e2cb5
      Takashi Iwai authored
      ALSA timer may reallocate the user queue upon request, and it happens
      at three places for now: at opening, at SNDRV_TIMER_IOCTL_PARAMS, and
      at SNDRV_TIMER_IOCTL_SELECT.  However, the last one,
      snd_timer_user_tselect(), doesn't need to reallocate the buffer since
      it doesn't change the queue size.  It does just because tu->tread
      might have been changed before starting the timer.
      
      Instead of *_SELECT ioctl, we should reallocate the queue at
      SNDRV_TIMER_IOCTL_TREAD; then the timer is guaranteed to be stopped,
      thus we can reassign the buffer more safely.
      
      This patch implements that with a slight code refactoring.
      Essentially, the patch achieves:
      - Introduce realloc_user_queue() for (re-)allocating the ring buffer,
        and call it from all places.  Also, realloc_user_queue() uses
        kcalloc() for avoiding possible leaks.
      - Add the buffer reallocation at SNDRV_TIMER_IOCTL_TREAD.  When it
        fails, tu->tread is restored to the old value, too.
      - Drop the buffer reallocation at snd_timer_user_tselect().
      Tested-by: default avatarAlexander Potapenko <glider@google.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      890e2cb5
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 4c7aba46
      Takashi Iwai authored
      For applying more ALSA timer cleanups.
      4c7aba46
    • Takashi Iwai's avatar
      ALSA: timer: Fix missing queue indices reset at SNDRV_TIMER_IOCTL_SELECT · ba3021b2
      Takashi Iwai authored
      snd_timer_user_tselect() reallocates the queue buffer dynamically, but
      it forgot to reset its indices.  Since the read may happen
      concurrently with ioctl and snd_timer_user_tselect() allocates the
      buffer via kmalloc(), this may lead to the leak of uninitialized
      kernel-space data, as spotted via KMSAN:
      
        BUG: KMSAN: use of unitialized memory in snd_timer_user_read+0x6c4/0xa10
        CPU: 0 PID: 1037 Comm: probe Not tainted 4.11.0-rc5+ #2739
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
        Call Trace:
         __dump_stack lib/dump_stack.c:16
         dump_stack+0x143/0x1b0 lib/dump_stack.c:52
         kmsan_report+0x12a/0x180 mm/kmsan/kmsan.c:1007
         kmsan_check_memory+0xc2/0x140 mm/kmsan/kmsan.c:1086
         copy_to_user ./arch/x86/include/asm/uaccess.h:725
         snd_timer_user_read+0x6c4/0xa10 sound/core/timer.c:2004
         do_loop_readv_writev fs/read_write.c:716
         __do_readv_writev+0x94c/0x1380 fs/read_write.c:864
         do_readv_writev fs/read_write.c:894
         vfs_readv fs/read_write.c:908
         do_readv+0x52a/0x5d0 fs/read_write.c:934
         SYSC_readv+0xb6/0xd0 fs/read_write.c:1021
         SyS_readv+0x87/0xb0 fs/read_write.c:1018
      
      This patch adds the missing reset of queue indices.  Together with the
      previous fix for the ioctl/read race, we cover the whole problem.
      Reported-by: default avatarAlexander Potapenko <glider@google.com>
      Tested-by: default avatarAlexander Potapenko <glider@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      ba3021b2
    • Takashi Iwai's avatar
      ALSA: timer: Fix race between read and ioctl · d11662f4
      Takashi Iwai authored
      The read from ALSA timer device, the function snd_timer_user_tread(),
      may access to an uninitialized struct snd_timer_user fields when the
      read is concurrently performed while the ioctl like
      snd_timer_user_tselect() is invoked.  We have already fixed the races
      among ioctls via a mutex, but we seem to have forgotten the race
      between read vs ioctl.
      
      This patch simply applies (more exactly extends the already applied
      range of) tu->ioctl_lock in snd_timer_user_tread() for closing the
      race window.
      Reported-by: default avatarAlexander Potapenko <glider@google.com>
      Tested-by: default avatarAlexander Potapenko <glider@google.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d11662f4
    • Takashi Sakamoto's avatar
      ALSA: fireface: constify ALSA specific operations · d2dc2a96
      Takashi Sakamoto authored
      ALSA fireface driver has ALSA specific operations for MIDI/PCM data.
      Structured data for the operations can be constified. Additionally,
      The structured data can be function local.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d2dc2a96
    • Takashi Sakamoto's avatar
      ALSA: firewire: process packets in 'struct snd_pcm_ops.ack' callback · 875becf8
      Takashi Sakamoto authored
      In recent commit for ALSA PCM core, some arrangement is done for
      'struct snd_pcm_ops.ack' callback. This is called when appl_ptr is
      explicitly moved in intermediate buffer for PCM frames, except for
      some cases described later.
      
      For drivers in ALSA firewire stack, usage of this callback has a merit to
      reduce latency between time of PCM frame queueing and handling actual
      packets in recent isochronous cycle, because no need to wait for software
      IRQ context from isochronous context of OHCI 1394.
      
      If this works well in a case that mapped page frame is used for the
      intermediate buffer, user process should execute some commands for ioctl(2)
      to tell the number of handled PCM frames in the intermediate buffer just
      after handling them. Therefore, at present, with a combination of below
      conditions, this doesn't work as expected and user process should wait for
      the software IRQ context as usual:
       - when ALSA PCM core judges page frame mapping is available for status
         data (struct snd_pcm_mmap_status) and control data
         (struct snd_pcm_mmap_control).
       - user process handles PCM frames by loop just with 'snd_pcm_mmap_begin()'
         and 'snd_pcm_mmap_commit()'.
       - user process uses PCM hw plugin in alsa-lib to operate I/O without
         'sync_ptr_ioctl' option.
      
      Unfortunately, major use case include these three conditions.
      Signed-off-by: default avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      875becf8
  2. 06 Jun, 2017 3 commits
  3. 02 Jun, 2017 26 commits
  4. 01 Jun, 2017 1 commit
    • Takashi Iwai's avatar
      ALSA: hda - Fix applying MSI dual-codec mobo quirk · d2c3b14e
      Takashi Iwai authored
      The previous commit [63691587: ALSA: hda - Apply dual-codec quirk
      for MSI Z270-Gaming mobo] attempted to apply the existing dual-codec
      quirk for a MSI mobo.  But it turned out that this isn't applied
      properly due to the MSI-vendor quirk before this entry.  I overlooked
      such two MSI entries just because they were put in the wrong position,
      although we have a list ordered by PCI SSID numbers.
      
      This patch fixes it by rearranging the unordered entries.
      
      Fixes: 63691587 ("ALSA: hda - Apply dual-codec quirk for MSI Z270-Gaming mobo")
      Reported-by: default avatarRudolf Schmidt <info@rudolfschmidt.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      d2c3b14e
  5. 31 May, 2017 3 commits
  6. 30 May, 2017 1 commit