summaryrefslogtreecommitdiffstats
path: root/sound/core/rawmidi.c
Commit message (Collapse)AuthorAgeFilesLines
* ALSA: rawmidi: A lightweight function to discard pending bytesTakashi Iwai2018-10-041-0/+22
| | | | | | | | | | For discarding the pending bytes on rawmidi, we process with a loop of snd_rawmidi_transmit() which is just a waste of CPU power. Implement a lightweight API function to discard the pending bytes and the proceed the ring buffer instantly, and use it instead of open codes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Initialize allocated buffersTakashi Iwai2018-09-031-2/+2
| | | | | | | | | | | syzbot reported the uninitialized value exposure in certain situations using virmidi loop. It's likely a very small race at writing and reading, and the influence is almost negligible. But it's safer to paper over this just by replacing the existing kvmalloc() with kvzalloc(). Reported-by: syzbot+194dffdb8b22fc5d207a@syzkaller.appspotmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Use kvmalloc() for buffersTakashi Iwai2018-07-181-4/+5
| | | | | | | | | | | The size of in-kernel rawmidi buffers may be big up to 1MB, and it can be specified freely by user-space; which implies that user-space may trigger kmalloc() errors frequently. This patch replaces the buffer allocation via kvmalloc() for dealing with bigger buffers gracefully. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Minor code refactoringTakashi Iwai2018-07-171-44/+33Star
| | | | | | | | | | | Unify a few open codes with helper functions to improve the readability. Minor behavior changes (rather fixes) are: - runtime->drain clearance is done within lock - active_sensing is updated before resizing buffer in SNDRV_RAWMIDI_IOCTL_PARAMS ioctl. Other than that, simply code cleanups. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Simplify error pathsTakashi Iwai2018-07-171-37/+39
| | | | | | | | | Apply the standard idiom: rewrite the multiple unlocks in error paths in the goto-error-and-single-unlock way. Just a code refactoring, and no functional changes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Tidy up coding stylesTakashi Iwai2018-07-171-42/+59
| | | | | | | Just minor coding style fixes like removal of superfluous white space, adding missing blank lines, etc. No actual code changes at all. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Change resized buffers atomicallyTakashi Iwai2018-07-171-6/+14
| | | | | | | | | | | | | The SNDRV_RAWMIDI_IOCTL_PARAMS ioctl may resize the buffers and the current code is racy. For example, the sequencer client may write to buffer while it being resized. As a simple workaround, let's switch to the resized buffer inside the stream runtime lock. Reported-by: syzbot+52f83f0ea8df16932f7f@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* vfs: do bulk POLL* -> EPOLL* replacementLinus Torvalds2018-02-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge branch 'misc.poll' of ↵Linus Torvalds2018-01-311-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull poll annotations from Al Viro: "This introduces a __bitwise type for POLL### bitmap, and propagates the annotations through the tree. Most of that stuff is as simple as 'make ->poll() instances return __poll_t and do the same to local variables used to hold the future return value'. Some of the obvious brainos found in process are fixed (e.g. POLLIN misspelled as POLL_IN). At that point the amount of sparse warnings is low and most of them are for genuine bugs - e.g. ->poll() instance deciding to return -EINVAL instead of a bitmap. I hadn't touched those in this series - it's large enough as it is. Another problem it has caught was eventpoll() ABI mess; select.c and eventpoll.c assumed that corresponding POLL### and EPOLL### were equal. That's true for some, but not all of them - EPOLL### are arch-independent, but POLL### are not. The last commit in this series separates userland POLL### values from the (now arch-independent) kernel-side ones, converting between them in the few places where they are copied to/from userland. AFAICS, this is the least disruptive fix preserving poll(2) ABI and making epoll() work on all architectures. As it is, it's simply broken on sparc - try to give it EPOLLWRNORM and it will trigger only on what would've triggered EPOLLWRBAND on other architectures. EPOLLWRBAND and EPOLLRDHUP, OTOH, are never triggered at all on sparc. With this patch they should work consistently on all architectures" * 'misc.poll' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (37 commits) make kernel-side POLL... arch-independent eventpoll: no need to mask the result of epi_item_poll() again eventpoll: constify struct epoll_event pointers debugging printk in sg_poll() uses %x to print POLL... bitmap annotate poll(2) guts 9p: untangle ->poll() mess ->si_band gets POLL... bitmap stored into a user-visible long field ring_buffer_poll_wait() return value used as return value of ->poll() the rest of drivers/*: annotate ->poll() instances media: annotate ->poll() instances fs: annotate ->poll() instances ipc, kernel, mm: annotate ->poll() instances net: annotate ->poll() instances apparmor: annotate ->poll() instances tomoyo: annotate ->poll() instances sound: annotate ->poll() instances acpi: annotate ->poll() instances crypto: annotate ->poll() instances block: annotate ->poll() instances x86: annotate ->poll() instances ...
| * sound: annotate ->poll() instancesAl Viro2017-11-271-2/+2
| | | | | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | ALSA: rawmidi: Avoid racy info ioctl via ctl deviceTakashi Iwai2017-12-141-3/+12
|/ | | | | | | | | | | | | | | | | | The rawmidi also allows to obtaining the information via ioctl of ctl API. It means that user can issue an ioctl to the rawmidi device even when it's being removed as long as the control device is present. Although the code has some protection via the global register_mutex, its range is limited to the search of the corresponding rawmidi object, and the mutex is already unlocked at accessing the rawmidi object. This may lead to a use-after-free. For avoiding it, this patch widens the application of register_mutex to the whole snd_rawmidi_info_select() function. We have another mutex per rawmidi object, but this operation isn't very hot path, so it shouldn't matter from the performance POV. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge tag 'sound-4.13-rc1' of ↵Linus Torvalds2017-07-061-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * ALSA: seq: Allow the modular sequencer registrationTakashi Iwai2017-06-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many drivers bind the sequencer stuff in off-load by another driver module, so that it's loaded only on demand. In the current code, this mechanism doesn't work when the driver is built-in while the sequencer is module. We check with IS_REACHABLE() and enable only when the sequencer is in the same level of build. However, this is basically a overshoot. The binder code (snd-seq-device) is an individual module from the sequencer core (snd-seq), and we just have to make the former a built-in while keeping the latter a module for allowing the scenario like the above. This patch achieves that by rewriting Kconfig slightly. Now, a driver that provides the manual sequencer device binding should select CONFIG_SND_SEQ_DEVICE in a way as select SND_SEQ_DEVICE if SND_SEQUENCER != n Note that the "!=n" is needed here to avoid the influence of the sequencer core is module while the driver is built-in. Also, since rawmidi.o may be linked with snd_seq_device.o when built-in, we have to shuffle the code to make the linker happy. (the kernel linker isn't smart enough yet to handle such a case.) That is, snd_seq_device.c is moved to sound/core from sound/core/seq, as well as Makefile. Last but not least, the patch replaces the code using IS_REACHABLE() with IS_ENABLED(), since now the condition meets always when enabled. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | sched/wait: Rename wait_queue_t => wait_queue_entry_tIngo Molnar2017-06-201-4/+4
|/ | | | | | | | | | | | | | | | | | | | | | 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>
* sched/headers: Prepare to move signal wakeup & sigpending methods from ↵Ingo Molnar2017-03-021-1/+1
| | | | | | | | | | | | | <linux/sched.h> into <linux/sched/signal.h> Fix up affected files that include this signal functionality via sched.h. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> 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>
* ALSA: rawmidi: Add const to snd_rawmidi_opsTakashi Iwai2017-01-121-1/+1
| | | | | | | | | Make snd_rawmidi_substream.ops to be a const pointer to be safer and allow more optimization. The patches to constify each rawmidi ops will follow. Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: don't opencode IS_REACHABLE()Fabian Frederick2016-11-121-2/+2
| | | | | Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Fix possible deadlock with virmidi registrationTakashi Iwai2016-09-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a seq-virmidi driver is initialized, it registers a rawmidi instance with its callback to create an associated seq kernel client. Currently it's done throughly in rawmidi's register_mutex context. Recently it was found that this may lead to a deadlock another rawmidi device that is being attached with the sequencer is accessed, as both open with the same register_mutex. This was actually triggered by syzkaller, as Dmitry Vyukov reported: ====================================================== [ INFO: possible circular locking dependency detected ] 4.8.0-rc1+ #11 Not tainted ------------------------------------------------------- syz-executor/7154 is trying to acquire lock: (register_mutex#5){+.+.+.}, at: [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341 but task is already holding lock: (&grp->list_mutex){++++.+}, at: [<ffffffff850138bb>] check_and_subscribe_port+0x5b/0x5c0 sound/core/seq/seq_ports.c:495 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&grp->list_mutex){++++.+}: [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746 [<ffffffff863f6199>] down_read+0x49/0xc0 kernel/locking/rwsem.c:22 [< inline >] deliver_to_subscribers sound/core/seq/seq_clientmgr.c:681 [<ffffffff85005c5e>] snd_seq_deliver_event+0x35e/0x890 sound/core/seq/seq_clientmgr.c:822 [<ffffffff85006e96>] > snd_seq_kernel_client_dispatch+0x126/0x170 sound/core/seq/seq_clientmgr.c:2418 [<ffffffff85012c52>] snd_seq_system_broadcast+0xb2/0xf0 sound/core/seq/seq_system.c:101 [<ffffffff84fff70a>] snd_seq_create_kernel_client+0x24a/0x330 sound/core/seq/seq_clientmgr.c:2297 [< inline >] snd_virmidi_dev_attach_seq sound/core/seq/seq_virmidi.c:383 [<ffffffff8502d29f>] snd_virmidi_dev_register+0x29f/0x750 sound/core/seq/seq_virmidi.c:450 [<ffffffff84fd208c>] snd_rawmidi_dev_register+0x30c/0xd40 sound/core/rawmidi.c:1645 [<ffffffff84f816d3>] __snd_device_register.part.0+0x63/0xc0 sound/core/device.c:164 [< inline >] __snd_device_register sound/core/device.c:162 [<ffffffff84f8235d>] snd_device_register_all+0xad/0x110 sound/core/device.c:212 [<ffffffff84f7546f>] snd_card_register+0xef/0x6c0 sound/core/init.c:749 [<ffffffff85040b7f>] snd_virmidi_probe+0x3ef/0x590 sound/drivers/virmidi.c:123 [<ffffffff833ebf7b>] platform_drv_probe+0x8b/0x170 drivers/base/platform.c:564 ...... -> #0 (register_mutex#5){+.+.+.}: [< inline >] check_prev_add kernel/locking/lockdep.c:1829 [< inline >] check_prevs_add kernel/locking/lockdep.c:1939 [< inline >] validate_chain kernel/locking/lockdep.c:2266 [<ffffffff814791f4>] __lock_acquire+0x4d44/0x4d80 kernel/locking/lockdep.c:3335 [<ffffffff8147a3a8>] lock_acquire+0x208/0x430 kernel/locking/lockdep.c:3746 [< inline >] __mutex_lock_common kernel/locking/mutex.c:521 [<ffffffff863f0ef1>] mutex_lock_nested+0xb1/0xa20 kernel/locking/mutex.c:621 [<ffffffff84fd6d4b>] snd_rawmidi_kernel_open+0x4b/0x260 sound/core/rawmidi.c:341 [<ffffffff8502e7c7>] midisynth_subscribe+0xf7/0x350 sound/core/seq/seq_midi.c:188 [< inline >] subscribe_port sound/core/seq/seq_ports.c:427 [<ffffffff85013cc7>] check_and_subscribe_port+0x467/0x5c0 sound/core/seq/seq_ports.c:510 [<ffffffff85015da9>] snd_seq_port_connect+0x2c9/0x500 sound/core/seq/seq_ports.c:579 [<ffffffff850079b8>] snd_seq_ioctl_subscribe_port+0x1d8/0x2b0 sound/core/seq/seq_clientmgr.c:1480 [<ffffffff84ffe9e4>] snd_seq_do_ioctl+0x184/0x1e0 sound/core/seq/seq_clientmgr.c:2225 [<ffffffff84ffeae8>] snd_seq_kernel_client_ctl+0xa8/0x110 sound/core/seq/seq_clientmgr.c:2440 [<ffffffff85027664>] snd_seq_oss_midi_open+0x3b4/0x610 sound/core/seq/oss/seq_oss_midi.c:375 [<ffffffff85023d67>] snd_seq_oss_synth_setup_midi+0x107/0x4c0 sound/core/seq/oss/seq_oss_synth.c:281 [<ffffffff8501b0a8>] snd_seq_oss_open+0x748/0x8d0 sound/core/seq/oss/seq_oss_init.c:274 [<ffffffff85019d8a>] odev_open+0x6a/0x90 sound/core/seq/oss/seq_oss.c:138 [<ffffffff84f7040f>] soundcore_open+0x30f/0x640 sound/sound_core.c:639 ...... other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&grp->list_mutex); lock(register_mutex#5); lock(&grp->list_mutex); lock(register_mutex#5); *** DEADLOCK *** ====================================================== The fix is to simply move the registration parts in snd_rawmidi_dev_register() to the outside of the register_mutex lock. The lock is needed only to manage the linked list, and it's not necessarily to cover the whole initialization process. Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Fix race at copying & updating the positionTakashi Iwai2016-02-031-12/+22
| | | | | | | | | | | | | | | | | | | | | | | | The rawmidi read and write functions manage runtime stream status such as runtime->appl_ptr and runtime->avail. These point where to copy the new data and how many bytes have been copied (or to be read). The problem is that rawmidi read/write call copy_from_user() or copy_to_user(), and the runtime spinlock is temporarily unlocked and relocked while copying user-space. Since the current code advances and updates the runtime status after the spin unlock/relock, the copy and the update may be asynchronous, and eventually runtime->avail might go to a negative value when many concurrent accesses are done. This may lead to memory corruption in the end. For fixing this race, in this patch, the status update code is performed in the same lock before the temporary unlock. Also, the spinlock is now taken more widely in snd_rawmidi_kernel_read1() for protecting more properly during the whole operation. BugLink: http://lkml.kernel.org/r/CACT4Y+b-dCmNf1GpgPKfDO0ih+uZCL2JV4__j-r1kdhPLSgQCQ@mail.gmail.com Reported-by: Dmitry Vyukov <dvyukov@google.com> Tested-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Make snd_rawmidi_transmit() race-freeTakashi Iwai2016-02-031-26/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A kernel WARNING in snd_rawmidi_transmit_ack() is triggered by syzkaller fuzzer: WARNING: CPU: 1 PID: 20739 at sound/core/rawmidi.c:1136 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 [<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 [<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 [<ffffffff84f80bd5>] snd_rawmidi_transmit_ack+0x275/0x400 sound/core/rawmidi.c:1136 [<ffffffff84fdb3c1>] snd_virmidi_output_trigger+0x4b1/0x5a0 sound/core/seq/seq_virmidi.c:163 [< inline >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150 [<ffffffff84f87ed9>] snd_rawmidi_kernel_write1+0x549/0x780 sound/core/rawmidi.c:1223 [<ffffffff84f89fd3>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1273 [<ffffffff817b0323>] __vfs_write+0x113/0x480 fs/read_write.c:528 [<ffffffff817b1db7>] vfs_write+0x167/0x4a0 fs/read_write.c:577 [< inline >] SYSC_write fs/read_write.c:624 [<ffffffff817b50a1>] SyS_write+0x111/0x220 fs/read_write.c:616 [<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 Also a similar warning is found but in another path: Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff82be2c0d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 [<ffffffff81355139>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 [<ffffffff81355369>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515 [<ffffffff8527e69a>] rawmidi_transmit_ack+0x24a/0x3b0 sound/core/rawmidi.c:1133 [<ffffffff8527e851>] snd_rawmidi_transmit_ack+0x51/0x80 sound/core/rawmidi.c:1163 [<ffffffff852d9046>] snd_virmidi_output_trigger+0x2b6/0x570 sound/core/seq/seq_virmidi.c:185 [< inline >] snd_rawmidi_output_trigger sound/core/rawmidi.c:150 [<ffffffff85285a0b>] snd_rawmidi_kernel_write1+0x4bb/0x760 sound/core/rawmidi.c:1252 [<ffffffff85287b73>] snd_rawmidi_write+0x543/0xb30 sound/core/rawmidi.c:1302 [<ffffffff817ba5f3>] __vfs_write+0x113/0x480 fs/read_write.c:528 [<ffffffff817bc087>] vfs_write+0x167/0x4a0 fs/read_write.c:577 [< inline >] SYSC_write fs/read_write.c:624 [<ffffffff817bf371>] SyS_write+0x111/0x220 fs/read_write.c:616 [<ffffffff86660276>] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 In the former case, the reason is that virmidi has an open code calling snd_rawmidi_transmit_ack() with the value calculated outside the spinlock. We may use snd_rawmidi_transmit() in a loop just for consuming the input data, but even there, there is a race between snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack(). Similarly in the latter case, it calls snd_rawmidi_transmit_peek() and snd_rawmidi_tranmit_ack() separately without protection, so they are racy as well. The patch tries to address these issues by the following ways: - Introduce the unlocked versions of snd_rawmidi_transmit_peek() and snd_rawmidi_transmit_ack() to be called inside the explicit lock. - Rewrite snd_rawmidi_transmit() to be race-free (the former case). - Make the split calls (the latter case) protected in the rawmidi spin lock. BugLink: http://lkml.kernel.org/r/CACT4Y+YPq1+cYLkadwjWa5XjzF1_Vki1eHnVn-Lm0hzhSpu5PA@mail.gmail.com BugLink: http://lkml.kernel.org/r/CACT4Y+acG4iyphdOZx47Nyq_VHGbpJQK-6xNpiqUjaZYqsXOGw@mail.gmail.com Reported-by: Dmitry Vyukov <dvyukov@google.com> Tested-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Remove kernel WARNING for NULL user-space buffer checkTakashi Iwai2016-02-011-1/+1
| | | | | | | | | | | NULL user-space buffer can be passed even in a normal path, thus it's not good to spew a kernel warning with stack trace at each time. Just drop snd_BUG_ON() macro usage there. BugLink: http://lkml.kernel.org/r/CACT4Y+YfVJ3L+q0i-4vyQVyyPD7V=OMX0PWPi29x9Bo3QaBLdw@mail.gmail.com Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: core: Drop superfluous error/debug messages after malloc failuresTakashi Iwai2015-03-101-6/+2Star
| | | | | | | | The kernel memory allocators already report the errors when the requested allocation fails, thus we don't need to warn it again in each caller side. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: Simplify snd_device_register() variantsTakashi Iwai2015-02-021-6/+5Star
| | | | | | | | | | | | | | | Now that all callers have been replaced with snd_device_register_for_dev(), let's drop the obsolete device registration code and concentrate only on the code handling struct device directly. That said, - remove the old snd_device_register(), - rename snd_device_register_for_dev() with snd_device_register(), - drop superfluous arguments from snd_device_register(), - change snd_unregister_device() to pass the device pointer directly Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Use rawmidi device file for kernel messagesTakashi Iwai2015-02-021-3/+3
| | | | | | | | ... instead of card's device. This will be helpful to distinguish errors from multiple rawmidi devices on a single card. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Embed struct deviceTakashi Iwai2015-02-021-7/+17
| | | | | | | | | | | | Like previous patches, this changes the device management for rawmidi, embedding the struct device into struct snd_rawmidi. The required change is more or less same as hwdep device. The currently unused dev field is reused as the new embedded struct field now. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: control: Provide a helper to look for the preferred subdeviceTakashi Iwai2015-02-021-12/+2Star
| | | | | | | | | Instead of open-coding the search over the control file loop, provide a helper function for the preferred subdevice assigned to the current process. Reviewed-by: Jaroslav Kysela <perex@perex.cz> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: Move EXPORT_SYMBOL() in appropriate placesTakashi Iwai2014-02-271-18/+17Star
| | | | | | Just a cleanup to follow the standard coding style. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: Use standard printk helpersTakashi Iwai2014-02-141-15/+34
| | | | | | | Use dev_err() & co as much as possible. If not available (no device assigned at the calling point), use pr_xxx() helpers instead. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: Drop unused name argument in snd_register_oss_device()Takashi Iwai2014-02-121-2/+2
| | | | | | | The last argument, name, of snd_oss_register_device() is nowhere referred in the function in the current code. Let's drop it. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: Fix typos in alsa-driver-api.xmlMasanari Iida2014-02-101-1/+1
| | | | | | | | | This patch fixed 2 typos in DocBook/alsa-driver-api.xml. It is because this file is generated by make xmldocs, I have to fix typos within source files. Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: add/change some comments describing function return valuesYacine Belkadi2013-03-121-7/+7
| | | | | | | | | | | | | | | | | | | script/kernel-doc reports the following type of warnings (when run in verbose mode): Warning(sound/core/init.c:152): No description found for return value of 'snd_card_create' To fix that: - add missing descriptions of function return values - use "Return:" sections to describe those return values Along the way: - complete some descriptions - fix some typos Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: Avoid endless sleep after disconnectTakashi Iwai2012-10-301-0/+20
| | | | | | | | | When disconnect callback is called, each component should wake up sleepers and check card->shutdown flag for avoiding the endless sleep blocking the proper resource release. Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: Add a reference counter to card instanceTakashi Iwai2012-10-301-1/+5
| | | | | | | | | | | | | For more strict protection for wild disconnections, a refcount is introduced to the card instance, and let it up/down when an object is referred via snd_lookup_*() in the open ops. The free-after-last-close check is also changed to check this refcount instead of the empty list, too. Reported-by: Matthieu CASTET <matthieu.castet@parrot.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* sound: fix drivers needing module.h not moduleparam.hPaul Gortmaker2011-11-011-1/+1
| | | | | | | | | The implicit presence of module.h lured several users into incorrectly thinking that they only needed/used modparam.h but once we clean up the module.h presence, these will show up as build failures, so fix 'em now. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
* ALSA: Use krealloc() in possible placesTakashi Iwai2011-07-121-4/+4
| | | | Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi - Use workq for event handlingTakashi Iwai2011-06-141-26/+11Star
| | | | | | | Kill tasklet usage in rawmidi core code. Use workq for the event callback instead of tasklet (which is used only in core/seq/seq_midi.c). Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: fix oops (use after free) when unloading a driver moduleClemens Ladisch2010-10-171-1/+3
| | | | | | | | | | | | | | When a driver module is unloaded and the last still open file is a raw MIDI device, the card and its devices will be actually freed in the snd_card_file_remove() call when that file is closed. Afterwards, rmidi and rmidi->card point into freed memory, so the module pointer is likely to be garbage. (This was introduced by commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a.) Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Reported-by: Krzysztof Foltman <wdev@foltman.com> Cc: 2.6.30-2.6.35 <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi: fix the get next midi device ioctlDan Carpenter2010-09-091-0/+2
| | | | | | | | | | | | | If we pass in a device which is higher than SNDRV_RAWMIDI_DEVICES then the "next device" should be -1. This function just returns device + 1. But the main thing is that "device + 1" can lead to a (harmless) integer overflow and that annoys static analysis tools. [fix the case for device == SNDRV_RAWMIDI_DEVICE by tiwai] Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: core - Define llseek fopsTakashi Iwai2010-04-131-0/+5
| | | | | | | | | | | Set no_llseek to llseek file ops of each sound component (but for hwdep). This avoids the implicit BKL invocation via generic_file_llseek() used as default when fops.llseek is NULL. Also call nonseekable_open() at each open ops to ensure the file flags have no seek bit. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* vfs: Implement proper O_SYNC semanticsChristoph Hellwig2009-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While Linux provided an O_SYNC flag basically since day 1, it took until Linux 2.4.0-test12pre2 to actually get it implemented for filesystems, since that day we had generic_osync_around with only minor changes and the great "For now, when the user asks for O_SYNC, we'll actually give O_DSYNC" comment. This patch intends to actually give us real O_SYNC semantics in addition to the O_DSYNC semantics. After Jan's O_SYNC patches which are required before this patch it's actually surprisingly simple, we just need to figure out when to set the datasync flag to vfs_fsync_range and when not. This patch renames the existing O_SYNC flag to O_DSYNC while keeping it's numerical value to keep binary compatibility, and adds a new real O_SYNC flag. To guarantee backwards compatiblity it is defined as expanding to both the O_DSYNC and the new additional binary flag (__O_SYNC) to make sure we are backwards-compatible when compiled against the new headers. This also means that all places that don't care about the differences can just check O_DSYNC and get the right behaviour for O_SYNC, too - only places that actuall care need to check __O_SYNC in addition. Drivers and network filesystems have been updated in a fail safe way to always do the full sync magic if O_DSYNC is set. The few places setting O_SYNC for lower layers are kept that way for now to stay failsafe. We enforce that O_DSYNC is set when __O_SYNC is set early in the open path to make sure we always get these sane options. Note that parisc really screwed up their headers as they already define a O_DSYNC that has always been a no-op. We try to repair it by using it for the new O_DSYNC and redefinining O_SYNC to send both the traditional O_SYNC numerical value _and_ the O_DSYNC one. Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Grant Grundler <grundler@parisc-linux.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Ingo Molnar <mingo@elte.hu> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andreas Dilger <adilger@sun.com> Acked-by: Trond Myklebust <Trond.Myklebust@netapp.com> Acked-by: Kyle McMartin <kyle@mcmartin.ca> Acked-by: Ulrich Drepper <drepper@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Jan Kara <jack@suse.cz>
* sound: rawmidi: record a substream's owner processClemens Ladisch2009-11-101-0/+9
| | | | | | | Record the pid of the task that opened a RawMIDI substream. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* sound: rawmidi: fix opened substreams countClemens Ladisch2009-11-101-4/+2Star
| | | | | | | | | | | | | The substream_opened field is to count the number of opened substreams, not the number of times that any substreams have been opened. Furthermore, all substreams being opened does not imply that the next open would fail, due to the possibility of O_APPEND. With this wrong check, opening a substream multiple times would succeed only if the device had more unopened substreams. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* Merge branch 'topic/ctl-pid-lock' into topic/core-changeTakashi Iwai2009-11-101-1/+1
|\
| * control: use reference-counted pidClemens Ladisch2009-11-061-1/+1
| | | | | | | | | | | | | | | | | | | | Instead of storing the PID number, take a reference to the task's pid structure. This protects against duplicates due to PID overflows, and using pid_vnr() ensures that the PID returned by snd_ctl_elem_info() is correct as seen from the current namespace. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | sound: rawmidi: fix MIDI device O_APPEND error handlingClemens Ladisch2009-11-101-12/+7Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a in 2.6.30 broke the error handling code in rawmidi_open_priv(). If only the output substream of a RawMIDI device has been opened and if this device is then opened with O_RDWR | O_APPEND and if the initialization of the input substream fails (either because of low memory or because the device driver's open callback fails), then the runtime structure of the already open output substream will be freed and all following writes through the first handle will cause snd_rawmidi_write() to use the NULL runtime pointer. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | sound: rawmidi: fix checking of O_APPEND when opening MIDI deviceClemens Ladisch2009-11-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a in 2.6.30 dropped the check that a substream must already have been opened with O_APPEND to be able to open it a second time. This would make it possible for a substream to be switched to append mode, which would mean that non-atomic writes would fail unexpectedly. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | sound: rawmidi: fix double init when opening MIDI device with O_APPENDClemens Ladisch2009-11-101-10/+12
|/ | | | | | | | | | | | | | Commit 9a1b64caac82aa02cb74587ffc798e6f42c6170a in 2.6.30 moved the substream initialization code to where it would be executed every time the substream is opened. This had the consequence that any further opening would drop and leak the data in the existing buffer, and that the device driver's open callback would be called multiple times, unexpectedly. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* sound: rawmidi: disable active-sensing-on-close by defaultClemens Ladisch2009-07-151-1/+1
| | | | | | | | | | Sending an Active Sensing message when closing a port can interfere with the following data if the port is reopened and a note-on is sent before the device's timeout has elapsed. Therefore, it is better to disable this setting by default. Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi - Refactor rawmidi open/close codesTakashi Iwai2009-03-091-183/+194
| | | | | | Refactor rawmidi open/close code messes. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* ALSA: rawmidi - Fix possible race in openTakashi Iwai2009-03-091-7/+7
| | | | | | | The module refcount should be handled in the register_mutex to avoid possible races with module unloading. Signed-off-by: Takashi Iwai <tiwai@suse.de>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-11-19 22:52:28 +0100