- 13 Mar, 2018 40 commits
-
-
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:
Johan Hovold <johan@kernel.org> Acked-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> 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>
-
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:
Takashi Iwai <tiwai@suse.de> Acked-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> 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:
Thomas Gleixner <tglx@linutronix.de> Signed-off-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:
David S. Miller <davem@davemloft.net> 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:
Bjorn Helgaas <bhelgaas@google.com> 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:
-
Varun Prakash authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 9b3a081f ] In case of connection reset Tx skb queue can have some skbs which are not transmitted so purge Tx skb queue in release_offload_resources() to avoid skb leak. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 35702778 ] When checking to see if a PCI bus can safely be reset, we previously checked to see if any of the children had their PCI_DEV_FLAGS_NO_BUS_RESET flag set. Children marked with that flag are known not to behave well after a bus reset. Some PCIe root port bridges also do not behave well after a bus reset, sometimes causing the devices behind the bridge to become unusable. Add a check for PCI_DEV_FLAGS_NO_BUS_RESET being set in the bridge device to allow these bridges to be flagged, and prevent their secondary buses from being reset. Signed-off-by:
David Daney <david.daney@cavium.com> [jglauber@cavium.com: fixed typo] Signed-off-by:
Jan Glauber <jglauber@cavium.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Dan Murphy authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit fc755687 ] Change the return error code to EINVAL if the MAC address is not valid in the set_wol function. Signed-off-by:
Dan Murphy <dmurphy@ti.com> Signed-off-by:
-
Russell King authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 5b64a296 ] On some platforms, the interrupt for the PL031 is optional. Avoid trying to claim the interrupt if it's not specified. Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Christian Lamparter authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 778f81d6 ] If crypto4xx is used in conjunction with dm-crypt, the available ring buffer elements are not enough to handle the load properly. On an aes-cbc-essiv:sha256 encrypted swap partition the read performance is abyssal: (tested with hdparm -t) /dev/mapper/swap_crypt: Timing buffered disk reads: 14 MB in 3.68 seconds = 3.81 MB/sec The patch increases both PPC4XX_NUM_SD and PPC4XX_NUM_PD to 256. This improves the performance considerably: /dev/mapper/swap_crypt: Timing buffered disk reads: 104 MB in 3.03 seconds = 34.31 MB/sec Furthermore, PPC4XX_LAST_SD, PPC4XX_LAST_GD and PPC4XX_LAST_PD can be easily calculated from their respective PPC4XX_NUM_* constant. Signed-off-by:
Christian Lamparter <chunkeey@gmail.com> Signed-off-by:
-
Derek Basehore authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 5d0c49ac ] This fixes an overflow condition that can happen with high max brightness and period values in compute_duty_cycle. This fixes it by using a 64 bit variable for computing the duty cycle. Signed-off-by:
Derek Basehore <dbasehore@chromium.org> Acked-by:
Thierry Reding <thierry.reding@gmail.com> Reviewed-by:
-
Sankar Patchineelam authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 2247925f ] Net device reset can fail when the h/w or f/w is in a bad state. Subsequent netdevice open fails in bnxt_hwrm_stat_ctx_alloc(). The cleanup invokes bnxt_hwrm_resource_free() which inturn calls bnxt_disable_int(). In this routine, the code segment if (ring->fw_ring_id != INVALID_HW_RING_ID) BNXT_CP_DB(cpr->cp_doorbell, cpr->cp_raw_cons); results in NULL pointer dereference as cpr->cp_doorbell is not yet initialized, and fw_ring_id is zero. The fix is to initialize cpr fw_ring_id to INVALID_HW_RING_ID before bnxt_init_chip() is invoked. Signed-off-by:
Sankar Patchineelam <sankar.patchineelam@broadcom.com> Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Vaidyanathan Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 293d264f ] drv->cpumask defaults to cpu_possible_mask in __cpuidle_driver_init(). On PowerNV platform cpu_present could be less than cpu_possible in cases where firmware detects the cpu, but it is not available to the OS. When CONFIG_HOTPLUG_CPU=n, such cpus are not hotplugable at runtime and hence we skip creating cpu_device. This breaks cpuidle on powernv where register_cpu() is not called for cpus in cpu_possible_mask that cannot be hot-added at runtime. Trying cpuidle_register_device() on cpu without cpu_device will cause crash like this: cpu 0xf: Vector: 380 (Data SLB Access) at [c000000ff1503490] pc: c00000000022c8bc: string+0x34/0x60 lr: c00000000022ed78: vsnprintf+0x284/0x42c sp: c000000ff1503710 msr: 9000000000009033 dar: 6000000060000000 current = 0xc000000ff1480000 paca = 0xc00000000fe82d00 softe: 0 irq_happened: 0x01 pid = 1, comm = swapper/8 Linux version 4.11.0-rc2 (sv@sagarika) (gcc version 4.9.4 (Buildroot 2017.02-00004-gc28573e) ) #15 SMP Fri Mar 17 19:32:02 IST 2017 enter ? for help [link register ] c00000000022ed78 vsnprintf+0x284/0x42c [c000000ff1503710] c00000000022ebb8 vsnprintf+0xc4/0x42c (unreliable) [c000000ff1503800] c00000000022ef40 vscnprintf+0x20/0x44 [c000000ff1503830] c0000000000ab61c vprintk_emit+0x94/0x2cc [c000000ff15038a0] c0000000000acc9c vprintk_func+0x60/0x74 [c000000ff15038c0] c000000000619694 printk+0x38/0x4c [c000000ff15038e0] c000000000224950 kobject_get+0x40/0x60 [c000000ff1503950] c00000000022507c kobject_add_internal+0x60/0x2c4 [c000000ff15039e0] c000000000225350 kobject_init_and_add+0x70/0x78 [c000000ff1503a60] c00000000053c288 cpuidle_add_sysfs+0x9c/0xe0 [c000000ff1503ae0] c00000000053aeac cpuidle_register_device+0xd4/0x12c [c000000ff1503b30] c00000000053b108 cpuidle_register+0x98/0xcc [c000000ff1503bc0] c00000000085eaf0 powernv_processor_idle_init+0x140/0x1e0 [c000000ff1503c60] c00000000000cd60 do_one_initcall+0xc0/0x15c [c000000ff1503d20] c000000000833e84 kernel_init_freeable+0x1a0/0x25c [c000000ff1503dc0] c00000000000d478 kernel_init+0x24/0x12c [c000000ff1503e30] c00000000000b564 ret_from_kernel_thread+0x5c/0x78 This patch fixes the bug by passing correct cpumask from powernv-cpuidle driver. Signed-off-by:
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com> Reviewed-by:
Gautham R. Shenoy <ego@linux.vnet.ibm.com> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> [ rjw: Comment massage ] Signed-off-by:
-
Russell King authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 916a008b ] dma_get_sgtable() tries to create a scatterlist table containing valid struct page pointers for the coherent memory allocation passed in to it. However, memory can be declared via dma_declare_coherent_memory(), or via other reservation schemes which means that coherent memory is not guaranteed to be backed by struct pages. In such cases, the resulting scatterlist table contains pointers to invalid pages, which causes kernel oops later. This patch adds detection of such memory, and refuses to create a scatterlist table for such memory. Reported-by:
Shuah Khan <shuahkhan@gmail.com> Signed-off-by:
-
Liping Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 77c1c03c ] We must call security_release_secctx to free the memory returned by security_secid_to_secctx, otherwise memory may be leaked forever. Fixes: ef493bd9 ("netfilter: nfnetlink_queue: add security context information") Signed-off-by:
Liping Zhang <zlpnobody@gmail.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Adam Wallis authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit b07c1251 ] Shutdown should be called for xhci_plat devices especially for situations where kexec might be used by stopping DMA transactions. Signed-off-by:
Adam Wallis <awallis@codeaurora.org> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit af109a2c ] gcc-7 points out that the AVMB1_ADDCARD ioctl results in an unintialized value ending up in the cardnr parameter: drivers/isdn/capi/kcapi.c: In function 'old_capi_manufacturer': drivers/isdn/capi/kcapi.c:1042:24: error: 'cdef.cardnr' may be used uninitialized in this function [-Werror=maybe-uninitialized] cparams.cardnr = cdef.cardnr; This has been broken since before the start of the git history, so either the value is not used for anything important, or the ioctl command doesn't get called in practice. Setting the cardnr to zero avoids the warning and makes sure we have consistent behavior. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Herongguang (Stephen) authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 0292e169 ] or VM memory are not put thus leaked in kvm_iommu_unmap_memslots() when destroy VM. This is consistent with current vfio implementation. Signed-off-by:
herongguang <herongguang.he@huawei.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Reizer, Eyal authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 9bcf53f3 ] mmc2 used for wl12xx was missing the keep-power-in suspend parameter. As a result the board couldn't reach suspend state. Signed-off-by:
Eyal Reizer <eyalr@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Gao Feng authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 75c689dc ] In the commit 93557f53 ("netfilter: nf_conntrack: nf_conntrack snmp helper"), the snmp_helper is replaced by nf_nat_snmp_hook. So the snmp_helper is never registered. But it still tries to unregister the snmp_helper, it could cause the panic. Now remove the useless snmp_helper and the unregister call in the error handler. Fixes: 93557f53 ("netfilter: nf_conntrack: nf_conntrack snmp helper") Signed-off-by:
Gao Feng <fgao@ikuai8.com> Signed-off-by:
-
Liping Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 83d90219 ] The nf_ct_helper_hash table is protected by nf_ct_helper_mutex, while nfct_helper operation is protected by nfnl_lock(NFNL_SUBSYS_CTHELPER). So it's possible that one CPU is walking the nf_ct_helper_hash for cthelper add/get/del, another cpu is doing nf_conntrack_helpers_unregister at the same time. This is dangrous, and may cause use after free error. Note, delete operation will flush all cthelpers added via nfnetlink, so using rcu to do protect is not easy. Now introduce a dummy list to record all the cthelpers added via nfnetlink, then we can walk the dummy list instead of walking the nf_ct_helper_hash. Also, keep nfnl_cthelper_dump_table unchanged, it may be invoked without nfnl_lock(NFNL_SUBSYS_CTHELPER) held. Signed-off-by:
-
Alexey Khoroshilov authored
BugLink: http://bugs.launchpad.net/bugs/1745054 [ Upstream commit 6ac3b77a ] vlsi_alloc_ring() checks for DMA mapping errors by comparing returned address with zero, while pci_dma_mapping_error() should be used. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
