The 'use' locking macros are no-ops if neither SMP or SND_DEBUG is
enabled. This might once have been OK in non-preemptible
configurations, but even in that case snd_seq_read() may sleep while
relying on a 'use' lock. So always use the proper implementations.
Cc: stable@vger.kernel.org
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There is a potential race window opened at creating and deleting a
port via ioctl, as spotted by fuzzing. snd_seq_create_port() creates
a port object and returns its pointer, but it doesn't take the
refcount, thus it can be deleted immediately by another thread.
Meanwhile, snd_seq_ioctl_create_port() still calls the function
snd_seq_system_client_ev_port_start() with the created port object
that is being deleted, and this triggers use-after-free like:
BUG: KASAN: use-after-free in snd_seq_ioctl_create_port+0x504/0x630 [snd_seq] at addr ffff8801f2241cb1
=============================================================================
BUG kmalloc-512 (Tainted: G B ): kasan: bad access detected
-----------------------------------------------------------------------------
INFO: Allocated in snd_seq_create_port+0x94/0x9b0 [snd_seq] age=1 cpu=3 pid=4511
___slab_alloc+0x425/0x460
__slab_alloc+0x20/0x40
kmem_cache_alloc_trace+0x150/0x190
snd_seq_create_port+0x94/0x9b0 [snd_seq]
snd_seq_ioctl_create_port+0xd1/0x630 [snd_seq]
snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
snd_seq_ioctl+0x40/0x80 [snd_seq]
do_vfs_ioctl+0x54b/0xda0
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x16/0x75
INFO: Freed in port_delete+0x136/0x1a0 [snd_seq] age=1 cpu=2 pid=4717
__slab_free+0x204/0x310
kfree+0x15f/0x180
port_delete+0x136/0x1a0 [snd_seq]
snd_seq_delete_port+0x235/0x350 [snd_seq]
snd_seq_ioctl_delete_port+0xc8/0x180 [snd_seq]
snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
snd_seq_ioctl+0x40/0x80 [snd_seq]
do_vfs_ioctl+0x54b/0xda0
SyS_ioctl+0x79/0x90
entry_SYSCALL_64_fastpath+0x16/0x75
Call Trace:
[<ffffffff81b03781>] dump_stack+0x63/0x82
[<ffffffff81531b3b>] print_trailer+0xfb/0x160
[<ffffffff81536db4>] object_err+0x34/0x40
[<ffffffff815392d3>] kasan_report.part.2+0x223/0x520
[<ffffffffa07aadf4>] ? snd_seq_ioctl_create_port+0x504/0x630 [snd_seq]
[<ffffffff815395fe>] __asan_report_load1_noabort+0x2e/0x30
[<ffffffffa07aadf4>] snd_seq_ioctl_create_port+0x504/0x630 [snd_seq]
[<ffffffffa07aa8f0>] ? snd_seq_ioctl_delete_port+0x180/0x180 [snd_seq]
[<ffffffff8136be50>] ? taskstats_exit+0xbc0/0xbc0
[<ffffffffa07abc5c>] snd_seq_do_ioctl+0x11c/0x190 [snd_seq]
[<ffffffffa07abd10>] snd_seq_ioctl+0x40/0x80 [snd_seq]
[<ffffffff8136d433>] ? acct_account_cputime+0x63/0x80
[<ffffffff815b515b>] do_vfs_ioctl+0x54b/0xda0
.....
We may fix this in a few different ways, and in this patch, it's fixed
simply by taking the refcount properly at snd_seq_create_port() and
letting the caller unref the object after use. Also, there is another
potential use-after-free by sprintf() call in snd_seq_create_port(),
and this is moved inside the lock.
This fix covers CVE-2017-15265.
Reported-and-tested-by: Michael23 Yu <ycqzsy@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The event handler in the virmidi sequencer code takes a read-lock for
the linked list traverse, while it's calling snd_seq_dump_var_event()
in the loop. The latter function may expand the user-space data
depending on the event type. It eventually invokes copy_from_user(),
which might be a potential dead-lock.
The sequencer core guarantees that the user-space data is passed only
with atomic=0 argument, but snd_virmidi_dev_receive_event() ignores it
and always takes read-lock(). For avoiding the problem above, this
patch introduces rwsem for non-atomic case, while keeping rwlock for
atomic case.
Also while we're at it: the superfluous irq flags is dropped in
snd_virmidi_input_open().
Reported-by: Jia-Ju Bai <baijiaju1990@163.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
X32 ABI uses the 64bit timespec in addition to 64bit alignment of 64bit
values. We have added compat ABI for these ioctls, but this patch adds
one missing padding into 'struct snd_pcm_mmap_status_x32' to fix
incompatibilities.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Commit 04c5d5a430 ("ALSA: compress: Embed struct device") removed
the statement that used 'str' but didn't remove the variable itself.
So remove it.
[Adding stable to Cc since pr_debug() may refer to the uninitialized
buffer -- tiwai]
Fixes: 04c5d5a430 ("ALSA: compress: Embed struct device")
Signed-off-by: Guneshwor Singh <guneshwor.o.singh@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA sequencer core has a mechanism to load the enumerated devices
automatically, and it's performed in an off-load work. This seems
causing some race when a sequencer is removed while the pending
autoload work is running. As syzkaller spotted, it may lead to some
use-after-free:
BUG: KASAN: use-after-free in snd_rawmidi_dev_seq_free+0x69/0x70
sound/core/rawmidi.c:1617
Write of size 8 at addr ffff88006c611d90 by task kworker/2:1/567
CPU: 2 PID: 567 Comm: kworker/2:1 Not tainted 4.13.0+ #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events autoload_drivers
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x192/0x22c lib/dump_stack.c:52
print_address_description+0x78/0x280 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x230/0x340 mm/kasan/report.c:409
__asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435
snd_rawmidi_dev_seq_free+0x69/0x70 sound/core/rawmidi.c:1617
snd_seq_dev_release+0x4f/0x70 sound/core/seq_device.c:192
device_release+0x13f/0x210 drivers/base/core.c:814
kobject_cleanup lib/kobject.c:648 [inline]
kobject_release lib/kobject.c:677 [inline]
kref_put include/linux/kref.h:70 [inline]
kobject_put+0x145/0x240 lib/kobject.c:694
put_device+0x25/0x30 drivers/base/core.c:1799
klist_devices_put+0x36/0x40 drivers/base/bus.c:827
klist_next+0x264/0x4a0 lib/klist.c:403
next_device drivers/base/bus.c:270 [inline]
bus_for_each_dev+0x17e/0x210 drivers/base/bus.c:312
autoload_drivers+0x3b/0x50 sound/core/seq_device.c:117
process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
kthread+0x324/0x3f0 kernel/kthread.c:231
ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
The fix is simply to assure canceling the autoload work at removing
the device.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The debug functions uses wrongly the %pF instead of the %pS printk format
specifier for printing symbols for the address returned by
_builtin_return_address(0). Fix it for the ia64, ppc64 and parisc64
architectures.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some ioctl functions are implemented individually for both playback
and capture streams although most of the codes are identical with just
a few different stream-specific function calls. This patch unifies
these places, removes the superfluous trivial check and flattens the
call paths as a cleanup. Meanwhile, for better readability, some
codes (e.g. xfer ioctls or forward/rewind ioctls) are factored out as
functions.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently we're taking power_lock at each card component for assuring
the power-up sequence, but it doesn't help anything in the
implementation at the moment: it just serializes unnecessarily the
callers, but it doesn't protect about the power state change itself.
It used to have some usefulness in the early days where we managed the
PM manually. But now the suspend/resume core procedure is beyond our
hands, and power_lock lost its meaning.
This patch drops the power_lock from allover the places.
There shouldn't be any issues by this change, as it's no helper
regarding the power state change. Rather we'll get better performance
by removing the serialization; which is the only slight concern of any
behavior change, but it can't be a showstopper, after all.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
PCM OSS emulation issues the drain ioctl without power lock. It used
to work in the earlier kernels as the power lock was taken inside
snd_pcm_drain() itself. But since 68b4acd322 ("ALSA: pcm: Apply
power lock globally to common ioctls"), the power lock is taken
outside the function. Due to that change, the call via OSS emulation
leads to the unbalanced power lock, thus it deadlocks.
As a quick fix, just take the power lock before snd_pcm_drain() call
for OSS emulation path. A better cleanup will follow later.
Fixes: 68b4acd322 ("ALSA: pcm: Apply power lock globally to common ioctls")
Reported-and-tested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit c8da9be4a7 ("ALSA: pcm: Adjust nine function calls
together with a variable assignment") contained a badly incorrect
conversion, a "status" PCM procfs creation was replaced with the next
one. Luckily, this could be spotted easily by the kernel runtime
warning.
Fixes: c8da9be4a7 ("ALSA: pcm: Adjust nine function calls together...")
Reported-by: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For user-defined element set, in its initial state, TLV data is not
registered. It's firstly available when any application register it by
an additional operation. However, in current implementation, it's available
in its initial state. As a result, applications get -ENXIO to read it.
This commit controls its readability to manage info flags properly. In an
initial state, elements don't have SND_CTL_ELEM_ACCESS_TLV_READ flag. Once
TLV write operation is executed, they get the flag.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In a design of user-defined element set, applications allow to change TLV
data on the set. This operation doesn't only affects to a target element,
but also to elements in the set.
This commit generates TLV event for all of elements in the set when the TLV
data is changed.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In a design of ALSA control core, a set of elements is represented by
'struct snd_kcontrol' to share common attributes. The set of elements
shares TLV (Type-Length-Value) data, too.
On the other hand, in ALSA control interface/protocol for applications,
a TLV operation is committed to an element. Totally, the operation can
have sub-effect to the other elements in the set. For example, TLV_WRITE
operation is expected to change TLV data, which returns to applications.
Applications attempt to change the TLV data per element, but in the above
design, they can effect to elements in the same set.
As a default, ALSA control core has no implementation except for TLV_READ
operation. Thus, the above design looks to have no issue. However, in
kernel APIs of ALSA control component, developers can program a handler
for any request of the TLV operation. Therefore, for elements in a set
which has the handler, applications can commit TLV_WRITE and TLV_COMMAND
requests.
For the above scenario, ALSA control core assist notification. When the
handler returns positive value, the core queueing an event for a requested
element. However, this includes design defects that the event is not
queued for the other element in a set. Actually, developers can program
the handlers to keep per-element TLV data, but it depends on each driver.
As of v4.13-rc6, there's no driver in tree to utilize the notification,
except for user-defined element set. This commit delegates the notification
into each driver to prevent developers from the design defects.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a jump target so that a bit of exception handling can be better reused
at the end of this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The script "checkpatch.pl" pointed information out like the following.
ERROR: do not use assignment in if condition
Thus fix the affected source code place.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The script "checkpatch.pl" pointed information out like the following.
ERROR: do not use assignment in if condition
Thus fix the affected source code places.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a jump target so that a bit of exception handling can be better reused
at the end of this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When user tries to replace the user-defined control TLV, the kernel
checks the change of its content via memcmp(). The problem is that
the kernel passes the return value from memcmp() as is. memcmp()
gives a non-zero negative value depending on the comparison result,
and this shall be recognized as an error code.
The patch covers that corner-case, return 1 properly for the changed
TLV.
Fixes: 8aa9b586e4 ("[ALSA] Control API - more robust TLV implementation")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In ALSA control interface, applications can execute two types of request
for value of members on each element; ELEM_READ and ELEM_WRITE. In ALSA
control core, these two requests are handled within read lock of a
counting semaphore, therefore several processes can run to execute these
two requests at the same time. This has an issue because ELEM_WRITE
requests have an effect to change state of the target element. Concurrent
access should be controlled for each of ELEM_READ/ELEM_WRITE case.
This commit uses the counting semaphore as write lock for ELEM_WRITE
requests, while use it as read lock for ELEM_READ requests. The state of
a target element is maintained exclusively between ELEM_WRITE/ELEM_READ
operations.
There's a concern. If the counting semaphore is acquired for read lock
in implementations of 'struct snd_kcontrol.put()' in each driver, this
commit shall cause dead lock. As of v4.13-rc5, 'snd-mixer-oss.ko',
'snd-emu10k1.ko' and 'snd-soc-sst-atom-hifi2-platform.ko' includes codes
for read locks, but these are not in a call graph from
'struct snd_kcontrol.put(). Therefore, this commit is safe.
In current implementation, the same solution is applied for the other
operations to element; e.g. ELEM_LOCK and ELEM_UNLOCK. There's another
discussion about an overhead to maintain concurrent access to an element
during operating the other elements on the same card instance, because the
lock primitive is originally implemented to maintain a list of elements on
the card instance. There's a substantial difference between
per-element-list lock and per-element lock.
Here, let me investigate another idea to add per-element lock to maintain
the concurrent accesses with inquiry/change requests to an element. It's
not so frequent for applications to operate members on elements, while
adding a new lock primitive to structure increases memory footprint for
all of element sets somehow. Experimentally, inquiry operation is more
frequent than change operation and usage of counting semaphore for the
inquiry operation brings no blocking to the other inquiry operations. Thus
the overhead is not so critical for usual applications. For the above
reasons, in this commit, the per-element lock is not introduced.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA control core handles ELEM_READ/ELEM_WRITE requests within lock
acquisition of a counting semaphore. The lock is acquired in helper
functions in the end of call path before calling implementations of each
driver.
ioctl(2) with SNDRV_CTL_ELEM_READ
...
->snd_ctl_ioctl()
->snd_ctl_elem_read_user()
->snd_ctl_elem_read()
->down_read(controls_rwsem)
->snd_ctl_find_id()
->struct snd_kcontrol.get()
->up_read(controls_rwsem)
ioctl(2) with SNDRV_CTL_ELEM_WRITE
...
->snd_ctl_ioctl()
->snd_ctl_elem_write_user()
->snd_ctl_elem_write()
->down_read(controls_rwsem)
->snd_ctl_find_id()
->struct snd_kcontrol.put()
->up_read(controls_rwsem)
This commit moves the lock acquisition to middle of the call graph to
simplify the helper functions. As a result:
ioctl(2) with SNDRV_CTL_ELEM_READ
...
->snd_ctl_ioctl()
->snd_ctl_elem_read_user()
->down_read(controls_rwsem)
->snd_ctl_elem_read()
->snd_ctl_find_id()
->struct snd_kcontrol.get()
->up_read(controls_rwsem)
ioctl(2) with SNDRV_CTL_ELEM_WRITE
...
->snd_ctl_ioctl()
->snd_ctl_elem_write_user()
->down_read(controls_rwsem)
->snd_ctl_elem_write()
->snd_ctl_find_id()
->struct snd_kcontrol.put()
->up_read(controls_rwsem)
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Any control event is queued by a call of snd_ctl_notify(). This function
adds the event to each queue of opened file data corresponding to ALSA
control character devices. This function acquired two types of lock; a
counting semaphore for a list of the opened file data and a spinlock for
card data opened by the file. Typically, this function is called after
acquiring a counting semaphore for a list of elements in the card data.
In current implementation of a handler for ELEM_WRITE request, the
function is called after releasing the semaphore for a list of elements
in the card data. This release is not necessarily needed.
This commit removes the release to call the function within the critical
section so that later commits are simple.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
commit 4842e98f26 ("ALSA: seq: Fix race at
creating a queue") attempted to fix a race reported by syzkaller. That
fix has been described as follows:
"
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.
"
Even with that fix in place, syzkaller reported a use-after-free error.
It specifically pointed to the last instruction "return q->queue" in
snd_seq_queue_alloc(). The pointer q is being used after kfree() has
been called on it.
It turned out that there is still a small window where a race can
happen. The window opens at
snd_seq_ioctl_create_queue()->snd_seq_queue_alloc()->queue_list_add()
and closes at
snd_seq_ioctl_create_queue()->queueptr()->snd_use_lock_use(). Between
these two calls, a different thread could delete the queue and possibly
re-create a different queue in the same location in queue_list.
This change prevents this situation by calling snd_use_lock_use() from
snd_seq_queue_alloc() prior to calling queue_list_add(). It is then the
caller's responsibility to call snd_use_lock_free(&q->use_lock).
Fixes: 4842e98f26 ("ALSA: seq: Fix race at creating a queue")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Daniel Mentz <danielmentz@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit 0181307abc ("ALSA: seq: Reorganize kconfig and build")
rewrote the dependency of each sequencer module in a standard way, but
there was one change applied mistakenly: CONFIG_SND_SEQ_MIDI isn't
enabled properly by CONFIG_SND_RAWMIDI. I seem to have changed the
wrong one instead, CONFIG_SND_SEQ_MIDI_EMUL, which is eventually
reverse-selected by CONFIG_SND_SEQ_MIDI itself. This ended up the
lack of snd-seq-midi module as reported below.
The fix is to put def_tristate properly to CONFIG_SND_SEQ_MIDI instead
of *_MIDI_EMUL entry.
Fixes: 0181307abc ("ALSA: seq: Reorganize kconfig and build")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196633
Signed-off-by: Takashi Iwai <tiwai@suse.de>
User-defined element set registers own handler to get callbacks from TLV
ioctl handler. In the handler, execution path bifurcates depending on
requests from user space. At write request, container in given buffer is
registered to the element set, or replaced old TLV data. At the read
request, the registered data is copied to user space. The command request
is not allowed. In current implementation, function of the handler
includes codes for the two cases.
This commit adds two helper functions for these cases so that readers can
easily get the above design.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In a design of ALSA control core, execution path bifurcates depending on
target element. When a set with the target element has a handler, it's
called. Else, registered buffer is copied to user space. These two
operations are apparently different. In current implementation, they're
on the same function with a condition statement. This makes it a bit hard
to understand conditions of each case.
This commit splits codes for these two cases.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At a previous commit, concurrent requests for TLV data are maintained
exclusively between read requests and write/command requests. TLV
callback handlers in each driver has no risk from concurrent access for
reference/change.
In current implementation, 'struct snd_card' has a mutex to control
concurrent accesses to user-defined element sets. This commit obsoletes it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In ALSA control interface, applications can execute three types of request
for Type-Length-Value (TLV) data to a set of elements; read, write and
command. In ALSA control core, all of the requests are handled within read
lock to a counting semaphore, therefore several processes can run to access
to the data at the same time for any purposes. This has an issue because
write and command requests have side effect to change state of a set of
elements for the TLV data. Concurrent access should be controlled for each
of reference/change case.
This commit uses the counting semaphore as read lock for TLV read requests,
while use it as write lock for TLV write/command requests. The state of a
set of elements for the TLV data is maintained exclusively between read
requests and write/command requests, or between write and command requests.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Any control event is queued by a call of snd_ctl_notify(). This function
adds the event to each queue of opened file data corresponding to ALSA
control character devices. This function acquired two types of lock; a
counting semaphore for a list of the opened file data and a spinlock for
card data opened by the file. Typically, this function is called after
acquiring a counting semaphore for a list of elements in the card data.
In current implementation of TLV request handler, the function is called
after releasing the semaphore for a list of elements in the card data.
This release is not necessarily needed.
This commit removes the release to call the function within the critical
section so that later commits are simple.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Small last-minute fixes for 4.13-rc1: a couple of PCM fixes for m68k,
a cleanup work for legacy ISA msnd driver, and a few HD-audio new IDs
and quirks.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEECxfAB4MH3rD5mfB6bDGAVD0pKaQFAllohicOHHRpd2FpQHN1
c2UuZGUACgkQbDGAVD0pKaTI+g/9GUZDsSLf8EIMhyJqcR0kpMXi4oMC3H/7fCCg
MEkGc4C8lG9ZpXpRthGWBwwIujIfH+QXdRpXZeHqV8yias80Ryi1rBd2BCk0eVuF
hQXbCXAyhN7E6OXvgjIi7eQKwzGrwhV9OFTpChqcEIu2Oym8lD91DOU+hHtFGX56
5VM4zZ+KzDa11L3cYzWKP/PlsqBp9eGNfamf5Q5wb2SnaVYcxLSQWkgsTQloRK/b
YOFMNvgUQV7XB23t8ouxPIo5YYCnX7xSyP1nkt9mL7z1CYn1q8hgG0yWw5lPK/6E
tnjm2H2X6fcT+zSVxYKOn6WHcK2aER7PJZOaqkmmFp4cN31AqdkToT/fNWTELaaM
pZe2fY0vfwtpvaVhonv70GEWcGyi9oa4CanOmDPNgti/V1Em0rBpoFa+FTlF4SWc
VJsi5645b9ieQ/LvXsAHlVEflSWuRtdUxen1Hx1rVhUBKnDPRifIeClycjcqddNY
uttMuQjzMs8S53G7bILHwLe0zyGEDFE/UH8/xooM9IiPr8Dd18wCu04Rlf/8dK5S
VFjn1VKhcc0HVtWCUPlHGW+RxsLWwI26CUH15sAH6v08ci8BsqPjF3IHyfLy+vXb
XbuMiBeKIOCNRHADHaTXodIr6O35mVI3HRqSAV3mYZlUX8Nd7CkpcsMYotwEihUL
MGnGV+g=
=tGl3
-----END PGP SIGNATURE-----
Merge tag 'sound-fix-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Small last-minute fixes for 4.13-rc1: a couple of PCM fixes for m68k,
a cleanup work for legacy ISA msnd driver, and a few HD-audio new IDs
and quirks"
* tag 'sound-fix-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Add hdmi id for a Geminilake variant
ALSA: hda/realtek - New codec device ID for ALC1220
ALSA: pcm: Simplify check for dma_mmap_coherent() availability
ALSA: pcm: Protect call to dma_mmap_coherent() by check for HAS_DMA
ALSA: msnd: Optimize / harden DSP and MIDI loops
ALSA: hda/realtek - change the location for one of two front microphones
ALSA: opl4: Move inline before return type
We check the availability of dma_mmap_coherent() in hw_support_mmap()
but with an ugly ifdef of lots of arch-checks. Now we have a nice
CONFIG_ARCH_NO_COHERENT_DMA_MMAP kconfig, and this can be used
together with CONFIG_HAS_DMA check for a cleaner and more
comprehensive check.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
If NO_DMA=y:
sound/core/pcm_native.o: In function `snd_pcm_lib_default_mmap':
pcm_native.c:(.text+0x144c): undefined reference to `bad_dma_ops'
pcm_native.c:(.text+0x1474): undefined reference to `dma_common_mmap'
Add a check for HAS_DMA to fix this.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This development cycle resulted in a fair amount of changes in both
core and driver sides. The most significant change in ALSA core is
about PCM. Also the support of of-graph card and the new DAPM widget
for DSP are noteworthy changes in ASoC core. And there're lots of
small changes splat over the tree, as you can see in diffstat.
Below are a few highlights:
ALSA core:
- Removal of set_fs() hackery from PCM core stuff, and the code
reorganization / optimization thereafter
- Improved support of PCM ack ops, and a new ABI for improved
control/status mmap handling
- Lots of constifications in various codes
ASoC core:
- The support of of-graph card, which may work as a better generic
device for a replacement of simple-card
- New widget types intended mainly for use with DSPs
ASoC drivers:
- New drivers for Allwinner V3s SoCs
- Ensonic ES8316 codec support
- More Intel SKL and KBL works
- More device support for Intel SST Atom (mostly for cheap tablets and
2-in-1 devices)
- Support for Rockchip PDM controllers
- Support for STM32 I2S and S/PDIF controllers
- Support for ZTE AUD96P22 codecs
HD-audio:
- Support of new Realtek codecs (ALC215/ALC285/ALC289), more quirks
for HP and Dell machines
- A few more fixes for i915 component binding
Note that of-graph change may bring the conflicts with a later pull
request of devicetree, as currently found in linux-next.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEECxfAB4MH3rD5mfB6bDGAVD0pKaQFAllbtmMOHHRpd2FpQHN1
c2UuZGUACgkQbDGAVD0pKaTMkhAAnqvRvh9nYBI1E2VGtJON/AFcsF4s6xdJd0ow
Bn5Kq/07rGWxAi8Cy69LM930eQrZl+xR69I7LMkC54BxVNhvhXNef7E5GXPbRi+3
l6dkBmkqvwmmHP5iiOxKtYSAnUfJitu1rmtAOVAjRh8rsWNeLuI8N8V/uilQBioi
lRywdBjdylub00H1DL8cmZHbrBb4pYrL/LepTswZL3I/UZ225fMiIGFd8tXpQPwZ
IKRZiuzrc3SykxSsL/aNeyxP+2qTYRtPfl/FGenKBBO2PJmGAb00yAdtQJRcD2eX
Xf1alfvpNgpy/U6+C7dJgNWQvvr+lPCaFXuMukIDno/zg/xD1V1Ev/fnbVEINLve
xMOnuJSGGaY6fu6eZ4Cck0VfZIj7UVA9x8zvBOKntIhq/VLfE7DDu3p9tiAZAVfH
nMOLAhy+0kFyHSrv6zVWQj+cmjPwLvaW7fNWVljL5/MWuF5GJi05DUOfV/vk8BaO
EnyVqe2ynzNLTsFpLHHy6XKgKtSTkPygxYSNuI7kSYAxD5qE6hXXKXTAqJ3LjDkO
tGiFmxp/vHrlNvcyRjXc30th/9PPj/mRBcJ2KyjXPa63L5ZW86PiyIHKxJA4yogv
y4z2ZlhIz90cZvpigFHtFqq1puVlDtKDbAaJ6AKrP8HEHUlMiPNApsSjWWBUcfzV
DXzrlg0=
=PUEh
-----END PGP SIGNATURE-----
Merge tag 'sound-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"This development cycle resulted in a fair amount of changes in both
core and driver sides. The most significant change in ALSA core is
about PCM. Also the support of of-graph card and the new DAPM widget
for DSP are noteworthy changes in ASoC core. And there're lots of
small changes splat over the tree, as you can see in diffstat.
Below are a few highlights:
ALSA core:
- Removal of set_fs() hackery from PCM core stuff, and the code
reorganization / optimization thereafter
- Improved support of PCM ack ops, and a new ABI for improved
control/status mmap handling
- Lots of constifications in various codes
ASoC core:
- The support of of-graph card, which may work as a better generic
device for a replacement of simple-card
- New widget types intended mainly for use with DSPs
ASoC drivers:
- New drivers for Allwinner V3s SoCs
- Ensonic ES8316 codec support
- More Intel SKL and KBL works
- More device support for Intel SST Atom (mostly for cheap tablets
and 2-in-1 devices)
- Support for Rockchip PDM controllers
- Support for STM32 I2S and S/PDIF controllers
- Support for ZTE AUD96P22 codecs
HD-audio:
- Support of new Realtek codecs (ALC215/ALC285/ALC289), more quirks
for HP and Dell machines
- A few more fixes for i915 component binding"
* tag 'sound-4.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (418 commits)
ALSA: hda - Fix unbalance of i915 module refcount
ASoC: Intel: Skylake: Remove driver debugfs exit
ASoC: Intel: Skylake: explicitly add the headers sst-dsp.h
ALSA: hda/realtek - Remove GPIO_MASK
ALSA: hda/realtek - Fix typo of pincfg for Dell quirk
ALSA: pcm: add a documentation for tracepoints
ALSA: atmel: ac97c: fix error return code in atmel_ac97c_probe()
ALSA: x86: fix error return code in hdmi_lpe_audio_probe()
ASoC: Intel: Skylake: Add support to read firmware registers
ASoC: Intel: Skylake: Add sram address to sst_addr structure
ASoC: Intel: Skylake: Debugfs facility to dump module config
ASoC: Intel: Skylake: Add debugfs support
ASoC: fix semicolon.cocci warnings
ASoC: rt5645: Add quirk override by module option
ASoC: rsnd: make arrays path and cmd_case static const
ASoC: audio-graph-card: add widgets and routing for external amplifier support
ASoC: audio-graph-card: update bindings for amplifier support
ASoC: rt5665: calibration should be done before jack detection
ASoC: rsnd: constify dev_pm_ops structures.
ASoC: nau8825: change crosstalk-bypass property to bool type
...
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/device.h> work with const
attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
9781 240 8 10029 272d sound/core/pcm.o
File size After adding 'const':
text data bss dec hex filename
9813 176 8 9997 270d sound/core/pcm.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that user-space (typically alsa-lib) can specify which protocol
version it supports, we can optimize the kernel code depending on the
reported protocol version.
In this patch, we change the previous hack for enforcing the appl_ptr
sync by disabling status/control mmap. Instead of forcibly disabling
both mmaps, we disable only the control mmap when user-space declares
the supported protocol version new enough. For older user-space,
still both PCM status and control mmaps are disabled when requested by
the driver due to the compatibility reason.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We have an ioctl to inform the PCM protocol version the running kernel
supports, but there is no way to know which protocol version the
user-space can understand. This lack of information caused headaches
in the past when we tried to extend the ABI. For example, because we
couldn't guarantee the validity of the reserved bytes, we had to
introduce a new ioctl SNDRV_PCM_IOCTL_STATUS_EXT for assigning a few
new fields in the formerly reserved bits. If we could know that it's
a new alsa-lib, we could assume the availability of the new fields,
thus we could have reused the existing SNDRV_PCM_IOCTL_STATUS.
In order to improve the ABI extensibility, this patch adds a new ioctl
for user-space to inform its supporting protocol version to the
kernel. By reporting the supported protocol from user-space, the
kernel can judge which feature should be provided and which not.
With the addition of the new ioctl, the PCM protocol version is bumped
to 2.0.14, too. User-space checks the kernel protocol version via
SNDRV_PCM_INFO_PVERSION, then it sets the supported version back via
SNDRV_PCM_INFO_USER_PVERSION.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently x86 platforms use the PCM status/control mmaps for
transferring the PCM status and appl_ptr between kernel and
user-spaces. The mmap is a most efficient way of communication, but
it has a drawback per its nature, namely, it can't notify the change
explicitly to kernel.
The lack of appl_ptr update notification is a problem on a few
existing drivers, but it's mostly a small issue and negligible.
However, a new type of driver that uses DSP for a deep buffer
management requires the exact position of appl_ptr for calculating the
buffer prefetch size, and the asynchronous appl_ptr update between
kernel and user-spaces becomes a significant problem for it.
How can we enforce user-space to report the appl_ptr update? The way
is relatively simple. Just by disabling the PCM control mmap, the
user-space is supposed to fall back to the mode using SYNC_PTR ioctl,
and the kernel gets control over that. This fallback mode is used in
all non-x86 platforms as default, and also in the 32bit compatible
model on all platforms including x86. It's been implemented already
over a decade, so we can say it's fairly safe and stably working.
With the help of the knowledge above, this patch introduces a new PCM
info flag SNDRV_PCM_INFO_SYNC_APPLPTR for achieving the appl_ptr sync
from user-space. When a driver sets this flag at open, the PCM status
/ control mmap is disabled, which effectively switches to SYNC_PTR
mode in user-space side.
In this version, both PCM status and control mmaps are disabled
although only the latter, control mmap, is the target. It's because
the current alsa-lib implementation supposes that both status and
control mmaps are always coupled, thus it handles a fatal error when
only one of them fails.
Of course, the disablement of the status/control mmaps may bring a
slight performance overhead. Thus, as of now, this should be used
only for the dedicated devices that deserves.
Note that the disablement of mmap is a sort of workaround. In the
later patch, we'll introduce the way to identify the protocol version
alsa-lib supports, and keep mmap working while the sync_ptr is
performed together.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Rename:
wait_queue_t => wait_queue_entry_t
'wait_queue_t' was always a slight misnomer: its name implies that it's a "queue",
but in reality it's a queue *entry*. The 'real' queue is the wait queue head,
which had to carry the name.
Start sorting this out by renaming it to 'wait_queue_entry_t'.
This also allows the real structure name 'struct __wait_queue' to
lose its double underscore and become 'struct wait_queue_entry',
which is the more canonical nomenclature for such data types.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The ALSA PCM core refers to the appl_ptr value stored on the mmapped
page that is shared between kernel and user-space. Although the
reference is performed in the PCM stream lock, it doesn't guarantee
the atomic access when the value gets updated concurrently from the
user-space on another CPU.
In most of codes, this is no big problem, but still there are a few
places that may result in slight inconsistencies because they access
runtime->control->appl_ptr multiple times; that is, the second read
might be a different value from the first value. It can be even
backward or jumping, as we have no control for it. Hence, the
calculation may give an unexpected value. Luckily, there is no
security vulnerability by that, as far as I've checked. But still we
should address it.
This patch tries to reduce such possible cases. The fix is simple --
we just read once, store it to a local variable and use it for the
rest calculations. The READ_ONCE() macro is used for it in order to
avoid the ill-effect by possible compiler optimizations.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations
in order to improve grep-ability.
- Move EXPORT_SYMBOL*() to the position right after its definition
- Remove superfluous blank line before EXPORT_SYMBOL*() lines
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations
in order to improve grep-ability.
- Move EXPORT_SYMBOL*() to the position right after its definition
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations
in order to improve grep-ability.
- Move EXPORT_SYMBOL*() to the position right after its definition
- Remove superfluous blank line before EXPORT_SYMBOL*() lines
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations
in order to improve grep-ability.
- Remove superfluous blank line before EXPORT_SYMBOL*() lines
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The standard PCM chmap helper callbacks treat the NULL info->chmap as
a fatal error and spews the kernel warning with stack trace when
CONFIG_SND_DEBUG is on. This was OK, originally it was supposed to be
always static and non-NULL. But, as the recent addition of Intel LPE
audio driver shows, the chmap content may vary dynamically, and it can
be even NULL when disconnected. The user still sees the kernel
warning unnecessarily.
For clearing such a confusion, this patch simply removes the
snd_BUG_ON() in each place, just returns an error without warning.
Cc: <stable@vger.kernel.org> # v4.11+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Drivers can implement 'struct snd_pcm_ops.ioctl' to handle some requests
from ALSA PCM core. These requests are internal purpose in kernel land.
Usually common set of operations are used for it.
SNDRV_PCM_IOCTL1_INFO is one of the requests. According to code comment,
it has been obsoleted in the old days.
We can see old releases in ftp.alsa-project.org. The command was firstly
introduced in v0.5.0 release as SND_PCM_IOCTL1_INFO, to allow drivers to
fill data of 'struct snd_pcm_channel_info' type. In v0.9.0 release,
this was obsoleted by the other commands for ioctl(2) such as
SNDRV_PCM_IOCTL_CHANNEL_INFO.
This commit removes the long-abandoned command, bye.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We call ack callback whenever appl_ptr gets updated via
pcm_lib_apply_appl_ptr(). There are various code paths to call this
function. A part of them are for read/write/forward/rewind, where the
appl_ptr is always changed and thus the call of ack is mandatory.
OTOH, another part of code paths are from the explicit user call,
e.g. via SYNC_PTR ioctl. There, we may receive the same appl_ptr
value, and in such a case, calling ack is obviously superfluous.
This patch adds the check of the given appl_ptr value, and returns
immediately if it's no real update.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
