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 <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ktime is a union because the initial implementation stored the time in
scalar nanoseconds on 64 bit machine and in a endianess optimized timespec
variant for 32bit machines. The Y2038 cleanup removed the timespec variant
and switched everything to scalar nanoseconds. The union remained, but
become completely pointless.
Get rid of the union and just keep ktime_t as simple typedef of type s64.
The conversion was done with coccinelle and some manual mopping up.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
No dramatic changes are found in this development cycle, but as usual,
many commits are applied in a wide range of drivers.
Most of big changes are in ASoC, where a few bits of framework work
and quite a lot of cleanups and improvements to existing code have
been done. The rest are usual stuff, a few HD-audio and USB-audio
quirks and fixes, as well as the drop of kthread usages in the whole
subsystem.
Below are some highlights:
ASoC:
- Support for stereo DAPM controls
- Some initial work on the of-graph sound card
- regmap conversions of the remaining AC'97 drivers
- A new version of the topology ABI; this should be backward compatible
- Updates / cleanups of rsnd, sunxi, sti, nau8825, samsung, arizona,
Intel skylake, atom-sst
- New drivers for Cirrus Logic CS42L42, Qualcomm MSM8916-WCD, and
Realtek RT5665
USB-audio:
- Yet another race fix at disconnection
- Tolerated packet size calculation for some Android devices
- Quirks for Axe-Fx II, QuickCam, TEAC 501/503
HD-audio:
- Improvement of Dell pin fixup mapping
- Quirks for HP Z1 Gen3, Alienware 15 R2 2016 and ALC622 headset mic
Misc:
- Replace all kthread usages with simple works
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJYUGNQAAoJEGwxgFQ9KSmkc3kP/jS5EDPWb6dwqdlZomT0lumR
flpvLLo6TWTi9CS8MkC1hPHbR+3LGPMUL8Wwf2cVb06dvKpUHa5P3Wq6lMm6T9wO
1ExhnHeDEDfGXop3/EuADmpRsfsV+z/PpWYmGB0vkoyPTg7e3xQRA6Im6p6IMi45
pnvEaSe18oEidqzAxaBgBFTdoNyaD9zrPL5J9Jh0/JCZ/kSmY6hhI+hlTjjOKCR6
fs4ge2WreonAKbhfOE61eE2KDnQA4II/2JUoPA42wZOat9ukb8DiErgHoFgsWTtE
h+/ZN5Qj3dweP3+NIKsWrmfC6qzTt9OnUNPB2O0A+UYmAMQBjBz9KVxW1FHyTqBp
ewATtvCNIQs+uPMaO/Q/Qo3ZkKLf/W7o/Dt2u/orSrnQ2plKgIOiHJodhXlTrOWm
szF+qJq0xRB7+/dZa+gDjGPAjirr6n3Fv7wrJmqfyF0hLaIEy4wa2Rd/IAZ9Ar46
5S4prL2Ba1CKf1YV27DR1bjUTAonlApfczNp+urCGQJCfZ0kQOAhZJQ/mbMOgSDS
KEC0vY6NLr88b19OETS4oQZ0ixxIAm8hwAle6z39GGhGZ8JWH5+JRzy8emVh2bss
lpFLFHLwK+a+JHxmnOniJW9AlC8I7hVqfS63qaTXfvDnMMcRd5fMgniZt8bTWc2/
F5hsE83JUlcA8Owfyoca
=WZeb
-----END PGP SIGNATURE-----
Merge tag 'sound-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"No dramatic changes are found in this development cycle, but as usual,
many commits are applied in a wide range of drivers.
Most of big changes are in ASoC, where a few bits of framework work
and quite a lot of cleanups and improvements to existing code have
been done. The rest are usual stuff, a few HD-audio and USB-audio
quirks and fixes, as well as the drop of kthread usages in the whole
subsystem.
Below are some highlights:
ASoC:
- support for stereo DAPM controls
- some initial work on the of-graph sound card
- regmap conversions of the remaining AC'97 drivers
- a new version of the topology ABI; this should be backward
compatible
- updates / cleanups of rsnd, sunxi, sti, nau8825, samsung, arizona,
Intel skylake, atom-sst
- new drivers for Cirrus Logic CS42L42, Qualcomm MSM8916-WCD, and
Realtek RT5665
USB-audio:
- yet another race fix at disconnection
- tolerated packet size calculation for some Android devices
- quirks for Axe-Fx II, QuickCam, TEAC 501/503
HD-audio:
- improvement of Dell pin fixup mapping
- quirks for HP Z1 Gen3, Alienware 15 R2 2016 and ALC622 headset mic
Misc:
- replace all kthread usages with simple works"
* tag 'sound-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (296 commits)
ALSA: hiface: Fix M2Tech hiFace driver sampling rate change
ALSA: usb-audio: Eliminate noise at the start of DSD playback.
ALSA: usb-audio: Add native DSD support for TEAC 501/503 DAC
ASoC: wm_adsp: wm_adsp_buf_alloc should use kfree in error path
ASoC: topology: avoid uninitialized kcontrol_type
ALSA: usb-audio: Add QuickCam Communicate Deluxe/S7500 to volume_control_quirks
ALSA: usb-audio: add implicit fb quirk for Axe-Fx II
ASoC: zte: spdif: correct ZX_SPDIF_CLK_RAT define
ASoC: zte: spdif and i2s drivers are not zx296702 specific
ASoC: rsnd: setup BRGCKR/BRRA/BRRB when starting
ASoC: rsnd: enable/disable ADG when suspend/resume timing
ASoC: rsnd: tidyup ssi->usrcnt counter check in hw_params
ALSA: cs46xx: add a new line
ASoC: Intel: update bxt_da7219_max98357a to support quad ch dmic capture
ASoC: nau8825: disable sinc filter for high THD of ADC
ALSA: usb-audio: more tolerant packetsize
ALSA: usb-audio: avoid setting of sample rate multiple times on bus
ASoC: cs35l34: Simplify the logic to set CS35L34_MCLK_CTL setting
ALSA: hda - Gate the mic jack on HP Z1 Gen3 AiO
ALSA: hda: when comparing pin configurations, ignore assoc in addition to seq
...
Commit 4bcc595ccd ("printk: reinstate KERN_CONT for printing
continuation lines") allows to define more message headers for a single
message. The motivation is that continuous lines might get mixed.
Therefore it make sense to define the right log level for every piece of
a cont line.
This patch allows to copy only the real message level. We should ignore
KERN_CONT because <filename:line> is added for each message. By other
words, we want to know where each piece of the line comes from.
[pmladek@suse.com: fix a check of the valid message level]
Link: http://lkml.kernel.org/r/20161111183444.GE2145@dhcp128.suse.cz
Link: http://lkml.kernel.org/r/1478695291-12169-5-git-send-email-pmladek@suse.com
Signed-off-by: Petr Mladek <pmladek@suse.com>
Cc: Joe Perches <joe@perches.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Jason Wessel <jason.wessel@windriver.com>
Cc: Jaroslav Kysela <perex@perex.cz>
Cc: Takashi Iwai <tiwai@suse.com>
Cc: Chris Mason <clm@fb.com>
Cc: Josef Bacik <jbacik@fb.com>
Cc: David Sterba <dsterba@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: <stable@vger.kernel.org> # v4.2+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <tiwai@suse.de>
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: 3915bf2946 ('ALSA: seq_timer: use monotonic times internally')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571
Reported-by: Yves Guillemot <yc.guillemot@wanadoo.fr>
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <dan.carpenter@oracle.com>
Fixes: 8ce8eb601c ("ALSA: seq: add an alternative way to handle ioctl requests")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix a missing \n in a pr_debug message and move the \n to the end
of a pr_err message.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
but task is already holding lock:
(&grp->list_mutex){++++.+}, at: [<ffffffff850138bb>] 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){++++.+}:
[<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
[<ffffffff863f6199>] down_read+0x49/0xc0 kernel/locking/rwsem.c:22
[< inline >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681
[<ffffffff85005c5e>] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822
[<ffffffff85006e96>] > snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418
[<ffffffff85012c52>] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101
[<ffffffff84fff70a>] 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
[<ffffffff8502d29f>] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450
[<ffffffff84fd208c>] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645
[<ffffffff84f816d3>] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164
[< inline >] __snd_device_register sound/core/device.c:162
[<ffffffff84f8235d>] snd_device_register_all+0xad/0x110 sound/core/device.c:212
[<ffffffff84f7546f>] snd_card_register+0xef/0x6c0 sound/core/init.c:749
[<ffffffff85040b7f>] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123
[<ffffffff833ebf7b>] 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
[<ffffffff814791f4>] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335
[<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746
[< inline >] __mutex_lock_common kernel/locking/mutex.c:521
[<ffffffff863f0ef1>] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621
[<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341
[<ffffffff8502e7c7>] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188
[< inline >] subscribe_port sound/core/seq/seq_ports.c:427
[<ffffffff85013cc7>] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510
[<ffffffff85015da9>] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579
[<ffffffff850079b8>] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480
[<ffffffff84ffe9e4>] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225
[<ffffffff84ffeae8>] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440
[<ffffffff85027664>] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375
[<ffffffff85023d67>] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281
[<ffffffff8501b0a8>] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274
[<ffffffff85019d8a>] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138
[<ffffffff84f7040f>] 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 <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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:[<ffffffff858e1a6c>] [< inline >] ktime_divns include/linux/ktime.h:195
RIP: 0010:[<ffffffff858e1a6c>] [<ffffffff858e1a6c>] snd_hrtimer_callback+0x1bc/0x3c0 sound/core/hrtimer.c:62
Call Trace:
<IRQ>
[< inline >] __run_hrtimer kernel/time/hrtimer.c:1238
[<ffffffff81504335>] __hrtimer_run_queues+0x325/0xe70 kernel/time/hrtimer.c:1302
[<ffffffff81506ceb>] hrtimer_interrupt+0x18b/0x420 kernel/time/hrtimer.c:1336
[<ffffffff8126d8df>] local_apic_timer_interrupt+0x6f/0xe0 arch/x86/kernel/apic/apic.c:933
[<ffffffff86e13056>] smp_apic_timer_interrupt+0x76/0xa0 arch/x86/kernel/apic/apic.c:957
[<ffffffff86e1210c>] apic_timer_interrupt+0x8c/0xa0 arch/x86/entry/entry_64.S:487
<EOI>
.....
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 <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <jeeja.kp@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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:
[<ffffffff81f9f141>] dump_stack+0x83/0xb2
[<ffffffff8161fe3f>] kasan_report_error+0x41f/0x4c0
[<ffffffff8161ff74>] kasan_report+0x34/0x40
[<ffffffff82c84b54>] ? snd_timer_user_read+0x554/0x790
[<ffffffff8161e79e>] check_memory_region+0x13e/0x1a0
[<ffffffff8161e9c1>] kasan_check_read+0x11/0x20
[<ffffffff82c84b54>] snd_timer_user_read+0x554/0x790
[<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
[<ffffffff817d0831>] ? proc_fault_inject_write+0x1c1/0x250
[<ffffffff817d0670>] ? next_tgid+0x2a0/0x2a0
[<ffffffff8127c278>] ? do_group_exit+0x108/0x330
[<ffffffff8174653a>] ? fsnotify+0x72a/0xca0
[<ffffffff81674dfe>] __vfs_read+0x10e/0x550
[<ffffffff82c84600>] ? snd_timer_user_info_compat.isra.5+0x2b0/0x2b0
[<ffffffff81674cf0>] ? do_sendfile+0xc50/0xc50
[<ffffffff81745e10>] ? __fsnotify_update_child_dentry_flags+0x60/0x60
[<ffffffff8143fec6>] ? kcov_ioctl+0x56/0x190
[<ffffffff81e5ada2>] ? common_file_perm+0x2e2/0x380
[<ffffffff81746b0e>] ? __fsnotify_parent+0x5e/0x2b0
[<ffffffff81d93536>] ? security_file_permission+0x86/0x1e0
[<ffffffff816728f5>] ? rw_verify_area+0xe5/0x2b0
[<ffffffff81675355>] vfs_read+0x115/0x330
[<ffffffff81676371>] SyS_read+0xd1/0x1a0
[<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
[<ffffffff82001c2c>] ? __this_cpu_preempt_check+0x1c/0x20
[<ffffffff8150455a>] ? __context_tracking_exit.part.4+0x3a/0x1e0
[<ffffffff816762a0>] ? vfs_write+0x4b0/0x4b0
[<ffffffff81005524>] do_syscall_64+0x1c4/0x4e0
[<ffffffff810052fc>] ? syscall_return_slowpath+0x16c/0x1d0
[<ffffffff83c3276a>] 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 <vegard.nossum@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: 04a56dd8ed ('ALSA: seq: change ioctl command operation to get data in kernel space')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <elfring@users.sourceforge.net>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJXli6yAAoJECTWi3JdVIfQgmkH/RIfbuCuGJCspFNZ3Gv/ORoX
oRcUILFd/74FRhQ+ax65Vg/Sn1P/p9dSLspRmZt/pjR37vr/b6BlZSLXgCEqVgIr
OjYi6ixcEeGyfIvWUH77nYgnUGT62XVJPfQC/2r8DsYI2bWw6tQGA/rCE2h9cl0N
JoeoGghcNoxS7zZzhgoyTX6B1FoQjJiHML6ApOvpGJWr87dPv1nbJHVBrYOPMr4X
4l/oVzOIVDmhRQtYPAWTXQzDNhVrLPxs8sgd/oV41Jl4gHRW4EPivjUBCWxQKPFy
Tf98Q7058eqcFn/egO5lsvzC0kQdiKEXpSRfol4VAU6LAvGxAYDbaIh8cBy29P4=
=nQWb
-----END PGP SIGNATURE-----
Merge tag 'asoc-v4.8' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
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
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 <b_lkasam@codeaurora.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <arnd@arndb.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <amitoj1606@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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 <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The updates this time around are almost all driver code:
- Further slow progress on the topology code.
- Substantial updates and improvements for the da7219, es8328, fsl-ssi
Intel and rcar drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJXOao7AAoJECTWi3JdVIfQ3EQH/1Z4nukvcOeZgVN/4K9b27t2
LYSyPH4+7XiDsi24UAyxZWls625t+1XRtolS0yHYY+IMObkeH/T+StTirDG4C1Mv
0uw/lEs5XmkSPFMad2fDcVXhf+D6EsvuLZ24qLKhoi8TyePv6GRvYapitE4dAI7Z
bBwjT+f9r1qSMJvfCmqit8zDneDFMKd7oqPmBW6NpFri5/ksn1KUnd/zOGu2SlSd
R01Oa2VbRDGj8/Zzu5MORvgLLucxTqtAFYeF3T52M5oc33IBWvbha4fk/BDOswbz
H9S3vHyakmbZgXnnGMTp4qz0bxA76YaHzjtqgGUEMbigHTsB0PP5TtII3i5LkaY=
=Zsr1
-----END PGP SIGNATURE-----
Merge tag 'asoc-v4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v4.7
The updates this time around are almost all driver code:
- Further slow progress on the topology code.
- Substantial updates and improvements for the da7219, es8328, fsl-ssi
Intel and rcar drivers.
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 <tiwai@suse.de>
A switch statement looks a bit cleaner than an if statement
spread over 3 lines, as such update this to a switch.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We can't return a negative error code from the poll callback the return
type is unsigned and is checked against the poll specific flags we need
to return POLLERR if we encounter an error.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
stream can't be NULL here as we have just taken the address of it, so no
need for the check.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We have a function that returns the appropriate flags for the stream
direction, so we should use it.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We can't return a negative error code from the poll callback the return
type is unsigned and is checked against the poll specific flags we need
to return POLLERR if we encounter an error.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The stack object “r1” has a total size of 32 bytes. Its field
“event” and “val” both contain 4 bytes padding. These 8 bytes
padding bytes are sent to user without being initialized.
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The stack object “r1” has a total size of 32 bytes. Its field
“event” and “val” both contain 4 bytes padding. These 8 bytes
padding bytes are sent to user without being initialized.
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The stack object “tread” has a total size of 32 bytes. Its field
“event” and “val” both contain 4 bytes padding. These 8 bytes
padding bytes are sent to user without being initialized.
Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
dmaengine_pcm currently only supports setups where FIFO reads/writes
correspond to exactly one sample, eg 16-bit sample data is transferred
via 16-bit FIFO accesses, 32-bit data via 32-bit accesses.
This patch adds support for setups with fixed width FIFOs where
multiple samples are packed into a larger word.
For example setups with a 32-bit wide FIFO register that expect
16-bit sample transfers to be done with the left+right sample data
packed into a 32-bit word.
Support for packed transfers is controlled via the
SND_DMAENGINE_PCM_DAI_FLAG_PACK flag in snd_dmaengine_dai_dma_data.flags
If this flag is set dmaengine_pcm doesn't put any restriction on the
supported formats and sets the DMA transfer width to undefined.
This means control over the constraints is now transferred to the DAI
driver and it's responsible to provide proper configuration and
check for possible corner cases that aren't handled by the ALSA core.
Signed-off-by: Matthias Reichl <hias@horus.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Tested-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch tries to address the still remaining issues in ALSA hrtimer
driver:
- Spurious use-after-free was detected in hrtimer callback
- Incorrect rescheduling due to delayed start
- WARN_ON() is triggered in hrtimer_forward() invoked in hrtimer
callback
The first issue happens only when the new timer is scheduled even
while hrtimer is being closed. It's related with the second and third
items; since ALSA timer core invokes hw.start callback during hrtimer
interrupt, this may result in the explicit call of hrtimer_start().
Also, the similar problem is seen for the stop; ALSA timer core
invokes hw.stop callback even in the hrtimer handler, too. Since we
must not call the synced hrtimer_cancel() in such a context, it's just
a hrtimer_try_to_cancel() call that doesn't properly work.
Another culprit of the second and third items is the call of
hrtimer_forward_now() before snd_timer_interrupt(). The timer->stick
value may change during snd_timer_interrupt() call, but this
possibility is ignored completely.
For covering these subtle and messy issues, the following changes have
been done in this patch:
- A new flag, in_callback, is introduced in the private data to
indicate that the hrtimer handler is being processed.
- Both start and stop callbacks skip when called from (during)
in_callback flag.
- The hrtimer handler returns properly HRTIMER_RESTART and NORESTART
depending on the running state now.
- The hrtimer handler reprograms the expiry properly after
snd_timer_interrupt() call, instead of before.
- The close callback clears running flag and sets in_callback flag
to block any further start/stop calls.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Takashi Iwai