23 Feb, 2017

1 commit


15 Feb, 2017

2 commits

  • commit 37a7ea4a9b81f6a864c10a7cb0b96458df5310a3 upstream.

    snd_seq_pool_done() syncs with closing of all opened threads, but it
    aborts the wait loop with a timeout, and proceeds to the release
    resource even if not all threads have been closed. The timeout was 5
    seconds, and if you run a crazy stuff, it can exceed easily, and may
    result in the access of the invalid memory address -- this is what
    syzkaller detected in a bug report.

    As a fix, let the code graduate from naiveness, simply remove the loop
    timeout.

    BugLink: http://lkml.kernel.org/r/CACT4Y+YdhDV2H5LLzDTJDVF-qiYHUHhtRaW4rbb4gUhTCQB81w@mail.gmail.com
    Reported-by: Dmitry Vyukov
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     
  • commit 4842e98f26dd80be3623c4714a244ba52ea096a8 upstream.

    When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
    new queue element to the public list before referencing it. Thus the
    queue might be deleted before the call of snd_seq_queue_use(), and it
    results in the use-after-free error, as spotted by syzkaller.

    The fix is to reference the queue object at the right time.

    Reported-by: Dmitry Vyukov
    Signed-off-by: Takashi Iwai
    Signed-off-by: Greg Kroah-Hartman

    Takashi Iwai
     

08 Nov, 2016

2 commits

  • Currently the ALSA proc handler allows read or write even if the proc
    file were write-only or read-only. It's mostly harmless, does thing
    but allocating memory and ignores the input/output. But it doesn't
    tell user about the invalid use, and it's confusing and inconsistent
    in comparison with other proc files.

    This patch adds some sanity checks and let the proc handler returning
    an -EIO error when the invalid read/write is performed.

    Cc: # v4.2+
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • The ALSA proc handler allows currently the write in the unlimited size
    until kmalloc() fails. But basically the write is supposed to be only
    for small inputs, mostly for one line inputs, and we don't have to
    handle too large sizes at all. Since the kmalloc error results in the
    kernel warning, it's better to limit the size beforehand.

    This patch adds the limit of 16kB, which must be large enough for the
    currently existing code.

    Cc: stable@vger.kernel.org # v4.2+
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

25 Oct, 2016

1 commit

  • The recent rewrite of the sequencer time accounting using timespec64
    in the commit [3915bf294652: ALSA: seq_timer: use monotonic times
    internally] introduced a bad regression. Namely, the time reported
    back doesn't increase but goes back and forth.

    The culprit was obvious: the delta is stored to the result (cur_time =
    delta), instead of adding the delta (cur_time += delta)!

    Let's fix it.

    Fixes: 3915bf294652 ('ALSA: seq_timer: use monotonic times internally')
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571
    Reported-by: Yves Guillemot
    Cc: # v4.8+
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

13 Oct, 2016

1 commit

  • This commit is a fix for Linux 4.9-rc1.

    In former commit, a function call of compatibility layer for ALSA sequencer
    core was obsoleted by an alternative. Although, the alternative gets a
    pointer to kernel stack due to mis-programming. As a result, ALSA sequencer
    core unexpectedly refers over kernel stack.

    Reported-by: Dan Carpenter
    Fixes: 8ce8eb601c71 ("ALSA: seq: add an alternative way to handle ioctl requests")
    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

17 Sep, 2016

1 commit


13 Sep, 2016

