- 13 Mar, 2018 40 commits
-
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit a36c2638 upstream. Since the commit 97cc2ed2 ("ALSA: hda - Fix yet another i915 pointer leftover in error path") cleared hdac_acomp pointer, the WARN_ON() non-NULL check in snd_hdac_i915_register_notifier() may give a false-positive warning, as the function gets called no matter whether the component is registered or not. For fixing it, let's get rid of the spurious WARN_ON(). Fixes: 97cc2ed2 ("ALSA: hda - Fix yet another i915 pointer leftover in error path") Reported-by:
Kouta Okamoto <kouta.okamoto@toshiba.co.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com>
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 15f8c5f2 upstream. Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent codec node was also prematurely freed, while the child node was leaked. Fixes: 2d6d649a ("ASoC: twl4030: Support for DT booted kernel") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Maciej S. Szmigiero authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 695b78b5 upstream. AC'97 ops (register read / write) need SSI regmap and clock, so they have to be set after them. We also need to set these ops back to NULL if we fail the probe. Signed-off-by:
Maciej S. Szmigiero <mail@maciej.szmigiero.name> Acked-by:
Nicolin Chen <nicoleotsuka@gmail.com> Signed-off-by:
-
Steve Wise authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit f55688c4 upstream. If the RECV CQE is in error, ignore the MSN check. This was causing recvs that were flushed into the sw cq to be completed with the wrong status (BAD_MSN instead of FLUSHED). Signed-off-by:
Steve Wise <swise@opengridcomputing.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Steven Rostedt (VMware) authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 45d8b80c upstream. Two info bits were added to the "commit" part of the ring buffer data page when returned to be consumed. This was to inform the user space readers that events have been missed, and that the count may be stored at the end of the page. What wasn't handled, was the splice code that actually called a function to return the length of the data in order to zero out the rest of the page before sending it up to user space. These data bits were returned with the length making the value negative, and that negative value was not checked. It was compared to PAGE_SIZE, and only used if the size was less than PAGE_SIZE. Luckily PAGE_SIZE is unsigned long which made the compare an unsigned compare, meaning the negative size value did not end up causing a large portion of memory to be randomly zeroed out. Fixes: 66a8cb95 ("ring-buffer: Add place holder recording of dropped events") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Jing Xia authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 24f2aaf9 upstream. Double free of the ring buffer happens when it fails to alloc new ring buffer instance for max_buffer if TRACER_MAX_TRACE is configured. The root cause is that the pointer is not set to NULL after the buffer is freed in allocate_trace_buffers(), and the freeing of the ring buffer is invoked again later if the pointer is not equal to Null, as: instance_mkdir() |-allocate_trace_buffers() |-allocate_trace_buffer(tr, &tr->trace_buffer...) |-allocate_trace_buffer(tr, &tr->max_buffer...) // allocate fail(-ENOMEM),first free // and the buffer pointer is not set to null |-ring_buffer_free(tr->trace_buffer.buffer) // out_free_tr |-free_trace_buffers() |-free_trace_buffer(&tr->trace_buffer); //if trace_buffer is not null, free again |-ring_buffer_free(buf->buffer) |-rb_free_cpu_buffer(buffer->buffers[cpu]) // ring_buffer_per_cpu is null, and // crash in ring_buffer_per_cpu->pages Link: http://lkml.kernel.org/r/20171226071253.8968-1-chunyan.zhang@spreadtrum.com Fixes: 737223fb ("tracing: Consolidate buffer allocation code") Signed-off-by:
Jing Xia <jing.xia@spreadtrum.com> Signed-off-by:
Chunyan Zhang <chunyan.zhang@spreadtrum.com> Signed-off-by:
-
Steven Rostedt (VMware) authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 4397f045 upstream. Jing Xia and Chunyan Zhang reported that on failing to allocate part of the tracing buffer, memory is freed, but the pointers that point to them are not initialized back to NULL, and later paths may try to free the freed memory again. Jing and Chunyan fixed one of the locations that does this, but missed a spot. Link: http://lkml.kernel.org/r/20171226071253.8968-1-chunyan.zhang@spreadtrum.com Fixes: 737223fb ("tracing: Consolidate buffer allocation code") Reported-by:
-
Steven Rostedt (VMware) authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 6b7e633f upstream. The ring_buffer_read_page() takes care of zeroing out any extra data in the page that it returns. There's no need to zero it out again from the consumer. It was removed from one consumer of this function, but read_buffers_splice_read() did not remove it, and worse, it contained a nasty bug because of it. Fixes: 2711ca23 ("ring-buffer: Move zeroing out excess in page to ring buffer code") Signed-off-by:
-
Yelena Krivosheev authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 4423c18e upstream. When port connect to PHY in polling mode (with poll interval 1 sec), port and phy link status must be synchronize in order don't loss link change event. [gregory.clement@free-electrons.com: add fixes tag] Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP network unit") Signed-off-by:
Yelena Krivosheev <yelena@marvell.com> Tested-by:
Dmitri Epshtein <dima@marvell.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ravi Bangoria authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit f41d84dd upstream. It's theoretically possible that branch instructions recorded in BHRB (Branch History Rolling Buffer) entries have already been unmapped before they are processed by the kernel. Hence, trying to dereference such memory location will result in a crash. eg: Unable to handle kernel paging request for data at address 0xd000000019c41764 Faulting instruction address: 0xc000000000084a14 NIP [c000000000084a14] branch_target+0x4/0x70 LR [c0000000000eb828] record_and_restart+0x568/0x5c0 Call Trace: [c0000000000eb3b4] record_and_restart+0xf4/0x5c0 (unreliable) [c0000000000ec378] perf_event_interrupt+0x298/0x460 [c000000000027964] performance_monitor_exception+0x54/0x70 [c000000000009ba4] performance_monitor_common+0x114/0x120 Fix it by deferefencing the addresses safely. Fixes: 69123184 ("powerpc/perf: Fix setting of "to" addresses for BHRB") Suggested-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> Reviewed-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Wanpeng Li authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit d73235d1 upstream. *** Guest State *** CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7 CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=ffffffffffffe871 CR3 = 0x00000000fffbc000 RSP = 0x0000000000000000 RIP = 0x0000000000000000 RFLAGS=0x00000000 DR7 = 0x0000000000000400 ^^^^^^^^^^ The failed vmentry is triggered by the following testcase when ept=Y: #include <unistd.h> #include <sys/syscall.h> #include <string.h> #include <stdint.h> #include <linux/kvm.h> #include <fcntl.h> #include <sys/ioctl.h> long r[5]; int main() { r[2] = open("/dev/kvm", O_RDONLY); r[3] = ioctl(r[2], KVM_CREATE_VM, 0); r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7); struct kvm_regs regs = { .rflags = 0, }; ioctl(r[4], KVM_SET_REGS, ®s); ioctl(r[4], KVM_RUN, 0); } X86 RFLAGS bit 1 is fixed set, userspace can simply clearing bit 1 of RFLAGS with KVM_SET_REGS ioctl which results in vmentry fails. This patch fixes it by oring X86_EFLAGS_FIXED during ioctl. Suggested-by:
Jim Mattson <jmattson@google.com> Reviewed-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Quan Xu <quan.xu0@gmail.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Jim Mattson <jmattson@google.com> Signed-off-by:
Wanpeng Li <wanpeng.li@hotmail.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Ricardo Ribalda Delgado authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 5a1314fa upstream. When the core is configured in C_SPI_MODE > 0, it integrates a lookup table that automatically configures the core in dual or quad mode based on the command (first byte on the tx fifo). Unfortunately, that list mode_?_memoy_*.mif does not contain all the supported commands by the flash. Since 4.14 spi-nor automatically tries to probe the flash using SFDP (command 0x5a), and that command is not part of the list_mode table. Whit the right combination of C_SPI_MODE and C_SPI_MEMORY this leads into a stall that can only be recovered with a soft rest. This patch detects this kind of stall and returns -EIO to the caller on those commands. spi-nor can handle this error properly: m25p80 spi0.0: Detected stall. Check C_SPI_MODE and C_SPI_MEMORY. 0x21 0x2404 m25p80 spi0.0: SPI transfer failed: -5 spi_master spi0: failed to transfer one message from queue m25p80 spi0.0: s25sl064p (8192 Kbytes) Signed-off-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Signed-off-by:
-
Helge Deller authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit bcf3f175 upstream. Diva GSP card has built-in serial AUX port and ATI graphic card which simply don't work and which both don't have external connectors. User Guides even mention that those devices shouldn't be used. So, prevent that Linux drivers try to enable those devices. Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Rafael J. Wysocki authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 5839ee73 upstream. It is incorrect to call pci_restore_state() for devices in low-power states (D1-D3), as that involves the restoration of MSI setup which requires MMIO to be operational and that is only the case in D0. However, pci_pm_thaw_noirq() may do that if the driver's "freeze" callbacks put the device into a low-power state, so fix it by making it force devices into D0 via pci_set_power_state() instead of trying to "update" their power state which is pointless. Fixes: e60514bd (PCI/PM: Restore the status of PCI devices across hibernation) Reported-by:
Thomas Gleixner <tglx@linutronix.de> Reported-by:
Maarten Lankhorst <dev@mblankhorst.nl> Tested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 5a15f289 upstream. The commit 89b89d12 ("ALSA: usb-audio: Add check return value for usb_string()") added the check of the return value from snd_usb_copy_string_desc(), which is correct per se, but it introduced a regression. In the original code, either the "Clock Source", "Playback Source" or "Capture Source" suffix is added after the terminal string, while the commit changed it to add the suffix only when get_term_name() is failing. It ended up with an incorrect ctl name like "PCM" instead of "PCM Capture Source". Also, even the original code has a similar bug: when the ctl name is generated from snd_usb_copy_string_desc() for the given iSelector, it also doesn't put the suffix. This patch addresses these issues: the suffix is added always when no static mapping is found. Also the patch tries to put more comments and cleans up the if/else block for better readability in order to avoid the same pitfall again. Fixes: 89b89d12 ("ALSA: usb-audio: Add check return value for usb_string()") Reported-and-tested-by:
Mauro Santos <registo.mailling@gmail.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit c1cfd902 upstream. 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. Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 85e9b13c upstream. Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent node was prematurely freed, while the child node was leaked. Note that the CONFIG_OF compile guard can be removed as of_get_child_by_name() provides a !CONFIG_OF implementation which always fails. Fixes: 37e13cec ("mfd: Add support for Device Tree to twl6040") Fixes: ca2cad6a ("mfd: Fix twl6040 build failure") Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 0a423772 upstream. A helper purported to look up a child node based on its name was using the wrong of-helper and ended up prematurely freeing the parent of-node while leaking any matching node. To make things worse, any matching node would not even necessarily be a child node as the whole device tree was searched depth-first starting at the parent. Fixes: 019a7e6b ("mfd: twl4030-audio: Add DT support") Signed-off-by:
-
Jon Hunter authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 15d83748 upstream. On the Tegra124 Nyan-Big chromebook the very first SPI message sent to the EC is failing. The Tegra SPI driver configures the SPI chip-selects to be active-high by default (and always has for many years). The EC SPI requires an active-low chip-select and so the Tegra chip-select is reconfigured to be active-low when the EC SPI driver calls spi_setup(). The problem is that if the first SPI message to the EC is sent too soon after reconfiguring the SPI chip-select, it fails. The EC SPI driver prevents back-to-back SPI messages being sent too soon by keeping track of the time the last transfer was sent via the variable 'last_transfer_ns'. To prevent the very first transfer being sent too soon, initialise the 'last_transfer_ns' variable after calling spi_setup() and before sending the first SPI message. Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Reviewed-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Benson Leung <bleung@chromium.org> Signed-off-by:
-
Sebastian Andrzej Siewior authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit 9abffc6f upstream. mcryptd_enqueue_request() grabs the per-CPU queue struct and protects access to it with disabled preemption. Then it schedules a worker on the same CPU. The worker in mcryptd_queue_worker() guards access to the same per-CPU variable with disabled preemption. If we take CPU-hotplug into account then it is possible that between queue_work_on() and the actual invocation of the worker the CPU goes down and the worker will be scheduled on _another_ CPU. And here the preempt_disable() protection does not work anymore. The easiest thing is to add a spin_lock() to guard access to the list. Another detail: mcryptd_queue_worker() is not processing more than MCRYPTD_BATCH invocation in a row. If there are still items left, then it will invoke queue_work() to proceed with more later. *I* would suggest to simply drop that check because it does not use a system workqueue and the workqueue is already marked as "CPU_INTENSIVE". And if preemption is required then the scheduler should do it. However if queue_work() is used then the work item is marked as CPU unbound. That means it will try to run on the local CPU but it may run on another CPU as well. Especially with CONFIG_DEBUG_WQ_FORCE_RR_CPU=y. Again, the preempt_disable() won't work here but lock which was introduced will help. In order to keep work-item on the local CPU (and avoid RR) I changed it to queue_work_on(). Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1745069 commit bb82e0b4 upstream. The commit f6f82851 ("pstore: pass allocated memory region back to caller") changed the check of the return value from erst_read() in erst_reader() in the following way: if (len == -ENOENT) goto skip; - else if (len < 0) { - rc = -1; + else if (len < sizeof(*rcd)) { + rc = -EIO; goto out; This introduced another bug: since the comparison with sizeof() is cast to unsigned, a negative len value doesn't hit any longer. As a result, when an error is returned from erst_read(), the code falls through, and it may eventually lead to some weird thing like memory corruption. This patch adds the negative error value check more explicitly for addressing the issue. Fixes: f6f82851 (pstore: pass allocated memory region back to caller) Tested-by:
Jerry Tang <jtang@suse.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1745054Signed-off-by:
-
Sudip Mukherjee authored
BugLink: http://bugs.launchpad.net/bugs/1745054 commit 8ee912da upstream. The build of alpha allmodconfig is giving error: arch/alpha/include/asm/mmu_context.h: In function 'ev5_switch_mm': arch/alpha/include/asm/mmu_context.h:160:2: error: implicit declaration of function 'task_thread_info'; did you mean 'init_thread_info'? [-Werror=implicit-function-declaration] The file 'mmu_context.h' needed an extra header file. Link: http://lkml.kernel.org/r/1505668810-7497-1-git-send-email-sudipm.mukherjee@gmail.comSigned-off-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1745054 commit 97cc2ed2 upstream. The hdac_acomp object in hdac_i915.c is left as assigned even after binding with i915 actually fails, and this leads to the WARN_ON() at the next load of the module. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94736Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1745054 commit bed2e98e upstream. Currently HD-audio driver on Intel Skylake or Broxteon gives an error message when binding with i915 audio component fails. However, this isn't any serious error on a system without Intel graphics. Indeed there are such systems, where a third-party codec (e.g. Creative) is put on the mobo while using other discrete GPU (e.g. Nvidia). Printing a kernel "error" message is overreaction in such a case. This patch downgrades the print level for that message. For systems that mandate the i915 binding (e.g. Haswell or Broadwell HDMI/DP), another kernel error message is shown in addition to make clear what went wrong. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111021Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1745054 commit faafd03d upstream. The commit [d745f5e7: ALSA: hda - Add the pin / port mapping on Intel ILK and VLV] introduced a WARN_ON() to check the pointer for avoiding the double initializations. But hdac_acomp pointer wasn't cleared at snd_hdac_i915_exit(), thus after reloading the HD-audio driver, it may result in the false positive warning. This patch makes sure to clear the leftover pointer at exit. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94736Reported-by:
Daniela Doras-prodan <daniela.doras-prodan@intel.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1745054 This reverts commit ffc75657 which is commit a0085f25 upstream. It causes problems with working systems, as noted by a number of the ChromeOS developers. Cc: Sukumar Ghorai <sukumar.ghorai@intel.com> Cc: Amit K Bag <amit.k.bag@intel.com> Cc: Oliver Neukum <oneukum@suse.com> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Matthias Kaehlcke <mka@chromium.org> Reported-by:
Guenter Roeck <linux@roeck-us.net> Reported-by:
-
Aleksandar Markovic authored
BugLink: http://bugs.launchpad.net/bugs/1745054 commit 409fcace upstream. Fix final phase of <CLASS|MADDF|MSUBF|MAX|MIN|MAXA|MINA>.<D|S> emulation. Provide proper generation of SIGFPE signal and updating debugfs FP exception stats in cases of any exception flags set in preceding phases of emulation. CLASS.<D|S> instruction may generate "Unimplemented Operation" FP exception. <MADDF|MSUBF>.<D|S> instructions may generate "Inexact", "Unimplemented Operation", "Invalid Operation", "Overflow", and "Underflow" FP exceptions. <MAX|MIN|MAXA|MINA>.<D|S> instructions can generate "Unimplemented Operation" and "Invalid Operation" FP exceptions. The proper final processing of the cases when any FP exception flag is set is achieved by replacing "break" statement with "goto copcsr" statement. With such solution, this patch brings the final phase of emulation of the above instructions consistent with the one corresponding to the previously implemented emulation of other related FPU instructions (ADD, SUB, etc.). Fixes: 38db37ba ("MIPS: math-emu: Add support for the MIPS R6 CLASS FPU instruction") Fixes: e24c3bec ("MIPS: math-emu: Add support for the MIPS R6 MADDF FPU instruction") Fixes: 83d43305 ("MIPS: math-emu: Add support for the MIPS R6 MSUBF FPU instruction") Fixes: a79f5f9b ("MIPS: math-emu: Add support for the MIPS R6 MAX{, A} FPU instruction") Fixes: 4e9561b2 ("MIPS: math-emu: Add support for the MIPS R6 MIN{, A} FPU instruction") Signed-off-by:
Aleksandar Markovic <aleksandar.markovic@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Douglas Leung <douglas.leung@mips.com> Cc: Goran Ferenc <goran.ferenc@mips.com> Cc: "Maciej W. Rozycki" <macro@imgtec.com> Cc: Miodrag Dinic <miodrag.dinic@mips.com> Cc: Paul Burton <paul.burton@mips.com> Cc: Petar Jovanovic <petar.jovanovic@mips.com> Cc: Raghu Gandham <raghu.gandham@mips.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17581/Signed-off-by:
James Hogan <jhogan@kernel.org> Signed-off-by:
-
Arvind Yadav authored
BugLink: http://bugs.launchpad.net/bugs/1745054 commit 919054fd upstream. clk_prepare_enable() can fail here and we must check its return value. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
Kevin Wangtao <kevin.wangtao@hisilicon.com> Signed-off-by:
-
Nicholas Piggin authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit f187851b ] When failing to enter broadcast timer mode for an idle state that requires it, a new state is selected that does not require broadcast, but the broadcast variable remains set. This causes tick_broadcast_exit to be called despite not having entered broadcast mode. This causes the WARN_ON_ONCE(!irqs_disabled()) to trigger in some cases. It does not appear to cause problems for code today, but seems to violate the interface so should be fixed. Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Reviewed-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
-
Alexandre Belloni authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 74717b28 ] If there is any non expired timer in the queue, the RTC alarm is never set. This is an issue when adding a timer that expires before the next non expired timer. Ensure the RTC alarm is set in that case. Fixes: 2b2f5ff0 ("rtc: interface: ignore expired timers when enqueuing new timers") Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Hoang Tran authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit cf5d74b8 ] With the commit 76174004 (tcp: do not slow start when cwnd equals ssthresh), the comparison to the reduced cwnd in tcp_vegas_ssthresh() would under-evaluate the ssthresh. Signed-off-by:
Hoang Tran <hoang.tran@uclouvain.be> Signed-off-by:
-
Jacob Keller authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 17a91809 ] When we process VF mailboxes, the driver is likely going to also queue up messages to the switch manager. This process merely queues up the FIFO, but doesn't actually begin the transmission process. Because we hold the mailbox lock during this VF processing, the PF<->SM mailbox is not getting processed at this time. Ensure that we actually process the PF<->SM mailbox in between each PF<->VF mailbox. This should ensure prompt transmission of the messages queued up after each VF message is received and handled. Signed-off-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Krishneil Singh <krishneil.k.singh@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Dick Kennedy authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit e8bcf0ae ] Local Reject/Invalid RPI errors seen during discovery. Temporary RPI cleanup was occurring regardless of SLI rev. It's only necessary on SLI-4. Adjust the test for whether cleanup is necessary. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Dick Kennedy authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 184fc2b9 ] Firmware update fails with: status x17 add_status x56 on the final write If multiple DMA buffers are used for the download, some firmware revs have difficulty with signatures and crcs split across the dma buffer boundaries. Resolve by making all writes be a single 4k page in length. Signed-off-by:
-
Gabriele Paoloni authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 86acc790 ] Previously, if an non-fatal error was reported by an endpoint, we called report_error_detected() for the endpoint, every sibling on the bus, and their descendents. If any of them did not implement the .error_detected() method, do_recovery() failed, leaving all these devices unrecovered. For example, the system described in the bugzilla below has two devices: 0000:74:02.0 [19e5:a230] SAS controller, driver has .error_detected() 0000:74:03.0 [19e5:a235] SATA controller, driver lacks .error_detected() When a device such as 74:02.0 reported a non-fatal error, do_recovery() failed because 74:03.0 lacked an .error_detected() method. But per PCIe r3.1, sec 6.2.2.2.2, such an error does not compromise the Link and does not affect 74:03.0: Non-fatal errors are uncorrectable errors which cause a particular transaction to be unreliable but the Link is otherwise fully functional. Isolating Non-fatal from Fatal errors provides Requester/Receiver logic in a device or system management software the opportunity to recover from the error without resetting the components on the Link and disturbing other transactions in progress. Devices not associated with the transaction in error are not impacted by the error. Report non-fatal errors only to the endpoint that reported them. We really want to check for AER_NONFATAL here, but the current code structure doesn't allow that. Looking for pci_channel_io_normal is the best we can do now. Link: https://bugzilla.kernel.org/show_bug.cgi?id=197055 Fixes: 6c2b374d ("PCI-Express AER implemetation: AER core and aerdriver") Signed-off-by:
Gabriele Paoloni <gabriele.paoloni@huawei.com> Signed-off-by:
Dongdong Liu <liudongdong3@huawei.com> [bhelgaas: changelog] Signed-off-by:
-
Emil Tantilov authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit dcfd6b83 ] This patch is resolving Coverity hits where padding in a structure could be used uninitialized. - Initialize fwd_cmd.pad/2 before ixgbe_calculate_checksum() - Initialize buffer.pad2/3 before ixgbe_hic_unlocked() Signed-off-by:
Emil Tantilov <emil.s.tantilov@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
-
Christophe JAILLET authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 18eb8636 ] Check memory allocation failures and return -ENOMEM in such cases, as already done for other memory allocations in this function. This avoids NULL pointers dereference. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Tested-by: Aaron Brown <aaron.f.brown@intel.com Acked-by:
PJ Waskiewicz <peter.waskiewicz.jr@intel.com> Signed-off-by:
-
Stuart Hayes authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 27d61629 ] When creating virtual functions, create the "virtfn%u" and "physfn" links in sysfs *before* attaching the driver instead of after. When we attach the driver to the new virtual network interface first, there is a race when the driver attaches to the new sends out an "add" udev event, and the network interface naming software (biosdevname or systemd, for example) tries to look at these links. Signed-off-by:
Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by:
-
Sreekanth Reddy authored
scsi: mpt3sas: Fix IO error occurs on pulling out a drive from RAID1 volume created on two SATA drive BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 2ce9a364 ] Whenever an I/O for a RAID volume fails with IOCStatus MPI2_IOCSTATUS_SCSI_IOC_TERMINATED and SCSIStatus equal to (MPI2_SCSI_STATE_TERMINATED | MPI2_SCSI_STATE_NO_SCSI_STATUS) then return the I/O to SCSI midlayer with "DID_RESET" (i.e. retry the IO infinite times) set in the host byte. Previously, the driver was completing the I/O with "DID_SOFT_ERROR" which causes the I/O to be quickly retried. However, firmware needed more time and hence I/Os were failing. Signed-off-by:
Sreekanth Reddy <Sreekanth.Reddy@broadcom.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
