| Age | Commit message (Collapse) | Author |
|---|
|
commit e18035cf5cb3d2bf8e4f4d350a23608bd208b934 upstream.
Add and use snd_pcm_stream_lock_nested() in snd_pcm_link/unlink
implementation. The code is fine, but generates a lockdep complaint:
============================================
WARNING: possible recursive locking detected
5.7.1mq+ #381 Tainted: G O
--------------------------------------------
pulseaudio/4180 is trying to acquire lock:
ffff888402d6f508 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xda8/0xee0 [snd_pcm]
but task is already holding lock:
ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&group->lock);
lock(&group->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
2 locks held by pulseaudio/4180:
#0: ffffffffa1a05190 (snd_pcm_link_rwsem){++++}-{3:3}, at: snd_pcm_common_ioctl+0xca0/0xee0 [snd_pcm]
#1: ffff8883f7a8cf18 (&group->lock){-...}-{2:2}, at: snd_pcm_common_ioctl+0xe4e/0xee0 [snd_pcm]
[...]
Cc: stable@vger.kernel.org
Fixes: f57f3df03a8e ("ALSA: pcm: More fine-grained PCM link locking")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/37252c65941e58473b1219ca9fab03d48f47e3e3.1591610330.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
commit 951e2736f4b11b58dc44d41964fa17c3527d882a upstream.
Prevent SNDRV_PCM_IOCTL_LINK linking stream to itself - the code
can't handle it. Fixed commit is not where bug was introduced, but
changes the context significantly.
Cc: stable@vger.kernel.org
Fixes: 0888c321de70 ("pcm_native: switch to fdget()/fdput()")
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Link: https://lore.kernel.org/r/89c4a2487609a0ed6af3ecf01cc972bdc59a7a2d.1591634956.git.mirq-linux@rere.qmqm.pl
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit fb8cd6481ffd126f35e9e146a0dcf0c4e8899f2e ]
The "info.index" variable can be 31 in "1 << info.index".
This might trigger an undefined behavior since 1 is signed.
Fix this by casting 1 to 1u just to be sure "1u << 31" is defined.
Signed-off-by: Changming Liu <liu.changm@northeastern.edu>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/BL0PR06MB4548170B842CB055C9AF695DE5B00@BL0PR06MB4548.namprd06.prod.outlook.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
commit e7513c5786f8b33f0c107b3759e433bc6cbb2efa upstream.
There is a corner case that ALSA keeps increasing the hw_ptr but DMA
already stop working/updating the position for a long time.
In following log we can see the position returned from DMA driver does
not move at all but the hw_ptr got increased at some point of time so
snd_pcm_avail() will return a large number which seems to be a buffer
underrun event from user space program point of view. The program
thinks there is space in the buffer and fill more data.
[ 418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
[ 418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554
...
[ 418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362
[ 418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
[ 418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368
This is because the hw_base will be increased by runtime->buffer_size
frames unconditionally if the hw_ptr is not updated for over half of
buffer time. As the hw_base increases, so does the hw_ptr increased
by the same number.
The avail value returned from snd_pcm_avail() could exceed the limit
(buffer_size) easily becase the hw_ptr itself got increased by same
buffer_size samples when the corner case happens. In following log,
the buffer_size is 16368 samples but the avail is 21810 samples so
CRAS server complains about it.
[ 418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442
[ 418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810
cras_server[1907]: pcm_avail returned frames larger than buf_size:
sof-glkda7219max: :0,5: 21810 > 16368
By updating runtime->hw_ptr_jiffies each time the HWSYNC is called,
the hw_base will keep the same when buffer stall happens at long as
the interval between each HWSYNC call is shorter than half of buffer
time.
Following is a log captured by a patched kernel. The hw_base/hw_ptr
value is fixed in this corner case and user space program should be
aware of the buffer stall and handle it.
[ 293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368
[ 293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584
[ 293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488
[ 293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392
[ 293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
...
[ 381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0
Signed-off-by: Brent Lu <brent.lu@intel.com>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c1f6e3c818dd734c30f6a7eeebf232ba2cf3181d upstream.
The rawmidi core allows user to resize the runtime buffer via ioctl,
and this may lead to UAF when performed during concurrent reads or
writes: the read/write functions unlock the runtime lock temporarily
during copying form/to user-space, and that's the race window.
This patch fixes the hole by introducing a reference counter for the
runtime buffer read/write access and returns -EBUSY error when the
resize is performed concurrently against read/write.
Note that the ref count field is a simple integer instead of
refcount_t here, since the all contexts accessing the buffer is
basically protected with a spinlock, hence we need no expensive atomic
ops. Also, note that this busy check is needed only against read /
write functions, and not in receive/transmit callbacks; the race can
happen only at the spinlock hole mentioned in the above, while the
whole function is protected for receive / transmit callbacks.
Reported-by: butt3rflyh4ck <butterflyhuangxx@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/CAFcO6XMWpUVK_yzzCpp8_XP7+=oUpQvuBeCbMffEDkpe8jWrfg@mail.gmail.com
Link: https://lore.kernel.org/r/s5heerw3r5z.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4285de0725b1bf73608abbcd35ad7fd3ddc0b61e upstream.
The checks of the plugin buffer overflow in the previous fix by commit
f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
are put in the wrong places mistakenly, which leads to the expected
(repeated) sound when the rate plugin is involved. Fix in the right
places.
Also, at those right places, the zero check is needed for the
termination node, so added there as well, and let's get it done,
finally.
Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200424193350.19678-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ae769d3556644888c964635179ef192995f40793 upstream.
The recent fix for the OOB access in PCM OSS plugins (commit
f2ecf903ef06: "ALSA: pcm: oss: Avoid plugin buffer overflow") caused a
regression on OSS applications. The patch introduced the size check
in client and slave size calculations to limit to each plugin's buffer
size, but I overlooked that some code paths call those without
allocating the buffer but just for estimation.
This patch fixes the bug by skipping the size check for those code
paths while keeping checking in the actual transfer calls.
Fixes: f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
Tested-and-reported-by: Jari Ruusu <jari.ruusu@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200403072515.25539-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This is a similar bug like the previous case for virmidi: the invalid
running status is kept after receiving a sysex message.
Again the fix is to clear the running status after handling the sysex.
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de
Link: https://lore.kernel.org/r/20200316090506.23966-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The virmidi driver handles sysex event exceptionally in a short-cut
snd_seq_dump_var_event() call, but this missed the reset of the
running status. As a result, it may lead to an incomplete command
right after the sysex when an event with the same running status was
queued.
Fix it by clearing the running status properly via alling
snd_midi_event_reset_decode() for that code path.
Reported-by: Andreas Steinmetz <ast@domdv.de>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de
Link: https://lore.kernel.org/r/20200316090506.23966-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The return value checks in snd_pcm_plug_alloc() are covered with
snd_BUG_ON() macro that may trigger a kernel WARNING depending on the
kconfig. But since the error condition can be triggered by a weird
user space parameter passed to OSS layer, we shouldn't give the kernel
stack trace just for that. As it's a normal error condition, let's
remove snd_BUG_ON() macro usage there.
Reported-by: syzbot+2a59ee7a9831b264f45e@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200312155730.7520-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Each OSS PCM plugins allocate its internal buffer per pre-calculation
of the max buffer size through the chain of plugins (calling
src_frames and dst_frames callbacks). This works for most plugins,
but the rate plugin might behave incorrectly. The calculation in the
rate plugin involves with the fractional position, i.e. it may vary
depending on the input position. Since the buffer size
pre-calculation is always done with the offset zero, it may return a
shorter size than it might be; this may result in the out-of-bound
access as spotted by fuzzer.
This patch addresses those possible buffer overflow accesses by simply
setting the upper limit per the given buffer size for each plugin
before src_frames() and after dst_frames() calls.
Reported-by: syzbot+e1fe9f44fb8ecf4fb5dd@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/000000000000b25ea005a02bcf21@google.com
Link: https://lore.kernel.org/r/20200309082148.19855-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
snd_seq_check_queue() passes the current tick and time of the given
queue as a pointer to snd_seq_prioq_cell_out(), but those might be
updated concurrently by the seq timer update.
Fix it by retrieving the current tick and time via the proper helper
functions at first, and pass those values to snd_seq_prioq_cell_out()
later in the loops.
snd_seq_timer_get_cur_time() takes a new argument and adjusts with the
current system time only when it's requested so; this update isn't
needed for snd_seq_check_queue(), as it's called either from the
interrupt handler or right after queuing.
Also, snd_seq_timer_get_cur_tick() is changed to read the value in the
spinlock for the concurrency, too.
Reported-by: syzbot+fd5e0eaa1a32999173b2@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20200214111316.26939-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The queue flags are represented in bit fields and the concurrent
access may result in unexpected results. Although the current code
should be mostly OK as it's only reading a field while writing other
fields as KCSAN reported, it's safer to cover both with a proper
spinlock protection.
This patch fixes the possible concurrent read by protecting with
q->owner_lock. Also the queue owner field is protected as well since
it's the field to be protected by the lock itself.
Reported-by: syzbot+65c6c92d04304d0a8efc@syzkaller.appspotmail.com
Reported-by: syzbot+e60ddfa48717579799dd@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20200214111316.26939-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The commit 66f2d19f8116 ("ALSA: pcm: Fix memory leak at closing a
stream without hw_free") tried to fix the regression wrt the missing
hw_free call at closing without SNDRV_PCM_IOCTL_HW_FREE ioctl.
However, the code change dropped mistakenly the state check, resulting
in calling hw_free twice when SNDRV_PCM_IOCTL_HW_FRE got called
beforehand. For most drivers, this is almost harmless, but the
drivers like SOF show another regression now.
This patch adds the state condition check before calling do_hw_free()
at releasing the stream for avoiding the double hw_free calls.
Fixes: 66f2d19f8116 ("ALSA: pcm: Fix memory leak at closing a stream without hw_free")
Reported-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/s5hd0ajyprg.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of pending small fixes:
ALSA core:
- PCM memory leak fix
ASoC:
- Lots of SOF and Intel driver fixes
- Addition of COMMON_CLK for wcd934x
- Regression fixes for AMD and Tegra platforms
HD-audio:
- DP-MST HDMI regression fix, Tegra workarounds, HP quirk fix
Others:
- A few fixes relevant with the recent uapi-updates
- Sparse warnings and endianness fixes"
* tag 'sound-fix-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (35 commits)
ALSA: hda: Clear RIRB status before reading WP
ALSA: hda/realtek - Fixed one of HP ALC671 platform Headset Mic supported
ASoC: wcd934x: Add missing COMMON_CLK dependency to SND_SOC_ALL_CODECS
ALSA: hda - Fix DP-MST support for NVIDIA codecs
ASoC: wcd934x: Add missing COMMON_CLK dependency
MAINTAINERS: Remove the Bard Liao from the MAINTAINERS of Realtek CODECs
ASoC: tegra: Revert 24 and 32 bit support
ASoC: SOF: Intel: add PCI ID for JasperLake
ALSA: hdsp: Make the firmware loading ioctl a bit more readable
ALSA: emu10k1: Fix annotation and cast for the recent uapi header change
ALSA: dummy: Fix PCM format loop in proc output
ALSA: usb-audio: Annotate endianess in Scarlett gen2 quirk
ALSA: usb-audio: Fix endianess in descriptor validation
ALSA: hda: Add JasperLake PCI ID and codec vid
ALSA: pcm: Fix sparse warnings wrt snd_pcm_state_t
ALSA: pcm: Fix memory leak at closing a stream without hw_free
ALSA: uapi: Fix sparse warning
ASoC: rt715: Add __maybe_unused to PM callbacks
ASoC: rt711: Add __maybe_unused to PM callbacks
ASoC: rt700: Add __maybe_unused to PM callbacks
...
|
|
The most notable change is DEFINE_SHOW_ATTRIBUTE macro split in
seq_file.h.
Conversion rule is:
llseek => proc_lseek
unlocked_ioctl => proc_ioctl
xxx => proc_xxx
delete ".owner = THIS_MODULE" line
[akpm@linux-foundation.org: fix drivers/isdn/capi/kcapi_proc.c]
[sfr@canb.auug.org.au: fix kernel/sched/psi.c]
Link: http://lkml.kernel.org/r/20200122180545.36222f50@canb.auug.org.au
Link: http://lkml.kernel.org/r/20191225172546.GB13378@avx2
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Since we have a bitwise definition of snd_pcm_state_t and use it for
certain struct fields, a few new (and years old) sparse warnings came
up. This patch is an attempt to cover them.
- The state fields in snd_pcm_mmap_status* and co are all defined as
snd_pcm_state_t type now
- The PCM action callbacks take snd_pcm_state_t argument as well;
some actions taking special values got the explicit cast and
comments
- For the PCM action that doesn't need an extra argument receives
ACTION_ARG_IGNORE instead of ambiguous 0
While we're at it, the boolean argument is also properly changed to
bool and true/false, as well as a slight refactoring of PCM pause
helper function to make easier to read.
No functional changes, just shutting up chatty sparse.
Fixes: 46b770f720bd ("ALSA: uapi: Fix sparse warning")
Reported-by: kbuild test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20200131152214.11698-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
ALSA PCM core recently introduced a new managed PCM buffer allocation
mode that does allocate / free automatically at hw_params and
hw_free. However, it overlooked the code path directly calling
hw_free PCM ops at releasing the PCM substream, and it may result in a
memory leak as spotted by syzkaller when no buffer preallocation is
used (e.g. vmalloc buffer).
This patch papers over it with a slight refactoring. The hw_free ops
call and relevant tasks are unified in a new helper function, and call
it from both places.
Fixes: 0dba808eae26 ("ALSA: pcm: Introduce managed buffer allocation mode")
Reported-by: syzbot+30edd0f34bfcdc548ac4@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200129195907.12197-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Currently, the available buffer allocation size for a PCM stream
depends on the preallocated size; when a buffer has been preallocated,
the max buffer size is set to that size, so that application won't
re-allocate too much memory. OTOH, when no preallocation is done,
each substream may allocate arbitrary size of buffers as long as
snd_pcm_hardware.buffer_bytes_max allows -- which can be quite high,
HD-audio sets 1GB there.
It means that the system may consume a high amount of pages for PCM
buffers, and they are pinned and never swapped out. This can lead to
OOM easily.
For avoiding such a situation, this patch adds the upper limit per
card. Each snd_pcm_lib_malloc_pages() and _free_pages() calls are
tracked and it will return an error if the total amount of buffers
goes over the defined upper limit. The default value is set to 32MB,
which should be really large enough for usual operations.
If larger buffers are needed for any specific usage, it can be
adjusted (also dynamically) via snd_pcm.max_alloc_per_card option.
Setting zero there means no chceck is performed, and again, unlimited
amount of buffers are allowed.
Link: https://lore.kernel.org/r/20200120124423.11862-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Resolved the merge conflict in HD-audio Tegra driver.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Both snd_pcm_hw_constraints_init() and _complete() functions are
called only from pcm_native.c, hence they can be static for further
optimization.
Link: https://lore.kernel.org/r/20200116162825.24792-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
snd_seq_info_timer_read() reads the information of the timer assigned
for each queue, but it's done in a racy way which may lead to UAF as
spotted by syzkaller.
This patch applies the missing q->timer_mutex lock while accessing the
timer object as well as a slight code change to adapt the standard
coding style.
Reported-by: syzbot+2b2ef983f973e5c40943@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200115203733.26530-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
GCC reports a warning with W=1:
sound/core/timer.c: In function ‘snd_timer_user_read’:
sound/core/timer.c:2219:19: warning: initialized field overwritten
[-Woverride-init]
2219 | .tstamp_sec = tread->tstamp_nsec,
| ^~~~~
sound/core/timer.c:2219:19: note: (near initialization for
‘(anonymous).tstamp_sec’)
Assigning nsec values to sec fields is problematic in general, even
more so when the initial goal was to survive the 2030 timer
armageddon.
Fix by using the proper field in the initialization
Cc: Baolin Wang <baolin.wang@linaro.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Fixes: 07094ae6f9527 ("ALSA: Avoid using timespec for struct snd_timer_tread")
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20200111203325.20498-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Smatch complains that "ret" might be uninitialized.
Fixes: fbd3eb7f66c5 ("ALSA: control: Add verification for kctl accesses")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20200108053706.h3hcnvmnf62wkjac@kili.mountain
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Apply const prefix to the static flag info table.
Just for minor optimization and no functional changes.
Link: https://lore.kernel.org/r/20200105144823.29547-42-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Apply const prefix to the static tables for strings and formats.
Just for minor optimization and no functional changes.
Link: https://lore.kernel.org/r/20200105144823.29547-41-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Apply const prefix to the static jack switch table.
Just for minor optimization and no functional changes.
Link: https://lore.kernel.org/r/20200105144823.29547-40-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Apply const prefix to the string array and its callers.
Just for minor optimization and no functional changes.
Link: https://lore.kernel.org/r/20200105144823.29547-39-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Apply const prefix to the remaining sequencer code: the static tables
for MIDI macros, RPN/NRPN, and some strings.
Just for minor optimization and no functional changes.
Link: https://lore.kernel.org/r/20200105144823.29547-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Apply const prefix to more possible places: the string tables for PCM
format and co, the table for the PCM type helpers, etc.
Just for minor optimization and no functional changes.
Link: https://lore.kernel.org/r/20200105144823.29547-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The current implementation of ALSA control API fully relies on the
callbacks of each driver, and there is no verification of the values
passed via API. This patch is an attempt to improve the situation
slightly by adding the validation code for the values stored via info
and get callbacks.
The patch adds a new kconfig, CONFIG_SND_CTL_VALIDATION. It depends
on CONFIG_SND_DEBUG and off as default since the validation would
require a slight overhead including the additional call of info
callback at each get callback invocation.
When this config is enabled, the values stored by each info callback
invocation are verified, namely:
- Whether the info type is valid
- Whether the number of enum items is non-zero
- Whether the given info count is within the allowed boundary
Similarly, the values stored at each get callback are verified as
well:
- Whether the values are within the given range
- Whether the values are aligned with the given step
- Whether any further changes are seen in the data array over the
given info count
The last point helps identifying a possibly invalid data type access,
typically a case where the info callback declares the type being
SNDRV_CTL_ELEM_TYPE_ENUMERATED while the get/put callbacks store
the values in value.integer.value[] array.
When a validation fails, the ALSA core logs an error message including
the device and the control ID, and the API call also returns an
error. So, with the new validation turned on, the driver behavior
difference may be visible on user-space, too -- it's intentional,
though, so that we can catch an error more clearly.
The patch also introduces a new ctl access type,
SNDRV_CTL_ELEM_ACCESS_SKIP_CHECK. A driver may pass this flag with
other access bits to indicate that the ctl element won't be verified.
It's useful when a driver code is specially written to access the data
greater than info->count size by some reason. For example, this flag
is actually set now in HD-audio HDMI codec driver which needs to clear
the data array in the case of the disconnected monitor.
Also, the PCM channel-map helper code is slightly modified to avoid
the false-positive hit by this validation code, too.
Link: https://lore.kernel.org/r/20200104083556.27789-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The snd_mixer_oss_assign_table is read-only, and can it be declared as
const.
There should be no functional changes by this patch.
Link: https://lore.kernel.org/r/20200103081714.9560-32-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Change the argument of snd_midi_process_event() to receive a const
snd_midi_op pointer and its callers respectively. This allows further
optimizations.
There should be no functional changes by this patch.
Link: https://lore.kernel.org/r/20200103081714.9560-30-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Most of snd_timer_hardware definitions do simply copying to another
struct as-is. Mark them as const for further optimization.
There should be no functional changes by this patch.
Link: https://lore.kernel.org/r/20200103081714.9560-21-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Now we may declare const for snd_device_ops definitions, so let's do
it for optimization.
There should be no functional changes by this patch.
Link: https://lore.kernel.org/r/20200103081714.9560-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This is a preliminary patch to allow const for snd_device_ops
definitions in each driver's code. The ops reference is read-only,
hence it can be declared as const for further optimization.
There should be no functional changes by this patch.
Link: https://lore.kernel.org/r/20200103081714.9560-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
A design of ALSA control core allows applications to execute three
operations for TLV feature; read, write and command. Furthermore, it
allows driver developers to process the operations by two ways; allocated
array or callback function. In the former, read operation is just allowed,
thus developers uses the latter when device driver supports variety of
models or the target model is expected to dynamically change information
stored in TLV container.
The core also allows applications to lock any element so that the other
applications can't perform write operation to the element for element
value and TLV information. When the element is locked, write and command
operation for TLV information are prohibited as well as element value.
Any read operation should be allowed in the case.
At present, when an element has callback function for TLV information,
TLV read operation returns EPERM if the element is locked. On the
other hand, the read operation is success when an element has allocated
array for TLV information. In both cases, read operation is success for
element value expectedly.
This commit fixes the bug. This change can be backported to v4.14
kernel or later.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20191223093347.15279-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The 'dimen' member of 'struct snd_ctl_elem_info' is designed to deliver
information to use an array of value as multi-dimensional values. This
feature is used just by echoaudio PCI driver, and fortunately it's not
used by the other applications than 'echomixer' in alsa-tools.
In a previous commit, usage of 'dimen' member is removed from echoaudio
PCI driver. Nowadays no driver/application use the feature.
This commit removes the member from structure.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191223023921.8151-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Taking the 5.5 devel branch back into the main devel branch.
A USB-audio fix needs to be adjusted to adapt the changes that have
been formerly applied for stop_sync.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground into for-next
ALSA: Fix year 2038 issue for sound subsystem
This is a series I worked on with Baolin in 2017 and 2018, but we
never quite managed to finish up the last pieces. During the
ALSA developer meetup at ELC-E 2018 in Edinburgh, a decision was
made to go with this approach for keeping best compatibility
with existing source code, and then I failed to follow up by
resending the patches.
Now I have patches for all remaining time_t uses in the kernel,
so it's absolutely time to revisit them. I have done more
review of the patches myself and found a couple of minor issues
that I have fixed up, otherwise the series is still the same as
before.
Conceptually, the idea of these patches is:
- 64-bit applications should see no changes at all, neither
compile-time nor run-time.
- 32-bit code compiled with a 64-bit time_t currently
does not work with ALSA, and requires kernel changes and/or
sound/asound.h changes
- Most 32-bit code using these interfaces will work correctly
on a modified kernel, with or without the uapi header changes.
- 32-bit code using SNDRV_TIMER_IOCTL_TREAD requires the
updated header file for 64-bit time_t support
- 32-bit i386 user space with 64-bit time_t is broken for
SNDRV_PCM_IOCTL_STATUS, SNDRV_RAWMIDI_IOCTL_STATUS and
SNDRV_PCM_IOCTL_SYNC_PTR because of i386 alignment. This is also
addressed by the updated uapi header.
- PCM mmap is currently supported on native x86 kernels
(both 32-bit and 64-bit) but not for compat mode. This series breaks
the 32-bit native mmap support for 32-bit time_t, but instead allows
it for 64-bit time_t on both native and compat kernels. This seems to
be the best trade-off, as mmap support is optional already, and most
32-bit code runs in compat mode anyway.
- I've tried to avoid breaking compilation of 32-bit code
as much as possible. Anything that does break however is likely code
that is already broken on 64-bit time_t and needs source changes to
fix them.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git y2038-alsa-v8
[2] https://lore.kernel.org/lkml/CAK8P3a2Os66+iwQYf97qh05W2JP8rmWao8zmKoHiXqVHvyYAJA@mail.gmail.com/T/#m6519cb07cfda08adf1dedea6596bb98892b4d5dc
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Changes since v7: (Arnd):
- Fix a typo found by Ben Hutchings
Changes since v6: (Arnd):
- Add a patch to update the API versions
- Hide a timespec reference in #ifndef __KERNEL__ to remove the
last reference to time_t
- Use a more readable way to do padding and describe it in the
changelog
- Rebase to linux-5.5-rc1, changing include/sound/soc-component.h
and sound/drivers/aloop.c as needed.
Changes since v5 (Arnd):
- Rebased to linux-5.4-rc4
- Updated to completely remove timespec and time_t references from alsa
- found and fixed a few bugs
Changes since v4 (Baolin):
- Add patch 5 to change trigger_tstamp member of struct snd_pcm_runtime.
- Add patch 8 to change internal timespec.
- Add more explanation in commit message.
- Use ktime_get_real_ts64() in patch 6.
- Split common code out into a separate function in patch 6.
- Fix tu->tread bug in patch 6 and remove #if __BITS_PER_LONG == 64 macro.
Changes since v3:
- Move struct snd_pcm_status32 to pcm.h file.
- Modify comments and commit message.
- Add new patch2 ~ patch6.
Changes since v2:
- Renamed all structures to make clear.
- Remove CONFIG_X86_X32 macro and introduced new compat_snd_pcm_status64_x86_32.
Changes since v1:
- Add one macro for struct snd_pcm_status_32 which only active in 32bits kernel.
- Convert pcm_compat.c to use struct snd_pcm_status_64.
- Convert pcm_native.c to use struct snd_pcm_status_64.
|
|
The current PCM code doesn't initialize explicitly the buffers
allocated for PCM streams, hence it might leak some uninitialized
kernel data or previous stream contents by mmapping or reading the
buffer before actually starting the stream.
Since this is a common problem, this patch simply adds the clearance
of the buffer data at hw_params callback. Although this does only
zero-clear no matter which format is used, which doesn't mean the
silence for some formats, but it should be OK because the intention is
just to clear the previous data on the buffer.
Reported-by: Lionel Koenig <lionel.koenig@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191211155742.3213-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Control elements for PCM chmap return information to userspace abount
the maximum number of available PCM channels as the number of values
in the element.
In current implementation the number is once initialized to zero, then
assigned to. This is useless and this commit fixes it.
Fixes: 2d3391ec0ecc ("ALSA: PCM: channel mapping API implementation")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191214131351.28950-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The snd_pcm_mmap_status and snd_pcm_mmap_control interfaces are one of the
trickiest areas to get right when moving to 64-bit time_t in user space.
The snd_pcm_mmap_status structure layout is incompatible with user space
that uses a 64-bit time_t, so we need a new layout for it. Since the
SNDRV_PCM_IOCTL_SYNC_PTR ioctl combines it with snd_pcm_mmap_control
into snd_pcm_sync_ptr, we need to change those two as well.
Both structures are also exported via an mmap() operation on certain
architectures, and this suffers from incompatibility between 32-bit
and 64-bit user space. As we have to change both structures anyway,
this is a good opportunity to fix the mmap() problem as well, so let's
standardize on the existing 64-bit layout of the structure where possible.
The downside is that we lose mmap() support for existing 32-bit x86 and
powerpc applications, adding that would introduce very noticeable runtime
overhead and complexity. My assumption here is that not too many people
will miss the removed feature, given that:
- Almost all x86 and powerpc users these days are on 64-bit kernels,
the majority of today's 32-bit users are on architectures that never
supported mmap (ARM, MIPS, ...).
- It never worked in compat mode (it was intentionally disabled there)
- The application already needs to work with a fallback to
SNDRV_PCM_IOCTL_SYNC_PTR, which will keep working with both the old
and new structure layout.
Both the ioctl() and mmap() based interfaces are changed at the same
time, as they are based on the same structures. Unlike other interfaces,
we change the uapi header to export both the traditional structure and
a version that is portable between 32-bit and 64-bit user space code
and that corresponds to the existing 64-bit layout. We further check the
__USE_TIME_BITS64 macro that will be defined by future C library versions
whenever we use the new time_t definition, so any existing user space
source code will not see any changes until it gets rebuilt against a new
C library. However, the new structures are all visible in addition to the
old ones, allowing applications to explicitly request the new structures.
In order to detect the difference between the old snd_pcm_mmap_status and
the new __snd_pcm_mmap_status64 structure from the ioctl command number,
we rely on one quirk in the structure definition: snd_pcm_mmap_status
must be aligned to alignof(time_t), which leads the compiler to insert
four bytes of padding in struct snd_pcm_sync_ptr after 'flags' and a
corresponding change in the size of snd_pcm_sync_ptr itself. On x86-32
(and only there), the compiler doesn't use 64-bit alignment in structure,
so I'm adding an explicit pad in the structure that has no effect on the
existing 64-bit architectures but ensures that the layout matches for x86.
The snd_pcm_uframes_t type compatibility requires another hack: we can't
easily make that 64 bit wide, so I leave the type as 'unsigned long',
but add padding before and after it, to ensure that the data is properly
aligned to the respective 64-bit field in the in-kernel structure.
For the SNDRV_PCM_MMAP_OFFSET_STATUS/CONTROL constants that are used
as the virtual file offset in the mmap() function, we also have to
introduce new constants that depend on hte __USE_TIME_BITS64 macro:
The existing macros are renamed to SNDRV_PCM_MMAP_OFFSET_STATUS_OLD
and SNDRV_PCM_MMAP_OFFSET_CONTROL_OLD, they continue to work fine on
64-bit architectures, but stop working on native 32-bit user space.
The replacement _NEW constants are now used by default for user space
built with __USE_TIME_BITS64, those now work on all new kernels for x86,
ppc and alpha (32 and 64 bit, native and compat). It might be a good idea
for a future alsa-lib to support both the _OLD and _NEW macros and use
the corresponding structures directly. Unmodified alsa-lib source code
will retain the current behavior, so it will no longer be able to use
mmap() for the status/control structures on 32-bit systems, until either
the C library gets updated to 64-bit time_t or alsa-lib gets updated to
support both mmap() layouts.
Co-developed-with: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
This is a preparation patch, moving the compat handler for
snd_pcm_ioctl_sync_ptr_compat from pcm_compat.c to pcm_native.c.
No other changes are indented.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The struct snd_timer_tread will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Since the struct snd_timer_tread is passed through read() rather than
ioctl(), and the read syscall has no command number that lets us pick
between the 32-bit or 64-bit version of this structure.
Thus we introduced one new command SNDRV_TIMER_IOCTL_TREAD64 and new
struct snd_timer_tread64 replacing timespec with s64 type to handle
64bit time_t. That means we will set tu->tread = TREAD_FORMAT_64BIT
when user space has a 64bit time_t, then we will copy to user with
struct snd_timer_tread64. Otherwise we will use 32bit time_t variables
when copying to user.
Moreover this patch replaces timespec type with timespec64 type and
related y2038 safe APIs.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The struct snd_rawmidi_status will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Thus we introduced 'struct snd_rawmidi_status32' and 'struct snd_rawmidi_status64'
to handle 32bit time_t and 64bit time_t in native mode, which replace
timespec with s64 type.
In compat mode, we renamed or introduced new structures to handle 32bit/64bit
time_t in compatible mode. The 'struct snd_rawmidi_status32' and
snd_rawmidi_ioctl_status32() are used to handle 32bit time_t in compat mode.
'struct compat_snd_rawmidi_status64' is used to handle 64bit time_t.
When glibc changes time_t to 64-bit, any recompiled program will issue ioctl
commands that the kernel does not understand without this patch.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
The struct snd_pcm_status will use 'timespec' type variables to record
timestamp, which is not year 2038 safe on 32bits system.
Userspace will use SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
as commands to issue ioctl() to fill the 'snd_pcm_status' structure in
userspace. The command number is always defined through _IOR/_IOW/IORW,
so when userspace changes the definition of 'struct timespec' to use
64-bit types, the command number also changes.
Thus in the kernel, we now need to define two versions of each such ioctl
and corresponding ioctl commands to handle 32bit time_t and 64bit time_t
in native mode:
struct snd_pcm_status32 {
......
s32 trigger_tstamp_sec;
s32 trigger_tstamp_nsec;
......
s32 audio_tstamp_sec;
s32 audio_tstamp_nsec;
......
};
struct snd_pcm_status64 {
......
s32 trigger_tstamp_sec;
s32 trigger_tstamp_nsec;
......
s32 audio_tstamp_sec;
s32 audio_tstamp_nsec;
......
};
Moreover in compat file, we renamed or introduced new structures to handle
32bit/64bit time_t in compatible mode. The 'struct snd_pcm_status32' and
snd_pcm_status_user32() are used to handle 32bit time_t in compat mode.
'struct compat_snd_pcm_status64' and snd_pcm_status_user_compat64() are used
to handle 64bit time_t.
The implicit padding before timespec is made explicit to avoid incompatible
structure layout between 32-bit and 64-bit x86 due to the different
alignment requirements, and the snd_pcm_status structure is now hidden
from the kernel to avoid relying on the timespec definitio definitionn
Finally we can replace SNDRV_PCM_IOCTL_STATUS and SNDRV_PCM_IOCTL_STATUS_EXT
with new commands and introduce new functions to fill new 'struct snd_pcm_status64'
instead of using unsafe 'struct snd_pcm_status'. Then in future, the new
commands can be matched when userspace changes 'timespec' to 64bit type
to make a size change of 'struct snd_pcm_status'. When glibc changes time_t
to 64-bit, any recompiled program will issue ioctl commands that the kernel
does not understand without this patch.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
struct snd_timer_status uses 'timespec' type variables to record
timestamp, which will be changed to an incompatible layout with
updated user space using 64-bit time_t.
To handle both the old and the new layout on 32-bit architectures,
this patch introduces 'struct snd_timer_status32' and 'struct snd_timer_status64'
to handle 32bit time_t and 64bit time_t in native mode and compat mode,
which replaces timespec with s64 type.
When glibc changes time_t to 64-bit, any recompiled program will issue
ioctl commands that the kernel does not understand without this patch.
In the public uapi header, snd_timer_status is now guarded by
an #ifndef __KERNEL__ to avoid referencing 'struct timespec'.
The timespec definition will be removed from the kernel to prevent
new y2038 bugs and to avoid the conflict with an incompatible libc
type of the same name.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
Since timespec is not year 2038 safe on 32bit system, and we need to
convert all timespec variables to timespec64 type for sound subsystem.
This patch is used to do preparation for following patches, that will
convert all structures defined in uapi/sound/asound.h to use 64-bit
time_t.
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull more sound updates from Takashi Iwai:
"A few last-minute updates, most of them are the regression fixes:
- AMD HD-audio HDMI runtime PM improvements
- Fixes for HD-audio HDMI regressions wrt DP-MST
- A regression fix for the previous aloop enhancement
- A fix for a long-time problem in PCM OSS layer that was spotted by
fuzzer now
- A few HD-audio quirks"
* tag 'sound-fix-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: pcm: oss: Avoid potential buffer overflows
ALSA: hda: hdmi - Keep old slot assignment behavior for Intel platforms
ALSA: hda: Modify stream stripe mask only when needed
ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen
ALSA: hda: hdmi - preserve non-MST PCM routing for Intel platforms
ALSA: hda: hdmi - fix kernel oops caused by invalid PCM idx
ALSA: hda/realtek - Fix inverted bass GPIO pin on Acer 8951G
ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236
ALSA: hda: hdmi - fix regression in connect list handling
ALSA: aloop: Avoid pointer dereference before null-check
ALSA: hda/hdmi - enable automatic runtime pm for AMD HDMI codecs by default
ALSA: hda/hdmi - enable runtime pm for newer AMD display audio
ALSA: hda/hdmi - Add new pci ids for AMD GPU display audio
ALSA: hda/hdmi - fix vgaswitcheroo detection for AMD
|
Michał Mirosław
Changming Liu
Brent Lu
Takashi Iwai
Linus Torvalds
Alexey Dobriyan
Pierre-Louis Bossart
Dan Carpenter
Takashi Sakamoto
Arnd Bergmann
Baolin Wang