1 commit

  • When checking value of request for copy operation, current implementation
    compares shifted value to macros, while these macros are already shifted.
    As a result, it never performs to copy from/to user space.

    This commit fixes the bug.

    Fixes: 8ce8eb601c71('ALSA: seq: add an alternative way to handle ioctl requests'
    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

11 Sep, 2016

1 commit


08 Sep, 2016

2 commits

  • When a seq-virmidi driver is initialized, it registers a rawmidi
    instance with its callback to create an associated seq kernel client.
    Currently it's done throughly in rawmidi's register_mutex context.
    Recently it was found that this may lead to a deadlock another rawmidi
    device that is being attached with the sequencer is accessed, as both
    open with the same register_mutex. This was actually triggered by
    syzkaller, as Dmitry Vyukov reported:

    ======================================================
    [ INFO: possible circular locking dependency detected ]
    4.8.0-rc1+ #11 Not tainted
    -------------------------------------------------------
    syz-executor/7154 is trying to acquire lock:
    (register_mutex#5){+.+.+.}, at: [] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341

    but task is already holding lock:
    (&grp->list_mutex){++++.+}, at: [] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&grp->list_mutex){++++.+}:
    [] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
    [] down_read+0x49/0xc0 kernel/locking/rwsem.c:22
    [< inline >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681
    [] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822
    [] > snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418
    [] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101
    [] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297
    [< inline >] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383
    [] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450
    [] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645
    [] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164
    [< inline >] __snd_device_register sound/core/device.c:162
    [] snd_device_register_all+0xad/0x110 sound/core/device.c:212
    [] snd_card_register+0xef/0x6c0 sound/core/init.c:749
    [] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123
    [] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564
    ......

    -> #0 (register_mutex#5){+.+.+.}:
    [< inline >] check_prev_add kernel/locking/lockdep.c:1829
    [< inline >] check_prevs_add kernel/locking/lockdep.c:1939
    [< inline >] validate_chain kernel/locking/lockdep.c:2266
    [] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335
    [] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
    [< inline >] __mutex_lock_common kernel/locking/mutex.c:521
    [] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621
    [] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
    [] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188
    [< inline >] subscribe_port sound/core/seq/seq_ports.c:427
    [] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510
    [] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579
    [] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480
    [] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225
    [] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440
    [] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375
    [] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281
    [] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274
    [] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
    [] soundcore_open+0x30f/0x640 sound/sound_core.c:639
    ......

    other info that might help us debug this:

    Possible unsafe locking scenario:

    CPU0 CPU1
    ---- ----
    lock(&grp->list_mutex);
    lock(register_mutex#5);
    lock(&grp->list_mutex);
    lock(register_mutex#5);

    *** DEADLOCK ***
    ======================================================

    The fix is to simply move the registration parts in
    snd_rawmidi_dev_register() to the outside of the register_mutex lock.
    The lock is needed only to manage the linked list, and it's not
    necessarily to cover the whole initialization process.

    Reported-by: Dmitry Vyukov
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • When a user timer instance is continued without the explicit start
    beforehand, the system gets eventually zero-division error like:

    divide error: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
    CPU: 1 PID: 27320 Comm: syz-executor Not tainted 4.8.0-rc3-next-20160825+ #8
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
    task: ffff88003c9b2280 task.stack: ffff880027280000
    RIP: 0010:[] [< inline >] ktime_divns include/linux/ktime.h:195
    RIP: 0010:[] [] snd_hrtimer_callback+0x1bc/0x3c0 sound/core/hrtimer.c:62
    Call Trace:

    [< inline >] __run_hrtimer kernel/time/hrtimer.c:1238
    [] __hrtimer_run_queues+0x325/0xe70 kernel/time/hrtimer.c:1302
    [] hrtimer_interrupt+0x18b/0x420 kernel/time/hrtimer.c:1336
    [] local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:933
    [] smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:957
    [] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:487

    .....

    Although a similar issue was spotted and a fix patch was merged in
    commit [6b760bb2c63a: ALSA: timer: fix division by zero after
    SNDRV_TIMER_IOCTL_CONTINUE], it seems covering only a part of
    iceberg.

    In this patch, we fix the issue a bit more drastically. Basically the
    continue of an uninitialized timer is supposed to be a fresh start, so
    we do it for user timers. For the direct snd_timer_continue() call,
    there is no way to pass the initial tick value, so we kick out for the
    uninitialized case.

    Reported-by: Dmitry Vyukov
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

06 Sep, 2016

1 commit

  • When the stream is in suspended state some applications wait
    on "Stream Pipe Error" in response to snd_pcm_avail call to
    resume the stream.

    In the current implementation snd_pcm_avail() returns zero
    when the stream is in suspended state. This causes application
    to enter in infinite loop for frames to be available.

    "Stream pipe Error" code is getting returned for read/write
    call when the stream is in suspended state. Similarly update
    snd_pcm_avail to return -ESTRPIPE.

    Signed-off-by: Jeeja KP
    Signed-off-by: Takashi Iwai

    Jeeja KP
     

02 Sep, 2016

1 commit

  • I got this with syzkaller:

    ==================================================================
    BUG: KASAN: null-ptr-deref on address 0000000000000020
    Read of size 32 by task syz-executor/22519
    CPU: 1 PID: 22519 Comm: syz-executor Not tainted 4.8.0-rc2+ #169
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2
    014
    0000000000000001 ffff880111a17a00 ffffffff81f9f141 ffff880111a17a90
    ffff880111a17c50 ffff880114584a58 ffff880114584a10 ffff880111a17a80
    ffffffff8161fe3f ffff880100000000 ffff880118d74a48 ffff880118d74a68
    Call Trace:
    [] dump_stack+0x83/0xb2
    [] kasan_report_error+0x41f/0x4c0
    [] kasan_report+0x34/0x40
    [] ? snd_timer_user_read+0x554/0x790
    [] check_memory_region+0x13e/0x1a0
    [] kasan_check_read+0x11/0x20
    [] snd_timer_user_read+0x554/0x790
    [] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
    [] ? proc_fault_inject_write+0x1c1/0x250
    [] ? next_tgid+0x2a0/0x2a0
    [] ? do_group_exit+0x108/0x330
    [] ? fsnotify+0x72a/0xca0
    [] __vfs_read+0x10e/0x550
    [] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
    [] ? do_sendfile+0xc50/0xc50
    [] ? __fsnotify_update_child_dentry_flags+0x60/0x60
    [] ? kcov_ioctl+0x56/0x190
    [] ? common_file_perm+0x2e2/0x380
    [] ? __fsnotify_parent+0x5e/0x2b0
    [] ? security_file_permission+0x86/0x1e0
    [] ? rw_verify_area+0xe5/0x2b0
    [] vfs_read+0x115/0x330
    [] SyS_read+0xd1/0x1a0
    [] ? vfs_write+0x4b0/0x4b0
    [] ? __this_cpu_preempt_check+0x1c/0x20
    [] ? __context_tracking_exit.part.4+0x3a/0x1e0
    [] ? vfs_write+0x4b0/0x4b0
    [] do_syscall_64+0x1c4/0x4e0
    [] ? syscall_return_slowpath+0x16c/0x1d0
    [] entry_SYSCALL64_slow_path+0x25/0x25
    ==================================================================

    There are a couple of problems that I can see:

    - ioctl(SNDRV_TIMER_IOCTL_SELECT), which potentially sets
    tu->queue/tu->tqueue to NULL on memory allocation failure, so read()
    would get a NULL pointer dereference like the above splat

    - the same ioctl() can free tu->queue/to->tqueue which means read()
    could potentially see (and dereference) the freed pointer

    We can fix both by taking the ioctl_lock mutex when dereferencing
    ->queue/->tqueue, since that's always held over all the ioctl() code.

    Just looking at the code I find it likely that there are more problems
    here such as tu->qhead pointing outside the buffer if the size is
    changed concurrently using SNDRV_TIMER_IOCTL_PARAMS.

    Signed-off-by: Vegard Nossum
    Cc:
    Signed-off-by: Takashi Iwai

    Vegard Nossum
     

31 Aug, 2016

1 commit

  • Currently, automatic variable of 'union ioctl_arg' type is initialized
    by designated initialization. Although, the actual effect is interpretation
    of early element of int type and initialization of 'int pversion'.
    Therefore the first field corresponding to int type is initialized to zero.
    This is against my expectation to initialize whole fields.

    This commit uses memset() to initialize the variable, instead of designated
    initialization.

    Fixes: 04a56dd8ed0d ('ALSA: seq: change ioctl command operation to get data in kernel space')
    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

29 Aug, 2016

2 commits

  • I hit this with syzkaller:

    kasan: CONFIG_KASAN_INLINE enabled
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] PREEMPT SMP KASAN
    CPU: 0 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #190
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    task: ffff88011278d600 task.stack: ffff8801120c0000
    RIP: 0010:[] [] snd_hrtimer_start+0x77/0x100
    RSP: 0018:ffff8801120c7a60 EFLAGS: 00010006
    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000007
    RDX: 0000000000000009 RSI: 1ffff10023483091 RDI: 0000000000000048
    RBP: ffff8801120c7a78 R08: ffff88011a5cf768 R09: ffff88011a5ba790
    R10: 0000000000000002 R11: ffffed00234b9ef1 R12: ffff880114843980
    R13: ffffffff84213c00 R14: ffff880114843ab0 R15: 0000000000000286
    FS: 00007f72958f3700(0000) GS:ffff88011aa00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000603001 CR3: 00000001126ab000 CR4: 00000000000006f0
    Stack:
    ffff880114843980 ffff880111eb2dc0 ffff880114843a34 ffff8801120c7ad0
    ffffffff82c81ab1 0000000000000000 ffffffff842138e0 0000000100000000
    ffff880111eb2dd0 ffff880111eb2dc0 0000000000000001 ffff880111eb2dc0
    Call Trace:
    [] snd_timer_start1+0x331/0x670
    [] snd_timer_start+0x5d/0xa0
    [] snd_timer_user_ioctl+0x88e/0x2830
    [] ? __follow_pte.isra.49+0x430/0x430
    [] ? snd_timer_pause+0x80/0x80
    [] ? do_wp_page+0x3aa/0x1c90
    [] ? put_prev_entity+0x108f/0x21a0
    [] ? snd_timer_pause+0x80/0x80
    [] do_vfs_ioctl+0x193/0x1050
    [] ? cpuacct_account_field+0x12f/0x1a0
    [] ? ioctl_preallocate+0x200/0x200
    [] ? syscall_trace_enter+0x3cf/0xdb0
    [] ? __context_tracking_exit.part.4+0x9a/0x1e0
    [] ? exit_to_usermode_loop+0x190/0x190
    [] ? check_preemption_disabled+0x37/0x1e0
    [] ? security_file_ioctl+0x89/0xb0
    [] SyS_ioctl+0x8f/0xc0
    [] ? do_vfs_ioctl+0x1050/0x1050
    [] do_syscall_64+0x1c4/0x4e0
    [] entry_SYSCALL64_slow_path+0x25/0x25
    Code: c7 c7 c4 b9 c8 82 48 89 d9 4c 89 ee e8 63 88 7f fe e8 7e 46 7b fe 48 8d 7b 48 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 b6 04 02 84 c0 74 04 84 c0 7e 65 80 7b 48 00 74 0e e8 52 46
    RIP [] snd_hrtimer_start+0x77/0x100
    RSP
    ---[ end trace 5955b08db7f2b029 ]---

    This can happen if snd_hrtimer_open() fails to allocate memory and
    returns an error, which is currently not checked by snd_timer_open():

    ioctl(SNDRV_TIMER_IOCTL_SELECT)
    - snd_timer_user_tselect()
    - snd_timer_close()
    - snd_hrtimer_close()
    - (struct snd_timer *) t->private_data = NULL
    - snd_timer_open()
    - snd_hrtimer_open()
    - kzalloc() fails; t->private_data is still NULL

    ioctl(SNDRV_TIMER_IOCTL_START)
    - snd_timer_user_start()
    - snd_timer_start()
    - snd_timer_start1()
    - snd_hrtimer_start()
    - t->private_data == NULL // boom

    Signed-off-by: Vegard Nossum
    Cc:
    Signed-off-by: Takashi Iwai

    Vegard Nossum
     
  • I got this:

    divide error: 0000 [#1] PREEMPT SMP KASAN
    CPU: 1 PID: 1327 Comm: a.out Not tainted 4.8.0-rc2+ #189
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014
    task: ffff8801120a9580 task.stack: ffff8801120b0000
    RIP: 0010:[] [] snd_hrtimer_callback+0x1da/0x3f0
    RSP: 0018:ffff88011aa87da8 EFLAGS: 00010006
    RAX: 0000000000004f76 RBX: ffff880112655e88 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: ffff880112655ea0 RDI: 0000000000000001
    RBP: ffff88011aa87e00 R08: ffff88013fff905c R09: ffff88013fff9048
    R10: ffff88013fff9050 R11: 00000001050a7b8c R12: ffff880114778a00
    R13: ffff880114778ab4 R14: ffff880114778b30 R15: 0000000000000000
    FS: 00007f071647c700(0000) GS:ffff88011aa80000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000603001 CR3: 0000000112021000 CR4: 00000000000006e0
    Stack:
    0000000000000000 ffff880114778ab8 ffff880112655ea0 0000000000004f76
    ffff880112655ec8 ffff880112655e80 ffff880112655e88 ffff88011aa98fc0
    00000000b97ccf2b dffffc0000000000 ffff88011aa98fc0 ffff88011aa87ef0
    Call Trace:

    [] __hrtimer_run_queues+0x347/0xa00
    [] ? snd_hrtimer_close+0x130/0x130
    [] ? retrigger_next_event+0x1b0/0x1b0
    [] ? hrtimer_interrupt+0x136/0x4b0
    [] hrtimer_interrupt+0x1b0/0x4b0
    [] local_apic_timer_interrupt+0x6e/0xf0
    [] ? kvm_guest_apic_eoi_write+0x13/0xc0
    [] smp_apic_timer_interrupt+0x76/0xa0
    [] apic_timer_interrupt+0x8c/0xa0

    [] ? _raw_spin_unlock_irqrestore+0x2c/0x60
    [] snd_timer_start1+0xdd/0x670
    [] snd_timer_continue+0x45/0x80
    [] snd_timer_user_ioctl+0x1030/0x2830
    [] ? __follow_pte.isra.49+0x430/0x430
    [] ? snd_timer_pause+0x80/0x80
    [] ? do_wp_page+0x3aa/0x1c90
    [] ? handle_mm_fault+0xbc8/0x27f0
    [] ? __pmd_alloc+0x370/0x370
    [] ? snd_timer_pause+0x80/0x80
    [] do_vfs_ioctl+0x193/0x1050
    [] ? ioctl_preallocate+0x200/0x200
    [] ? syscall_trace_enter+0x3cf/0xdb0
    [] ? __context_tracking_exit.part.4+0x9a/0x1e0
    [] ? exit_to_usermode_loop+0x190/0x190
    [] ? check_preemption_disabled+0x37/0x1e0
    [] ? security_file_ioctl+0x89/0xb0
    [] SyS_ioctl+0x8f/0xc0
    [] ? do_vfs_ioctl+0x1050/0x1050
    [] do_syscall_64+0x1c4/0x4e0
    [] entry_SYSCALL64_slow_path+0x25/0x25
    Code: e8 fc 42 7b fe 8b 0d 06 8a 50 03 49 0f af cf 48 85 c9 0f 88 7c 01 00 00 48 89 4d a8 e8 e0 42 7b fe 48 8b 45 c0 48 8b 4d a8 48 99 f7 f9 49 01 c7 e8 cb 42 7b fe 48 8b 55 d0 48 b8 00 00 00 00
    RIP [] snd_hrtimer_callback+0x1da/0x3f0
    RSP
    ---[ end trace 6aa380f756a21074 ]---

    The problem happens when you call ioctl(SNDRV_TIMER_IOCTL_CONTINUE) on a
    completely new/unused timer -- it will have ->sticks == 0, which causes a
    divide by 0 in snd_hrtimer_callback().

    Signed-off-by: Vegard Nossum
    Cc:
    Signed-off-by: Takashi Iwai

    Vegard Nossum
     

22 Aug, 2016

5 commits

  • Reuse existing functionality from memdup_user() instead of keeping
    duplicate source code.

    This issue was detected by using the Coccinelle software.

    Signed-off-by: Markus Elfring
    Acked-by: Vinod Koul
    Signed-off-by: Takashi Iwai

    Markus Elfring
     
  • Former commits change existent functions so that they don't handle data in
    kernel space. Copying from/to userspace is done outside of the functions,
    thus no need to change address limit of running task.

    This commit obsoletes get_fs()/set_fs() and applies corresponding changes.

    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     
  • In previous commit, a new table for functions with data in kernel space
    is added to replace current table.

    This commit changes existent functions to fit the table. These functions
    are added to the new table and removed from the old table.

    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     
  • ALSA sequencer is designed with two types of clients; application and
    kernel. Operations for each ioctl command should handle data in both of
    user space and kernel space, while current implementation just allows them
    to handle data in user space. Data in kernel space is handled with change
    of address limit of running tasks.

    This commit adds a new table to map ioctl commands to corresponding
    functions. The functions get data in kernel space. Helper functions to
    operate kernel and application clients seek entries from the table.
    Especially, the helper function for application is responsible for coping
    from user space to kernel space or vise versa.

    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     
  • This kernel API is used by kernel implementation. Currently, it's used for
    kernel clients of ALSA sequencer, while it can be used for application
    clients. The difference is just on address spaces of argument. In short,
    this kernel API can be available for application client with data in kernel
    space.

    This commit adds a document about this.

    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

26 Jul, 2016

1 commit

  • ASoC: Updates for v4.8

    Not really any framework work this time around (though we have seen one
    of the Analog Devices drivers move more to the clock API which is good
    to see) but rather a lot of new drivers:

    - Lots of updates for the Intel drivers, mostly board support and bug
    fixing, and to the NAU8825 driver.
    - Work on generalizing bits of simple-card to allow more code sharing
    with the Renesas rsrc-card (which can't use simple-card due to DPCM).
    - Removal of the Odroid X2 driver due to replacement with simple-card.
    - Support for several new Mediatek platforms and associated boards.
    - New drivers for Allwinner A10, Analog Devices ADAU7002, Broadcom
    Cygnus, Cirrus Logic CS35L33 and CS53L30, Maxim MAX8960 and MAX98504,
    Realtek RT5514 and Wolfson WM8758

    Takashi Iwai
     

25 Jul, 2016

2 commits


08 Jul, 2016

2 commits

  • The chmap ctls assigned to PCM streams are freed in the PCM disconnect
    callback. However, since the disconnect callback isn't called when
    the card gets freed before registering, the chmap ctls may still be
    left assigned. They are eventually freed together with other ctls,
    but it may cause an Oops at pcm_chmap_ctl_private_free(), as the
    function refers to the assigned PCM stream, while the PCM objects have
    been already freed beforehand.

    The fix is to free the chmap ctls also at PCM free callback, not only
    at PCM disconnect.

    Reported-by: Laxminath Kasam
    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     
  • snd_ctl_remove() has a notification for the removal event. It's
    superfluous when done during the device got disconnected. Although
    the notification itself is mostly harmless, it may potentially be
    harmful, and should be suppressed. Actually some components PCM may
    free ctl elements during the disconnect or free callbacks, thus it's
    no theoretical issue.

    This patch adds the check of card->shutdown flag for avoiding
    unnecessary notifications after (or during) the disconnect.

    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

07 Jul, 2016

1 commit

  • The 'dimen' field in struct snd_ctl_elem_info is used to compose all of
    members in the element as multi-dimensional matrix. The field has four
    members. Each member represents the width in each dimension level by
    element member unit. For example, if the members consist of typical
    two dimensional matrix, the dimen[0] represents the number of rows
    and dimen[1] represents the number of columns (or vise-versa).

    The total members in the matrix should be exactly the same as the number
    of members in the element, while current implementation has no validator
    of this information. In a view of userspace applications, the information
    must be valid so that it cannot cause any bugs such as buffer-over-run.

    This commit adds a validator of dimension information for userspace
    applications which add new element sets. When they add the element sets
    with wrong dimension information, they receive -EINVAL.

    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

04 Jul, 2016

1 commit

  • The user timer tu->qused counter may go to a negative value when
    multiple concurrent reads are performed since both the check and the
    decrement of tu->qused are done in two individual locked contexts.
    This results in bogus read outs, and the endless loop in the
    user-space side.

    The fix is to move the decrement of the tu->qused counter into the
    same spinlock context as the zero-check of the counter.

    Cc:
    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

18 Jun, 2016

1 commit

  • The sequencer client manager reports timestamps in units of unsigned
    32-bit seconds/nanoseconds, but that does not suffer from the y2038
    overflow because it stores only the delta since the 'last_update'
    time was recorded.

    However, the use of the do_gettimeofday() function is problematic
    and we have to replace it to avoid the overflow on on 32-bit
    architectures.

    This uses 'struct timespec64' to record 'last_update', and changes
    the code to use monotonic timestamps that do not suffer from leap
    seconds and settimeofday updates.

    As a side-effect, the code can now use the timespec64_sub() helper
    and become more readable and also avoid a multiplication to convert
    from microseconds to nanoseconds.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Takashi Iwai

    Arnd Bergmann
     

15 Jun, 2016

1 commit

  • Replace the in order struct initialisation style with explicit field
    style.

    The Coccinelle semantic patch used to make this change is as follows:

    @decl@
    identifier i1,fld;
    type T;
    field list[n] fs;
    @@

    struct i1 {
    fs
    T fld;
    ...};

    @@
    identifier decl.i1,i2,decl.fld;
    expression e;
    position bad.p, bad.fix;
    @@

    struct i1 i2@p = { ...,
    + .fld = e
    - e@fix
    ,...};

    Also, removed some unnecessary comments.

    Signed-off-by: Amitoj Kaur Chawla
    Signed-off-by: Takashi Iwai

    Amitoj Kaur Chawla
     

13 Jun, 2016

1 commit

  • Currently, the avail IOCTL doesn't pass any error status, which
    means typically on error it simply shows no data available. This
    can lead to situations where user-space is waiting indefinitely
    for data that will never come as the DSP has suffered an
    unrecoverable error.

    Add snd_compr_stop_error which end drivers can call to indicate
    the stream has suffered an unrecoverable error and stop it. The
    avail and poll IOCTLs are then updated to report if the stream is
    in an error state to user-space. Allowing the error to propagate
    out. Processing of the actual snd_compr_stop needs to be deferred
    to a worker thread as the end driver may detect the errors during
    an existing operation callback.

    Signed-off-by: Charles Keepax
    Acked-by: Vinod Koul
    Signed-off-by: Mark Brown

    Charles Keepax
     

16 May, 2016

1 commit


13 May, 2016

2 commits


10 May, 2016

1 commit

  • When snd_pcm_add_chmap_ctls() is called to the PCM stream to which a
    chmap has been already assigned, it returns as an error due to the
    conflicting snd_ctl_add() result. However, this also clears the
    already assigned chmap_kctl field via pcm_chmap_ctl_private_free(),
    and becomes inconsistent in the later operation.

    This patch adds the check of the conflicting chmap kctl before
    actually trying to allocate / assign. The check failure is treated as
    a kernel warning, as the double call of snd_pcm_add_chmap_ctls() is
    basically a driver bug and having the stack trace would help
    developers to figure out the bad code path.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

09 May, 2016

4 commits