- 17 Feb, 2016 40 commits
-
-
Takashi Iwai authored
commit 6c361d10 upstream. This reverts commit 0c25ad80. The original commit disabled the aamixer path due to the noise problem, but it turned out that some mobo with the same PCI SSID doesn't suffer from the issue, and the disabled function (analog loopback) is still demanded by users. Since the recent commit [e7fdd527: ALSA: hda - Implement loopback control switch for Realtek and other codecs], we have the dynamic mixer switch to enable/disable the aamix path, and we don't have to disable the path statically any longer. So, let's revert the disablement, so that only the user suffering from the noise problem can turn off the aamix on the fly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=108301 Reported-by: <mutedbytes@gmail.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
David Henningsson authored
commit 360a8245 upstream. The static checker warning is: sound/pci/hda/patch_hdmi.c:460 hdmi_eld_ctl_get() error: __memcpy() 'eld->eld_buffer' too small (256 vs 512) I have a hard time figuring out if this can ever cause an information leak (I don't think so), but nonetheless it does not hurt to increase the robustness of the code. Fixes: 68e03de9 ('ALSA: hda - hdmi: Do not expose eld data when eld is invalid') Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Takashi Iwai authored
commit 2154cc0e upstream. Mac Mini 7,1 model with CS4208 codec reports the headphone jack detection wrongly in an inverted way. Moreover, the advertised pins for the audio input and SPDIF output have actually no jack detection. This patch addresses these issues. The inv_jack_detect flag is set for fixing the headphone jack detection, and the pin configs for audio input and SPDIF output are marked as non-detectable. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=105161 Report-and-tested-by: moosotc@gmail.com Signed-off-by:
-
Takashi Iwai authored
commit ed8b1d6d upstream. A slave timer element also unlinks at snd_timer_stop() but it takes only slave_active_lock. When a slave is assigned to a master, however, this may become a race against the master's interrupt handling, eventually resulting in a list corruption. The actual bug could be seen with a syzkaller fuzzer test case in BugLink below. As a fix, we need to take timeri->timer->lock when timer isn't NULL, i.e. assigned to a master, while the assignment to a master itself is protected by slave_active_lock. BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.comSigned-off-by:
-
Takashi Iwai authored
commit 117159f0 upstream. In snd_timer_notify1(), the wrong timer instance was passed for slave ccallback function. This leads to the access to the wrong data when an incompatible master is handled (e.g. the master is the sequencer timer and the slave is a user timer), as spotted by syzkaller fuzzer. This patch fixes that wrong assignment. BugLink: http://lkml.kernel.org/r/CACT4Y+Y_Bm+7epAb=8Wi=AaWd+DYS7qawX52qxdCfOfY49vozQ@mail.gmail.comReported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Takashi Iwai authored
commit 4dff5c7b upstream. snd_timer_user_read() has a potential race among parallel reads, as qhead and qused are updated outside the critical section due to copy_to_user() calls. Move them into the critical section, and also sanitize the relevant code a bit. Signed-off-by:
-
Takashi Iwai authored
commit f784beb7 upstream. Although ALSA timer code got hardening for races, it still causes use-after-free error. This is however rather a corrupted linked list, not actually the concurrent accesses. Namely, when timer start is triggered twice, list_add_tail() is called twice, too. This ends up with the link corruption and triggers KASAN error. The simplest fix would be replacing list_add_tail() with list_move_tail(), but fundamentally it's the problem that we don't check the double start/stop correctly. So, the right fix here is to add the proper checks to snd_timer_start() and snd_timer_stop() (and their variants). BugLink: http://lkml.kernel.org/r/CACT4Y+ZyPRoMQjmawbvmCEDrkBD2BQuH7R09=eOkf5ESK8kJAw@mail.gmail.comReported-by:
-
Takashi Iwai authored
commit 094fd3be upstream. In ALSA timer core, the active timer instance is managed in active_list linked list. Each element is added / removed dynamically at timer start, stop and in timer interrupt. The problem is that snd_timer_interrupt() has a thinko and leaves the element in active_list when it's the last opened element. This eventually leads to list corruption or use-after-free error. This hasn't been revealed because we used to delete the list forcibly in snd_timer_stop() in the past. However, the recent fix avoids the double-stop behavior (in commit [f784beb7: ALSA: timer: Fix link corruption due to double start or stop]), and this leak hits reality. This patch fixes the link management in snd_timer_interrupt(). Now it simply unlinks no matter which stream is. BugLink: http://lkml.kernel.org/r/CACT4Y+Yy2aukHP-EDp8-ziNqNNmb-NTf=jDWXMP7jB8HDa2vng@mail.gmail.comReported-by:
-
Takashi Iwai authored
commit c3b16813 upstream. This is a minor code cleanup without any functional changes: - Kill keep_flag argument from _snd_timer_stop(), as all callers pass only it false. - Remove redundant NULL check in _snd_timer_stop(). Signed-off-by:
-
Takashi Iwai authored
commit 7f0973e9 upstream. The port subscription code uses double mutex locks for source and destination ports, and this may become racy once when wrongly set up. It leads to lockdep warning splat, typically triggered by fuzzer like syzkaller, although the actual deadlock hasn't been seen, so far. This patch simplifies the handling by reducing to two single locks, so that no lockdep warning will be trigger any longer. By splitting to two actions, a still-in-progress element shall be added in one list while handling another. For ignoring this element, a new check is added in deliver_to_subscribers(). Along with it, the code to add/remove the subscribers list element was cleaned up and refactored. BugLink: http://lkml.kernel.org/r/CACT4Y+aKQXV7xkBW9hpQbzaDO7LrUvohxWh-UwMxXjDy-yBD=A@mail.gmail.comReported-by:
-
Takashi Iwai authored
commit 2d1b5c08 upstream. The virmidi driver has an open race at closing its assigned rawmidi device, and this may lead to use-after-free in snd_seq_deliver_single_event(). Plug the hole by properly protecting the linked list deletion and calling in the right order in snd_virmidi_input_close(). BugLink: http://lkml.kernel.org/r/CACT4Y+Zd66+w12fNN85-425cVQT=K23kWbhnCEcMB8s3us-Frw@mail.gmail.comReported-by:
-
Takashi Iwai authored
commit 2cdc7b63 upstream. ALSA sequencer may open/close and control ALSA timer instance dynamically either via sequencer events or direct ioctls. These are done mostly asynchronously, and it may call still some timer action like snd_timer_start() while another is calling snd_timer_close(). Since the instance gets removed by snd_timer_close(), it may lead to a use-after-free. This patch tries to address such a race by protecting each snd_timer_*() call via the existing spinlock and also by avoiding the access to timer during close call. BugLink: http://lkml.kernel.org/r/CACT4Y+Z6RzW5MBr-HUdV-8zwg71WQfKTdPpYGvOeS7v4cyurNQ@mail.gmail.comReported-by:
-
Vinod Koul authored
commit 5e82d2be upstream. While performing hw_free, DPCM checks the BE state but leaves out the suspend state. The suspend state needs to be checked as well, as we might be suspended and then usermode closes rather than resuming the audio stream. This was found by a stress testing of system with playback in loop and killed after few seconds running in background and second script running suspend-resume test in loop Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Acked-by:
Liam Girdwood <liam.r.girdwood@linux.intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Takashi Iwai authored
commit b2483716 upstream. There are potential deadlocks in PCM OSS emulation code while accessing read/write and mmap concurrently. This comes from the infamous mmap_sem usage in copy_from/to_user(). Namely, snd_pcm_oss_write() -> &runtime->oss.params_lock -> copy_to_user() -> &mm->mmap_sem mmap() -> &mm->mmap_sem -> snd_pcm_oss_mmap() -> &runtime->oss.params_lock Since we can't avoid taking params_lock from mmap code path, use trylock variant and aborts with -EAGAIN as a workaround of this AB/BA deadlock. BugLink: http://lkml.kernel.org/r/CACT4Y+bVrBKDG0G2_AcUgUQa+X91VKTeS4v+wN7BSHwHtqn3kQ@mail.gmail.comReported-by:
-
Kailang Yang authored
commit cfc5a845 upstream. Dell create new platform with ALC298 codec. This patch will enable headset mode for ALC225/ALC3253 platform. Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
-
Kailang Yang authored
commit 4cc9b9d6 upstream. Support headset mode for ALC225 platforms. Signed-off-by:
-
Kailang Yang authored
commit 4231430d upstream. Add new support for ALC225, yet another variant of ALC298 codec. Signed-off-by:
-
Takashi Iwai authored
commit 81f57754 upstream. 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.comReported-by:
-
Takashi Iwai authored
commit cc85f7a6 upstream. 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.comReported-by:
-
Takashi Iwai authored
commit 06ab3003 upstream. 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.comReported-by:
-
Takashi Iwai authored
commit da10816e upstream. ALSA OSS sequencer spews a kernel error message ("ALSA: seq_oss: too many applications") when user-space tries to open more than the limit. This means that it can easily fill the log buffer. Since it's merely a normal error, it's safe to suppress it via pr_debug() instead. Signed-off-by:
-
Takashi Iwai authored
commit 59915133 upstream. ALSA sequencer OSS emulation code has a sanity check for currently opened devices, but there is a thinko there, eventually it spews warnings and skips the operation wrongly like: WARNING: CPU: 1 PID: 7573 at sound/core/seq/oss/seq_oss_synth.c:311 Fix this off-by-one error. Reported-by:
-
Takashi Iwai authored
commit 7ee96216 upstream. ALSA dummy driver can switch the timer backend between system timer and hrtimer via its hrtimer module option. This can be also switched dynamically via sysfs, but it may lead to a memory corruption when switching is done while a PCM stream is running; the stream instance for the newly switched timer method tries to access the memory that was allocated by another timer method although the sizes differ. As the simplest fix, this patch just disables the switch via sysfs by dropping the writable bit. BugLink: http://lkml.kernel.org/r/CACT4Y+ZGEeEBntHW5WHn2GoeE0G_kRrCmUh6=dWyy-wfzvuJLg@mail.gmail.comReported-by:
-
Takashi Iwai authored
commit 462b3f16 upstream. Some architectures like PowerPC can handle the maximum struct size in an ioctl only up to 13 bits, and struct snd_compr_codec_caps used by SNDRV_COMPRESS_GET_CODEC_CAPS ioctl overflows this limit. This problem was revealed recently by a powerpc change, as it's now treated as a fatal build error. This patch is a stop-gap for that: for architectures with less than 14 bit ioctl struct size, get rid of the handling of the relevant ioctl. We should provide an alternative equivalent ioctl code later, but for now just paper over it. Luckily, the compress API hasn't been used on such architectures, so the impact must be effectively zero. Reviewed-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
-
Libin Yang authored
commit 6639484d upstream. On Broxton, to make sure the reset controller works properly, MISCBDCGE bit (bit 6) in CGCTL (0x48) of PCI configuration space need be cleared before reset and set back to 1 after reset. Otherwise, it may prevent the CORB/RIRB logic from being reset. Signed-off-by:
Libin Yang <libin.yang@linux.intel.com> Signed-off-by:
-
Takashi Iwai authored
commit 61595dca upstream. Since the build of PCM timer may be disabled via Kconfig now, each driver that provides a timer interface needs to set CONFIG_SND_TIMER explicitly. Otherwise it may get a build error due to missing symbol. Fixes: 90bbaf66 ('ALSA: timer: add config item to export PCM timer disabling for expert') Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Lucas Tanure authored
commit 07905298 upstream. The return type "unsigned int" was used by the get_formation_index function despite of the aspect that it will eventually return a negative error code. So, change to signed int and get index by reference in the parameters. Done with the help of Coccinelle. [Fix the missing braces suggested by Julia Lawall -- tiwai] Signed-off-by:
Lucas Tanure <tanure@linux.com> Reviewed-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Tested-by:
-
Andrey Konovalov authored
commit 07d86ca9 upstream. The 'umidi' object will be free'd on the error path by snd_usbmidi_free() when tearing down the rawmidi interface. So we shouldn't try to free it in snd_usbmidi_create() after having registered the rawmidi interface. Found by KASAN. Signed-off-by:
Andrey Konovalov <andreyknvl@gmail.com> Acked-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Jurgen Kramer authored
commit ad678b4c upstream. This patch adds native DSD support for the PS Audio NuWave DAC. Signed-off-by:
Jurgen Kramer <gtmkramer@xs4all.nl> Signed-off-by:
-
Jurgen Kramer authored
commit 5327d6ba upstream. In my patch adding native DSD support for the Oppo HA-1, the wrong vendor ID got through. This patch fixes the vendor ID and aligns the comment. Fixes: a4eae3a5 ('ALSA: usb: Add native DSD support for Oppo HA-1') Signed-off-by:
-
Lev Lybin authored
commit 1b3c993a upstream. Microsoft LifeCam HD-6000 (045e:076f) requires the similar quirk for avoiding the stall due to the invalid sample rate reads. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111491Signed-off-by:
Lev Lybin <lev.lybin@gmail.com> Signed-off-by:
-
Guillaume Fougnies authored
commit 5a4ff9ec upstream. TEAC UD-501/UD-503/NT-503 fail to switch properly between different rate/format. Similar to 'Playback Design', this patch corrects the invalid clock source error for TEAC products and avoids complete freeze of the usb interface of 503 series. Signed-off-by:
Guillaume Fougnies <guillaume@eulerian.com> Signed-off-by:
-
Thomas Gleixner authored
commit 203cbf77 upstream. If CONFIG_TIME_LOW_RES is enabled we add a jiffie to the relative timeout to prevent short sleeps, but we do not account for that in interfaces which retrieve the remaining time. Helge observed that timerfd can return a remaining time larger than the relative timeout. That's not expected and breaks userland test programs. Store the information that the timer was armed relative and provide functions to adjust the remaining time. To avoid bloating the hrtimer struct make state a u8, which as a bonus results in better code on x86 at least. Reported-and-tested-by:
Helge Deller <deller@gmx.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: John Stultz <john.stultz@linaro.org> Cc: linux-m68k@lists.linux-m68k.org Cc: dhowells@redhat.com Link: http://lkml.kernel.org/r/20160114164159.273328486@linutronix.deSigned-off-by:
-
Dan Williams authored
commit 1501efad upstream. It is not safe for an integrity profile to be changed while i/o is in-flight in the queue. Prevent adding new disks or otherwise online spares to an array if the device has an incompatible integrity profile. The original change to the blk_integrity_unregister implementation in md, commmit c7bfced9 "md: suspend i/o during runtime blk_integrity_unregister" introduced an immediate hang regression. This policy of disallowing changes the integrity profile once one has been established is shared with DM. Here is an abbreviated log from a test run that: 1/ Creates a degraded raid1 with an integrity-enabled device (pmem0s) [ 59.076127] 2/ Tries to add an integrity-disabled device (pmem1m) [ 90.489209] 3/ Retries with an integrity-enabled device (pmem1s) [ 205.671277] [ 59.076127] md/raid1:md0: active with 1 out of 2 mirrors [ 59.078302] md: data integrity enabled on md0 [..] [ 90.489209] md0: incompatible integrity profile for pmem1m [..] [ 205.671277] md: super_written gets error=-5 [ 205.677386] md/raid1:md0: Disk failure on pmem1m, disabling device. [ 205.677386] md/raid1:md0: Operation continuing on 1 devices. [ 205.683037] RAID1 conf printout: [ 205.684699] --- wd:1 rd:2 [ 205.685972] disk 0, wo:0, o:1, dev:pmem0s [ 205.687562] disk 1, wo:1, o:1, dev:pmem1s [ 205.691717] md: recovery of RAID array md0 Fixes: c7bfced9 ("md: suspend i/o during runtime blk_integrity_unregister") Cc: Mike Snitzer <snitzer@redhat.com> Reported-by:
NeilBrown <neilb@suse.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Javier Martinez Canillas authored
commit 329d88da upstream. This is a partial revert of commit ed8d1cf0 ("[media] Export I2C module alias information in missing drivers") that exported the module aliases for the I2C drivers that were missing to make autoload to work. But there is a bug report [0] that auto load of the ir-kbd-i2c driver cause the Hauppauge HD-PVR driver to not behave correctly. This is a hdpvr latent bug that was just exposed by ir-kbd-i2c module autoloading working and will also happen if the I2C driver is built-in or a user calls modprobe to load the module and register the driver. But there is a regression experimented by users so until the real bug is fixed, let's not export the module alias for the ir-kbd-i2c driver even when this just masks the actual issue. [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810726 Fixes: ed8d1cf0 ("[media] Export I2C module alias information in missing drivers") Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
-
Helge Deller authored
commit e60fc5aa upstream. On a 64bit kernel build the compiler aligns the _sifields union in the struct siginfo_t on a 64bit address. The __ARCH_SI_PREAMBLE_SIZE define compensates for this alignment and thus fixes the wait testcase of the strace package. The symptoms of a wrong __ARCH_SI_PREAMBLE_SIZE value is that _sigchld.si_stime variable is missed to be copied and thus after a copy_siginfo() will have uninitialized values. Signed-off-by:
-
Helge Deller authored
commit b0e55131 upstream. PA-RISC doesn't have atomic instructions to modify page table entries, so it takes spinlock in the TLB handler and modifies the page table entry non-atomically. If you modify the page table entry without the spinlock, you may race with TLB handler on another CPU and your modification may be lost. Protect against that with usage of purge_tlb_start() and purge_tlb_end() which handles the TLB spinlock. Signed-off-by:
-
Tejun Heo authored
commit 8d91f8b1 upstream. @console_may_schedule tracks whether console_sem was acquired through lock or trylock. If the former, we're inside a sleepable context and console_conditional_schedule() performs cond_resched(). This allows console drivers which use console_lock for synchronization to yield while performing time-consuming operations such as scrolling. However, the actual console outputting is performed while holding irq-safe logbuf_lock, so console_unlock() clears @console_may_schedule before starting outputting lines. Also, only a few drivers call console_conditional_schedule() to begin with. This means that when a lot of lines need to be output by console_unlock(), for example on a console registration, the task doing console_unlock() may not yield for a long time on a non-preemptible kernel. If this happens with a slow console devices, for example a serial console, the outputting task may occupy the cpu for a very long time. Long enough to trigger softlockup and/or RCU stall warnings, which in turn pile more messages, sometimes enough to trigger the next cycle of warnings incapacitating the system. Fix it by making console_unlock() insert cond_resched() between lines if @console_may_schedule. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Calvin Owens <calvinowens@fb.com> Acked-by:
Jan Kara <jack@suse.com> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Kyle McMartin <kyle@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Steven Rostedt authored
commit 6ccd8371 upstream. When a max stack trace is discovered, the stack dump is saved. In order to not record the overhead of the stack tracer, the ip of the traced function is looked for within the dump. The trace is started from the location of that function. But if for some reason the ip is not found, the entire stack trace is then truncated. That's not very useful. Instead, print everything if the ip of the traced function is not found within the trace. This issue showed up on s390. Link: http://lkml.kernel.org/r/20160129102241.1b3c9c04@gandalf.local.home Fixes: 72ac426a ("tracing: Clean up stack tracing and fix fentry updates") Reported-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Tested-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 7717c6be upstream. While cleaning the stacktrace code I unintentially changed the skip depth of trace_buffer_unlock_commit_regs() from 0 to 6. kprobes uses this function, and with skipping 6 call backs, it can easily produce no stack. Here's how I tested it: # echo 'p:ext4_sync_fs ext4_sync_fs ' > /sys/kernel/debug/tracing/kprobe_events # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable # cat /sys/kernel/debug/trace sync-2394 [005] 502.457060: ext4_sync_fs: (ffffffff81317650) sync-2394 [005] 502.457063: kernel_stack: <stack trace> sync-2394 [005] 502.457086: ext4_sync_fs: (ffffffff81317650) sync-2394 [005] 502.457087: kernel_stack: <stack trace> sync-2394 [005] 502.457091: ext4_sync_fs: (ffffffff81317650) After putting back the skip stack to zero, we have: sync-2270 [000] 748.052693: ext4_sync_fs: (ffffffff81317650) sync-2270 [000] 748.052695: kernel_stack: <stack trace> => iterate_supers (ffffffff8126412e) => sys_sync (ffffffff8129c4b6) => entry_SYSCALL_64_fastpath (ffffffff8181f0b2) sync-2270 [000] 748.053017: ext4_sync_fs: (ffffffff81317650) sync-2270 [000] 748.053019: kernel_stack: <stack trace> => iterate_supers (ffffffff8126412e) => sys_sync (ffffffff8129c4b6) => entry_SYSCALL_64_fastpath (ffffffff8181f0b2) sync-2270 [000] 748.053381: ext4_sync_fs: (ffffffff81317650) sync-2270 [000] 748.053383: kernel_stack: <stack trace> => iterate_supers (ffffffff8126412e) => sys_sync (ffffffff8129c4b6) => entry_SYSCALL_64_fastpath (ffffffff8181f0b2) Fixes: 73dddbb5 "tracing: Only create stacktrace option when STACKTRACE is configured" Reported-by:
Brendan Gregg <brendan.d.gregg@gmail.com> Tested-by:
-
