- 17 Feb, 2016 39 commits
-
-
Kailang Yang authored
commit 4231430d upstream. Add new support for ALC225, yet another variant of ALC298 codec. Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
Dmitry Vyukov <dvyukov@google.com> Tested-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:
Mark Brown <broonie@kernel.org> Acked-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:
-
Christoph Biedl authored
commit 3460baa6 upstream. Commit 36e097a8 ("PCI: Split out bridge window override of minimum allocation address") claimed to do no functional changes but unfortunately did: The "min" variable is altered. At least the AVM A1 PCMCIA adapter was no longer detected, breaking ISDN operation. Use a local copy of "min" to restore the previous behaviour. [bhelgaas: avoid gcc "?:" extension for portability and readability] Fixes: 36e097a8 ("PCI: Split out bridge window override of minimum allocation address") Signed-off-by:
Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Grygorii Strashko authored
commit 8ff0ef99 upstream. On -RT and if kernel is booting with "threadirqs" cmd line parameter, PCIe/PCI (MSI) IRQ cascade handlers (like dra7xx_pcie_msi_irq_handler()) will be forced threaded and, as result, will generate warnings like this: WARNING: CPU: 1 PID: 82 at kernel/irq/handle.c:150 handle_irq_event_percpu+0x14c/0x174() irq 460 handler irq_default_primary_handler+0x0/0x14 enabled interrupts Backtrace: (warn_slowpath_common) from (warn_slowpath_fmt+0x38/0x40) (warn_slowpath_fmt) from (handle_irq_event_percpu+0x14c/0x174) (handle_irq_event_percpu) from (handle_irq_event+0x84/0xb8) (handle_irq_event) from (handle_simple_irq+0x90/0x118) (handle_simple_irq) from (generic_handle_irq+0x30/0x44) (generic_handle_irq) from (dra7xx_pcie_msi_irq_handler+0x7c/0x8c) (dra7xx_pcie_msi_irq_handler) from (irq_forced_thread_fn+0x28/0x5c) (irq_forced_thread_fn) from (irq_thread+0x128/0x204) This happens because all of them invoke generic_handle_irq() from the requested handler. generic_handle_irq() grabs raw_locks and thus needs to run in raw-IRQ context. This issue was originally reproduced on TI dra7-evem, but, as was identified during discussion [1], other hosts can also suffer from this issue. Fix all them at once by marking PCIe/PCI (MSI) IRQ cascade handlers IRQF_NO_THREAD explicitly. [1] http://lkml.kernel.org/r/1448027966-21610-1-git-send-email-grygorii.strashko@ti.com [bhelgaas: add stable tag, fix typos] Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> CC: Kishon Vijay Abraham I <kishon@ti.com> CC: Jingoo Han <jingoohan1@gmail.com> CC: Kukjin Kim <kgene@kernel.org> CC: Krzysztof Kozlowski <k.kozlowski@samsung.com> CC: Richard Zhu <Richard.Zhu@freescale.com> CC: Thierry Reding <thierry.reding@gmail.com> CC: Stephen Warren <swarren@wwwdotorg.org> CC: Alexandre Courbot <gnurou@gmail.com> CC: Simon Horman <horms@verge.net.au> CC: Pratyush Anand <pratyush.anand@gmail.com> CC: Michal Simek <michal.simek@xilinx.com> CC: "Sören Brinkmann" <soren.brinkmann@xilinx.com> CC: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Brian Norris authored
commit f7a8e38f upstream. Commits such as commit 853f1c58 ("mtd: nand: omap2: show parent device structure in sysfs") attempt to rely on the core MTD code to set the MTD name based on the parent device. However, nand_base tries to set a different default name according to the flash name (e.g., extracted from the ONFI parameter page), which means NAND drivers will never make use of the MTD defaults. This is not the intention of commit 853f1c58. This results in problems when trying to use the cmdline partition parser, since the MTD name is different than expected. Let's fix this by providing a default NAND name, where possible. Note that this is not really a great default name in the long run, since this means that if there are multiple MTDs attached to the same controller device, they will have the same name. But that is an existing issue and requires future work on a better controller vs. flash chip abstraction to fix properly. Fixes: 853f1c58 ("mtd: nand: omap2: show parent device structure in sysfs") Reported-by:
Heiko Schocher <hs@denx.de> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Reviewed-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Tested-by:
-
Uri Mashiach authored
commit e47301b0 upstream. Fix the below Oops when trying to modprobe wlcore_spi. The oops occurs because the wl1271_power_{off,on}() function doesn't check the power() function pointer. [ 23.401447] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 23.409954] pgd = c0004000 [ 23.412922] [00000000] *pgd=00000000 [ 23.416693] Internal error: Oops: 80000007 [#1] SMP ARM [ 23.422168] Modules linked in: wl12xx wlcore mac80211 cfg80211 musb_dsps musb_hdrc usbcore usb_common snd_soc_simple_card evdev joydev omap_rng wlcore_spi snd_soc_tlv320aic23_i2c rng_core snd_soc_tlv320aic23 c_can_platform c_can can_dev snd_soc_davinci_mcasp snd_soc_edma snd_soc_omap omap_wdt musb_am335x cpufreq_dt thermal_sys hwmon [ 23.453253] CPU: 0 PID: 36 Comm: kworker/0:2 Not tainted 4.2.0-00002-g951efee-dirty #233 [ 23.461720] Hardware name: Generic AM33XX (Flattened Device Tree) [ 23.468123] Workqueue: events request_firmware_work_func [ 23.473690] task: de32efc0 ti: de4ee000 task.ti: de4ee000 [ 23.479341] PC is at 0x0 [ 23.482112] LR is at wl12xx_set_power_on+0x28/0x124 [wlcore] [ 23.488074] pc : [<00000000>] lr : [<bf2581f0>] psr: 60000013 [ 23.488074] sp : de4efe50 ip : 00000002 fp : 00000000 [ 23.500162] r10: de7cdd00 r9 : dc848800 r8 : bf27af00 [ 23.505663] r7 : bf27a1a8 r6 : dcbd8a80 r5 : dce0e2e0 r4 : dce0d2e0 [ 23.512536] r3 : 00000000 r2 : 00000000 r1 : 00000001 r0 : dc848810 [ 23.519412] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 23.527109] Control: 10c5387d Table: 9cb78019 DAC: 00000015 [ 23.533160] Process kworker/0:2 (pid: 36, stack limit = 0xde4ee218) [ 23.539760] Stack: (0xde4efe50 to 0xde4f0000) [...] [ 23.665030] [<bf2581f0>] (wl12xx_set_power_on [wlcore]) from [<bf25f7ac>] (wlcore_nvs_cb+0x118/0xa4c [wlcore]) [ 23.675604] [<bf25f7ac>] (wlcore_nvs_cb [wlcore]) from [<c04387ec>] (request_firmware_work_func+0x30/0x58) [ 23.685784] [<c04387ec>] (request_firmware_work_func) from [<c0058e2c>] (process_one_work+0x1b4/0x4b4) [ 23.695591] [<c0058e2c>] (process_one_work) from [<c0059168>] (worker_thread+0x3c/0x4a4) [ 23.704124] [<c0059168>] (worker_thread) from [<c005ee68>] (kthread+0xd4/0xf0) [ 23.711747] [<c005ee68>] (kthread) from [<c000f598>] (ret_from_fork+0x14/0x3c) [ 23.719357] Code: bad PC value [ 23.722760] ---[ end trace 981be8510db9b3a9 ]--- Prevent oops by validationg power() pointer value before calling the function. Signed-off-by:
Uri Mashiach <uri.mashiach@compulab.co.il> Acked-by:
Igor Grinberg <grinberg@compulab.co.il> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Uri Mashiach authored
commit 9b2761cb upstream. The maximum chunks used by the function is (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE + 1). The original commands array had space for (SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) commands. When the last chunk is used (len > 4 * WSPI_MAX_CHUNK_SIZE), the last command is stored outside the bounds of the commands array. Oops 5 (page fault) is generated during current wl1271 firmware load attempt: root@debian-armhf:~# ifconfig wlan0 up [ 294.312399] Unable to handle kernel paging request at virtual address 00203fc4 [ 294.320173] pgd = de528000 [ 294.323028] [00203fc4] *pgd=00000000 [ 294.326916] Internal error: Oops: 5 [#1] SMP ARM [ 294.331789] Modules linked in: bnep rfcomm bluetooth ipv6 arc4 wl12xx wlcore mac80211 musb_dsps cfg80211 musb_hdrc usbcore usb_common wlcore_spi omap_rng rng_core musb_am335x omap_wdt cpufreq_dt thermal_sys hwmon [ 294.351838] CPU: 0 PID: 1827 Comm: ifconfig Not tainted 4.2.0-00002-g3e9ad27-dirty #78 [ 294.360154] Hardware name: Generic AM33XX (Flattened Device Tree) [ 294.366557] task: dc9d6d40 ti: de550000 task.ti: de550000 [ 294.372236] PC is at __spi_validate+0xa8/0x2ac [ 294.376902] LR is at __spi_sync+0x78/0x210 [ 294.381200] pc : [<c049c760>] lr : [<c049ebe0>] psr: 60000013 [ 294.381200] sp : de551998 ip : de5519d8 fp : 00200000 [ 294.393242] r10: de551c8c r9 : de5519d8 r8 : de3a9000 [ 294.398730] r7 : de3a9258 r6 : de3a9400 r5 : de551a48 r4 : 00203fbc [ 294.405577] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : de3a9000 [ 294.412420] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 294.419918] Control: 10c5387d Table: 9e528019 DAC: 00000015 [ 294.425954] Process ifconfig (pid: 1827, stack limit = 0xde550218) [ 294.432437] Stack: (0xde551998 to 0xde552000) ... [ 294.883613] [<c049c760>] (__spi_validate) from [<c049ebe0>] (__spi_sync+0x78/0x210) [ 294.891670] [<c049ebe0>] (__spi_sync) from [<bf036598>] (wl12xx_spi_raw_write+0xfc/0x148 [wlcore_spi]) [ 294.901661] [<bf036598>] (wl12xx_spi_raw_write [wlcore_spi]) from [<bf21c694>] (wlcore_boot_upload_firmware+0x1ec/0x458 [wlcore]) [ 294.914038] [<bf21c694>] (wlcore_boot_upload_firmware [wlcore]) from [<bf24532c>] (wl12xx_boot+0xc10/0xfac [wl12xx]) [ 294.925161] [<bf24532c>] (wl12xx_boot [wl12xx]) from [<bf20d5cc>] (wl1271_op_add_interface+0x5b0/0x910 [wlcore]) [ 294.936364] [<bf20d5cc>] (wl1271_op_add_interface [wlcore]) from [<bf15c4ac>] (ieee80211_do_open+0x44c/0xf7c [mac80211]) [ 294.947963] [<bf15c4ac>] (ieee80211_do_open [mac80211]) from [<c0537978>] (__dev_open+0xa8/0x110) [ 294.957307] [<c0537978>] (__dev_open) from [<c0537bf8>] (__dev_change_flags+0x88/0x148) [ 294.965713] [<c0537bf8>] (__dev_change_flags) from [<c0537cd0>] (dev_change_flags+0x18/0x48) [ 294.974576] [<c0537cd0>] (dev_change_flags) from [<c05a55a0>] (devinet_ioctl+0x6b4/0x7d0) [ 294.983191] [<c05a55a0>] (devinet_ioctl) from [<c0517040>] (sock_ioctl+0x1e4/0x2bc) [ 294.991244] [<c0517040>] (sock_ioctl) from [<c017d378>] (do_vfs_ioctl+0x420/0x6b0) [ 294.999208] [<c017d378>] (do_vfs_ioctl) from [<c017d674>] (SyS_ioctl+0x6c/0x7c) [ 295.006880] [<c017d674>] (SyS_ioctl) from [<c000f4c0>] (ret_fast_syscall+0x0/0x54) [ 295.014835] Code: e1550004 e2444034 0a00007d e5953018 (e5942008) [ 295.021544] ---[ end trace 66ed188198f4e24e ]--- Signed-off-by:
-
xuejiufei authored
commit c95a5180 upstream. When recovery master down, dlm_do_local_recovery_cleanup() only remove the $RECOVERY lock owned by dead node, but do not clear the refmap bit. Which will make umount thread falling in dead loop migrating $RECOVERY to the dead node. Signed-off-by:
xuejiufei <xuejiufei@huawei.com> Reviewed-by:
Joseph Qi <joseph.qi@huawei.com> Cc: Mark Fasheh <mfasheh@suse.de> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Signed-off-by:
-
xuejiufei authored
commit bef5502d upstream. We have found that migration source will trigger a BUG that the refcount of mle is already zero before put when the target is down during migration. The situation is as follows: dlm_migrate_lockres dlm_add_migration_mle dlm_mark_lockres_migrating dlm_get_mle_inuse <<<<<< Now the refcount of the mle is 2. dlm_send_one_lockres and wait for the target to become the new master. <<<<<< o2hb detect the target down and clean the migration mle. Now the refcount is 1. dlm_migrate_lockres woken, and put the mle twice when found the target goes down which trigger the BUG with the following message: "ERROR: bad mle: ". Signed-off-by:
-
Takashi Iwai authored
commit e7fdd527 upstream. Many codecs, typically found on Realtek codecs, have the analog loopback path merged to the secondary input of the middle of the output paths. Currently, we don't offer the dynamic switching in such configuration but let each loopback path mute by itself. This should work well in theory, but in reality, we often see that such a dead loopback path causes some background noises even if all the elements get muted. Such a problem has been fixed by adding the quirk accordingly to disable aamix, and it's the right fix, per se. The only problem is that it's not so trivial to achieve it; user needs to pass a hint string via patch module option or sysfs. This patch gives a bit improvement on the situation: it adds "Loopback Mixing" control element for such codecs like other codecs (e.g. IDT or VIA codecs) with the individual loopback paths. User can turn on/off the loopback path simply via a mixer app. For keeping the compatibility, the loopback is still enabled on these codecs. But user can try to turn it off if experiencing a suspicious background or click noise on the fly, then build a static fixup later once after the problem is addressed. Other than the addition of the loopback enable/disablement control, there should be no changes. Signed-off-by:
-
Ming Lei authored
commit d0e5fbb0 upstream. After commit e36f6204(block: split bios to maxpossible length), bio can be splitted in the middle of a vector entry, then it is easy to split out one bio which size isn't aligned with block size, especially when the block size is bigger than 512. This patch fixes the issue by making the max io size aligned to logical block size. Fixes: e36f6204(block: split bios to maxpossible length) Reported-by:
Stefan Haberland <sth@linux.vnet.ibm.com> Cc: Keith Busch <keith.busch@intel.com> Suggested-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Martin Wilck authored
commit 25cad69f upstream. Since b8b2c7d8, platform_drv_probe() is called for all platform devices. If drv->probe is NULL, and dev_pm_domain_attach() fails, platform_drv_probe() will return the error code from dev_pm_domain_attach(). This causes real_probe() to enter the "probe_failed" path and set dev->driver to NULL. Before b8b2c7d8, real_probe() would assume success if both dev->bus->probe and drv->probe were missing. As a result, a device and driver could be "bound" together just by matching their names; this doesn't work any more after b8b2c7d8. This may cause problems later for certain usage of platform_driver_register() and platform_device_register_simple(). I observed a panic while loading the tpm_tis driver with parameter "force=1" (i.e. registering tpm_tis as a platform driver), because tpm_tis_init's assumption that the device returned by platform_device_register_simple() was bound didn't hold any more (tpmm_chip_alloc() dereferences chip->pdev->driver, causing panic). This patch restores the previous (4.3.0 and earlier) behavior of platform_drv_probe() in the case when the associated platform driver has no "probe" function. Fixes: b8b2c7d8 ("base/platform: assert that dev_pm_domain callbacks are called unconditionally") Signed-off-by:
Martin Wilck <Martin.Wilck@ts.fujitsu.com> Cc: Martin Fuzzey <mfuzzey@parkeon.com> Acked-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
-
Ioan-Adrian Ratiu authored
commit e470127e upstream. The critical section protected by usbhid->lock in hid_ctrl() is too big and because of this it causes a recursive deadlock. "Too big" means the case statement and the call to hid_input_report() do not need to be protected by the spinlock (no URB operations are done inside them). The deadlock happens because in certain rare cases drivers try to grab the lock while handling the ctrl irq which grabs the lock before them as described above. For example newer wacom tablets like 056a:033c try to reschedule proximity reads from wacom_intuos_schedule_prox_event() calling hid_hw_request() -> usbhid_request() -> usbhid_submit_report() which tries to grab the usbhid lock already held by hid_ctrl(). There are two ways to get out of this deadlock: 1. Make the drivers work "around" the ctrl critical region, in the wacom case for ex. by delaying the scheduling of the proximity read request itself to a workqueue. 2. Shrink the critical region so the usbhid lock protects only the instructions which modify usbhid state, calling hid_input_report() with the spinlock unlocked, allowing the device driver to grab the lock first, finish and then grab the lock afterwards in hid_ctrl(). This patch implements the 2nd solution. Signed-off-by:
Ioan-Adrian Ratiu <adi@adirat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by:
-
Tariq Saeed authored
commit b1b1e15e upstream. NFS on a 2 node ocfs2 cluster each node exporting dir. The lock causing the hang is the global bit map inode lock. Node 1 is master, has the lock granted in PR mode; Node 2 is in the converting list (PR -> EX). There are no holders of the lock on the master node so it should downconvert to NL and grant EX to node 2 but that does not happen. BLOCKED + QUEUED in lock res are set and it is on osb blocked list. Threads are waiting in __ocfs2_cluster_lock on BLOCKED. One thread wants EX, rest want PR. So it is as though the downconvert thread needs to be kicked to complete the conv. The hang is caused by an EX req coming into __ocfs2_cluster_lock on the heels of a PR req after it sets BUSY (drops l_lock, releasing EX thread), forcing the incoming EX to wait on BUSY without doing anything. PR has called ocfs2_dlm_lock, which sets the node 1 lock from NL -> PR, queues ast. At this time, upconvert (PR ->EX) arrives from node 2, finds conflict with node 1 lock in PR, so the lock res is put on dlm thread's dirty listt. After ret from ocf2_dlm_lock, PR thread now waits behind EX on BUSY till awoken by ast. Now it is dlm_thread that serially runs dlm_shuffle_lists, ast, bast, in that order. dlm_shuffle_lists ques a bast on behalf of node 2 (which will be run by dlm_thread right after the ast). ast does its part, sets UPCONVERT_FINISHING, clears BUSY and wakes its waiters. Next, dlm_thread runs bast. It sets BLOCKED and kicks dc thread. dc thread runs ocfs2_unblock_lock, but since UPCONVERT_FINISHING set, skips doing anything and reques. Inside of __ocfs2_cluster_lock, since EX has been waiting on BUSY ahead of PR, it wakes up first, finds BLOCKED set and skips doing anything but clearing UPCONVERT_FINISHING (which was actually "meant" for the PR thread), and this time waits on BLOCKED. Next, the PR thread comes out of wait but since UPCONVERT_FINISHING is not set, it skips updating the l_ro_holders and goes straight to wait on BLOCKED. So there, we have a hang! Threads in __ocfs2_cluster_lock wait on BLOCKED, lock res in osb blocked list. Only when dc thread is awoken, it will run ocfs2_unblock_lock and things will unhang. One way to fix this is to wake the dc thread on the flag after clearing UPCONVERT_FINISHING Orabug: 20933419 Signed-off-by:
Tariq Saeed <tariq.x.saeed@oracle.com> Signed-off-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Reviewed-by:
Wengang Wang <wen.gang.wang@oracle.com> Reviewed-by:
Mark Fasheh <mfasheh@suse.de> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Reviewed-by:
-
Keith Busch authored
commit e36f6204 upstream. This splits bio in the middle of a vector to form the largest possible bio at the h/w's desired alignment, and guarantees the bio being split will have some data. The criteria for splitting is changed from the max sectors to the h/w's optimal sector alignment if it is provided. For h/w that advertise their block storage's underlying chunk size, it's a big performance win to not submit commands that cross them. If sector alignment is not provided, this patch uses the max sectors as before. This addresses the performance issue commit d3805611 attempted to fix, but was reverted due to splitting logic error. Signed-off-by:
Keith Busch <keith.busch@intel.com> Cc: Jens Axboe <axboe@fb.com> Cc: Ming Lei <tom.leiming@gmail.com> Cc: Kent Overstreet <kent.overstreet@gmail.com> Signed-off-by:
-
Trond Myklebust authored
commit 1a093ceb upstream. Since commit 2d8ae84f, nothing is bumping lo->plh_block_lgets in the layoutreturn path, so it should not be touched in nfs4_layoutreturn_release either. Fixes: 2d8ae84f ("NFSv4.1/pnfs: Remove redundant lo->plh_block_lgets...") Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
LABBE Corentin authored
commit 4f9ea866 upstream. sun4i-ss implementaton of md5/sha1 is via ahash algorithms. Commit 8996eafd ("crypto: ahash - ensure statesize is non-zero") made impossible to load them without giving statesize. This patch specifiy statesize for sha1 and md5. Fixes: 6298e948 ("crypto: sunxi-ss - Add Allwinner Security System crypto accelerator") Tested-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
- 31 Jan, 2016 1 commit
-
-
Greg Kroah-Hartman authored
-
