aboutsummaryrefslogtreecommitdiffstats
path: root/sound/core (follow)
AgeCommit message (Collapse)AuthorFilesLines
2020-03-16ALSA: seq: oss: Fix running status after receiving sysexTakashi Iwai1-0/+1
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>
2020-03-16ALSA: seq: virmidi: Fix running status after receiving sysexTakashi Iwai1-0/+1
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>
2020-03-12ALSA: pcm: oss: Remove WARNING from snd_pcm_plug_alloc() checksTakashi Iwai1-2/+2
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>
2020-03-09ALSA: pcm: oss: Avoid plugin buffer overflowTakashi Iwai1-0/+8
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>
2020-02-14ALSA: seq: Fix concurrent access to queue current tick/timeTakashi Iwai4-9/+20
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>
2020-02-14ALSA: seq: Avoid concurrent access to queue flagsTakashi Iwai1-4/+16
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>
2020-02-13ALSA: pcm: Fix double hw_free callsTakashi Iwai1-1/+2
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>
2020-02-06Merge tag 'sound-fix-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds2-79/+140
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 ...
2020-02-04proc: convert everything to "struct proc_ops"Alexey Dobriyan1-19/+17
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>
2020-01-31ALSA: pcm: Fix sparse warnings wrt snd_pcm_state_tTakashi Iwai2-70/+125
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>
2020-01-29ALSA: pcm: Fix memory leak at closing a stream without hw_freeTakashi Iwai1-9/+15
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>
2020-01-21ALSA: pcm: Set per-card upper limit of PCM buffer allocationsTakashi Iwai2-18/+52
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>
2020-01-20Merge branch 'for-linus' into for-nextTakashi Iwai1-5/+9
Resolved the merge conflict in HD-audio Tegra driver. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2020-01-16ALSA: pcm: Make snd_pcm_hw_constraints_init() and _complete() staticTakashi Iwai2-5/+2
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>
2020-01-15ALSA: seq: Fix racy access for queue timer in proc readTakashi Iwai1-5/+9
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>
2020-01-12ALSA: timer: fix nsec/sec initialization confusionPierre-Louis Bossart1-1/+1
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>
2020-01-08ALSA: control: potential uninitialized return valueDan Carpenter1-1/+1
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>
2020-01-05ALSA: rawmidi: More constificationTakashi Iwai1-1/+1
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>
2020-01-05ALSA: oss: More constificationsTakashi Iwai2-2/+2
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>
2020-01-05ALSA: jack: More constificationTakashi Iwai1-1/+1
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>
2020-01-05ALSA: info: More constificationsTakashi Iwai1-2/+2
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>
2020-01-05ALSA: seq: More constificationsTakashi Iwai3-8/+8
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>
2020-01-05ALSA: pcm: More constificationsTakashi Iwai3-9/+10
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>
2020-01-04ALSA: control: Add verification for kctl accessesTakashi Iwai3-38/+256
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>
2020-01-03ALSA: mixer: oss: Constify snd_mixer_oss_assign_table definitionTakashi Iwai1-6/+8
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>
2020-01-03ALSA: seq: Constify struct snd_midi_opTakashi Iwai1-15/+22
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>
2020-01-03ALSA: timer: Constify snd_timer_hardware definitionsTakashi Iwai2-2/+2
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>
2020-01-03ALSA: core: Constify snd_device_ops definitionsTakashi Iwai8-9/+9
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>
2020-01-03ALSA: core: Treat snd_device_ops as constTakashi Iwai1-1/+1
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>
2019-12-24ALSA: ctl: allow TLV read operation for callback type of element in locked caseTakashi Sakamoto1-2/+3
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>
2019-12-23ALSA: ctl: remove dimen member from elem_info structureTakashi Sakamoto1-32/+0
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>
2019-12-18Merge branch 'for-linus' into for-nextTakashi Iwai1-0/+4
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>
2019-12-17Merge tag 'y2038-alsa-v8-signed' of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground into for-nextTakashi Iwai8-455/+614
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.
2019-12-14ALSA: pcm: Avoid possible info leaks from PCM stream buffersTakashi Iwai1-0/+4
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>
2019-12-14ALSA: control: remove useless assignment in .info callback of PCM chmap elementTakashi Sakamoto1-1/+0
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>
2019-12-13ALSA: add new 32-bit layout for snd_pcm_mmap_status/controlArnd Bergmann3-31/+47
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>
2019-12-13ALSA: move snd_pcm_ioctl_sync_ptr_compat into pcm_native.cArnd Bergmann2-98/+100
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>
2019-12-13ALSA: Avoid using timespec for struct snd_timer_treadBaolin Wang2-38/+117
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>
2019-12-11ALSA: Avoid using timespec for struct snd_rawmidi_statusBaolin Wang2-94/+125
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>
2019-12-11ALSA: Avoid using timespec for struct snd_pcm_statusBaolin Wang3-124/+138
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>
2019-12-11ALSA: Avoid using timespec for struct snd_timer_statusBaolin Wang2-57/+62
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>
2019-12-11ALSA: Replace timespec with timespec64Baolin Wang3-32/+44
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>
2019-12-06Merge tag 'sound-fix-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds3-0/+6
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
2019-12-04ALSA: pcm: oss: Avoid potential buffer overflowsTakashi Iwai3-0/+6
syzkaller reported an invalid access in PCM OSS read, and this seems to be an overflow of the internal buffer allocated for a plugin. Since the rate plugin adjusts its transfer size dynamically, the calculation for the chained plugin might be bigger than the given buffer size in some extreme cases, which lead to such an buffer overflow as caught by KASAN. Fix it by limiting the max transfer size properly by checking against the destination size in each plugin transfer callback. Reported-by: syzbot+f153bde47a62e0b05f83@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191204144824.17801-1-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-12-01Merge tag 'compat-ioctl-5.5' of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playgroundLinus Torvalds1-0/+4
Pull removal of most of fs/compat_ioctl.c from Arnd Bergmann: "As part of the cleanup of some remaining y2038 issues, I came to fs/compat_ioctl.c, which still has a couple of commands that need support for time64_t. In completely unrelated work, I spent time on cleaning up parts of this file in the past, moving things out into drivers instead. After Al Viro reviewed an earlier version of this series and did a lot more of that cleanup, I decided to try to completely eliminate the rest of it and move it all into drivers. This series incorporates some of Al's work and many patches of my own, but in the end stops short of actually removing the last part, which is the scsi ioctl handlers. I have patches for those as well, but they need more testing or possibly a rewrite" * tag 'compat-ioctl-5.5' of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground: (42 commits) scsi: sd: enable compat ioctls for sed-opal pktcdvd: add compat_ioctl handler compat_ioctl: move SG_GET_REQUEST_TABLE handling compat_ioctl: ppp: move simple commands into ppp_generic.c compat_ioctl: handle PPPIOCGIDLE for 64-bit time_t compat_ioctl: move PPPIOCSCOMPRESS to ppp_generic compat_ioctl: unify copy-in of ppp filters tty: handle compat PPP ioctls compat_ioctl: move SIOCOUTQ out of compat_ioctl.c compat_ioctl: handle SIOCOUTQNSD af_unix: add compat_ioctl support compat_ioctl: reimplement SG_IO handling compat_ioctl: move WDIOC handling into wdt drivers fs: compat_ioctl: move FITRIM emulation into file systems gfs2: add compat_ioctl support compat_ioctl: remove unused convert_in_user macro compat_ioctl: remove last RAID handling code compat_ioctl: remove /dev/raw ioctl translation compat_ioctl: remove PCI ioctl translation compat_ioctl: remove joystick ioctl translation ...
2019-11-20ALSA: pcm: Add card sync_irq fieldTakashi Iwai2-0/+3
Many PCI and other drivers performs snd_pcm_period_elapsed() simply in its interrupt handler, so the sync_stop operation is just to call synchronize_irq(). Instead of putting this call multiple times, introduce the common card->sync_irq field. When this field is set, PCM core performs synchronize_irq() for sync-stop operation. Each driver just needs to copy its local IRQ number to card->sync_irq, and that's all we need. Link: https://lore.kernel.org/r/20191117085308.23915-8-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-20ALSA: pcm: Add the support for sync-stop operationTakashi Iwai1-0/+15
The standard programming model of a PCM sound driver is to process snd_pcm_period_elapsed() from an interrupt handler. When a running stream is stopped, PCM core calls the trigger-STOP PCM ops, sets the stream state to SETUP, and moves on to the next step. This is performed in an atomic manner -- this could be called from the interrupt context, after all. The problem is that, if the stream goes further and reaches to the CLOSE state immediately, the stream might be still being processed in snd_pcm_period_elapsed() in the interrupt context, and hits a NULL dereference. Such a crash happens because of the atomic operation, and we can't wait until the stream-stop finishes. For addressing such a problem, this commit adds a new PCM ops, sync_stop. This gets called at the appropriate places that need a sync with the stream-stop, i.e. at hw_params, prepare and hw_free. Some drivers already have a similar mechanism implemented locally, and we'll refactor the code later. Link: https://lore.kernel.org/r/20191117085308.23915-7-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-20ALSA: pcm: Move PCM_RUNTIME_CHECK() macro into local headerTakashi Iwai2-0/+3
It should be used only in the PCM core code locally. Link: https://lore.kernel.org/r/20191117085308.23915-6-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-20ALSA: pcm: Allow NULL ioctl opsTakashi Iwai1-4/+15
Currently PCM ioctl ops is a mandatory field but almost all drivers simply pass snd_pcm_lib_ioctl. For simplicity, allow to set NULL in the field and call snd_pcm_lib_ioctl() as default. Link: https://lore.kernel.org/r/20191117085308.23915-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
2019-11-20ALSA: pcm: Introduce managed buffer allocation modeTakashi Iwai2-13/+82
This patch adds the support for the feature to automatically allocate and free PCM buffers, so called "managed buffer allocation" mode. It's set up via new PCM helpers, snd_pcm_set_managed_buffer() and snd_pcm_set_managed_buffer_all(), both of which correspond to the existing preallocator helpers, snd_pcm_lib_preallocate_pages() and snd_pcm_lib_preallocate_pages_for_all(). When the new helper is used, it not only performs the pre-allocation of buffers, but also it manages to call snd_pcm_lib_malloc_pages() before the PCM hw_params ops and snd_lib_pcm_free() after the PCM hw_free ops inside PCM core, respectively. This allows drivers to drop the explicit calls of the memory allocation / release functions, and it will be a good amount of code reduction in the end of this patch series. When the PCM substream is set to the managed buffer allocation mode, the managed_buffer_alloc flag is set in the substream object. Since some drivers want to know when a buffer is newly allocated or re-allocated at hw_params callback (e.g. want to set up the additional stuff for the given buffer only at allocation time), now PCM core turns on buffer_changed flag when the buffer has changed. The standard conversions to use the new API will be straightforward: - Replace snd_pcm_lib_preallocate*() calls with the corresponding snd_pcm_set_managed_buffer*(); the arguments should be unchanged - Drop superfluous snd_pcm_lib_malloc() and snd_pcm_lib_free() calls; the check of snd_pcm_lib_malloc() returns should be replaced with the check of runtime->buffer_changed flag. - If hw_params or hw_free becomes empty, drop them from PCM ops Link: https://lore.kernel.org/r/20191117085308.23915-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>