- 08 Nov, 2016 40 commits
-
-
Nicolas Iooss authored
BugLink: http://bugs.launchpad.net/bugs/1637501 commit 61ab0d40 upstream. In sst_prepare_and_post_msg(), when a response is received in "block", the following code gets executed: *data = kzalloc(block->size, GFP_KERNEL); memcpy(data, (void *) block->data, block->size); The memcpy() call overwrites the content of the *data pointer instead of filling the newly-allocated memory (which pointer is hold by *data). Fix this by merging kzalloc+memcpy into a single kmemdup() call. Thanks Joe Perches for suggesting using kmemdup() Fixes: 60dc8dba ("ASoC: Intel: sst: Add some helper functions") Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Rafał Miłecki authored
BugLink: http://bugs.launchpad.net/bugs/1637501 commit 23e9c128 upstream. This function is called from get_station callback which means that every time user space was getting/dumping station(s) we were leaking 2 KiB. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Fixes: 1f0dc59a ("brcmfmac: rework .get_station() callback") Acked-by:
Arend van Spriel <arend.vanspriel@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Guilherme G Piccoli authored
BugLink: http://bugs.launchpad.net/bugs/1637501 commit edfc23ee upstream. Although rare, it's possible to hit PCI error early on device probe, meaning possibly some structs are not entirely initialized, and some might even be completely uninitialized, leading to NULL pointer dereference. The i40e driver currently presents a "bad" behavior if device hits such early PCI error: firstly, the struct i40e_pf might not be attached to pci_dev yet, leading to a NULL pointer dereference on access to pf->state. Even checking if the struct is NULL and avoiding the access in that case isn't enough, since the driver cannot recover from PCI error that early; in our experiments we saw multiple failures on kernel log, like: [549.664] i40e 0007:01:00.1: Initial pf_reset failed: -15 [549.664] i40e: probe of 0007:01:00.1 failed with error -15 [...] [871.644] i40e 0007:01:00.1: The driver for the device stopped because the device firmware failed to init. Try updating your NVM image. [871.644] i40e: probe of 0007:01:00.1 failed with error -32 [...] [872.516] i40e 0007:01:00.0: ARQ: Unknown event 0x0000 ignored Between the first probe failure (error -15) and the second (error -32) another PCI error happened due to the first bad probe. Also, driver started to flood console with those ARQ event messages. This patch will prevent these issues by allowing error recovery mechanism to remove the failed device from the system instead of trying to recover from early PCI errors during device probe. Signed-off-by:
Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com> Acked-by:
Jacob Keller <jacob.e.keller@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Miklos Szeredi authored
BugLink: http://bugs.launchpad.net/bugs/1637501 commit a09f99ed upstream. Fuse allowed VFS to set mode in setattr in order to clear suid/sgid on chown and truncate, and (since writeback_cache) write. The problem with this is that it'll potentially restore a stale mode. The poper fix would be to let the filesystems do the suid/sgid clearing on the relevant operations. Possibly some are already doing it but there's no way we can detect this. So fix this by refreshing and recalculating the mode. Do this only if ATTR_KILL_S[UG]ID is set to not destroy performance for writes. This is still racy but the size of the window is reduced. Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Miklos Szeredi authored
BugLink: http://bugs.launchpad.net/bugs/1637501 commit 5e2b8828 upstream. Without "default_permissions" the userspace filesystem's lookup operation needs to perform the check for search permission on the directory. If directory does not allow search for everyone (this is quite rare) then userspace filesystem has to set entry timeout to zero to make sure permissions are always performed. Changing the mode bits of the directory should also invalidate the (previously cached) dentry to make sure the next lookup will have a chance of updating the timeout, if needed. Reported-by:
Jean-Pierre André <jean-pierre.andre@wanadoo.fr> Signed-off-by:
-
Miklos Szeredi authored
BugLink: http://bugs.launchpad.net/bugs/1637501 commit cb3ae6d2 upstream. Make sure userspace filesystem is returning a well formed list of xattr names (zero or more nonzero length, null terminated strings). [Michael Theall: only verify in the nonzero size case] Signed-off-by:
-
Peng Fan authored
BugLink: http://bugs.launchpad.net/bugs/1637501 commit 85714108 upstream. When dma_common_free_remap, the input parameter 'size' may not be page aligned. And, met kernel warning when doing iommu dma for usb on i.MX8 platform: " WARNING: CPU: 0 PID: 869 at mm/vmalloc.c:70 vunmap_page_range+0x1cc/0x1d0() Modules linked in: CPU: 0 PID: 869 Comm: kworker/u8:2 Not tainted 4.1.12-00444-gc5f9d1d-dirty #147 Hardware name: Freescale i.MX8DV Sabreauto (DT) Workqueue: ci_otg ci_otg_work Call trace: [<ffffffc000089920>] dump_backtrace+0x0/0x124 [<ffffffc000089a54>] show_stack+0x10/0x1c [<ffffffc0006d1e6c>] dump_stack+0x84/0xc8 [<ffffffc0000b4568>] warn_slowpath_common+0x98/0xd0 [<ffffffc0000b4664>] warn_slowpath_null+0x14/0x20 [<ffffffc000170348>] vunmap_page_range+0x1c8/0x1d0 [<ffffffc000170388>] unmap_kernel_range+0x20/0x88 [<ffffffc000460ad0>] dma_common_free_remap+0x74/0x84 [<ffffffc0000940d8>] __iommu_free_attrs+0x9c/0x178 [<ffffffc0005032bc>] ehci_mem_cleanup+0x140/0x194 [<ffffffc000503548>] ehci_stop+0x8c/0xdc [<ffffffc0004e8258>] usb_remove_hcd+0xf0/0x1cc [<ffffffc000516bc0>] host_stop+0x1c/0x58 [<ffffffc000514240>] ci_otg_work+0xdc/0x120 [<ffffffc0000c9c34>] process_one_work+0x134/0x33c [<ffffffc0000c9f78>] worker_thread+0x13c/0x47c [<ffffffc0000cf43c>] kthread+0xd8/0xf0 " For dma_common_pages_remap: dma_common_pages_remap |->get_vm_area_caller |->__get_vm_area_node |->size = PAGE_ALIGN(size); Round up to page aligned So, in dma_common_free_remap, we also need a page aligned size, pass 'PAGE_ALIGN(size)' to unmap_kernel_range. Signed-off-by:
Peng Fan <van.freenix@gmail.com> Signed-off-by:
-
Junjie Mao authored
BugLink: http://bugs.launchpad.net/bugs/1637501 commit 14155caf upstream. Fixes: 4246a0b6 ("block: add a bi_error field to struct bio") Signed-off-by:
Junjie Mao <junjie.mao@enight.me> Acked-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Kefeng Wang authored
BugLink: http://bugs.launchpad.net/bugs/1637501 commit e16b46f1 upstream. It should check the data->pclk, not data->clk when get apb_pclk. Fixes: c8ed99d4("serial: 8250_dw: Add support for deferred probing") Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Tested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1637500Signed-off-by:
-
H.J. Lu authored
BugLink: http://bugs.launchpad.net/bugs/1637500 commit 6d92bc9d upstream. The 32-bit x86 assembler in binutils 2.26 will generate R_386_GOT32X relocation to get the symbol address in PIC. When the compressed x86 kernel isn't built as PIC, the linker optimizes R_386_GOT32X relocations to their fixed symbol addresses. However, when the compressed x86 kernel is loaded at a different address, it leads to the following load failure: Failed to allocate space for phdrs during the decompression stage. If the compressed x86 kernel is relocatable at run-time, it should be compiled with -fPIE, instead of -fPIC, if possible and should be built as Position Independent Executable (PIE) so that linker won't optimize R_386_GOT32X relocation to its fixed symbol address. Older linkers generate R_386_32 relocations against locally defined symbols, _bss, _ebss, _got and _egot, in PIE. It isn't wrong, just less optimal than R_386_RELATIVE. But the x86 kernel fails to properly handle R_386_32 relocations when relocating the kernel. To generate R_386_RELATIVE relocations, we mark _bss, _ebss, _got and _egot as hidden in both 32-bit and 64-bit x86 kernels. To build a 64-bit compressed x86 kernel as PIE, we need to disable the relocation overflow check to avoid relocation overflow errors. We do this with a new linker command-line option, -z noreloc-overflow, which got added recently: commit 4c10bbaa0912742322f10d9d5bb630ba4e15dfa7 Author: H.J. Lu <hjl.tools@gmail.com> Date: Tue Mar 15 11:07:06 2016 -0700 Add -z noreloc-overflow option to x86-64 ld Add -z noreloc-overflow command-line option to the x86-64 ELF linker to disable relocation overflow check. This can be used to avoid relocation overflow check if there will be no dynamic relocation overflow at run-time. The 64-bit compressed x86 kernel is built as PIE only if the linker supports -z noreloc-overflow. So far 64-bit relocatable compressed x86 kernel boots fine even when it is built as a normal executable. Signed-off-by:
H.J. Lu <hjl.tools@gmail.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org [ Edited the changelog and comments. ] Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1633128 Use the DMA_ATTR_NO_WARN attribute for the dma_map_sg() call of the nvme driver that returns BLK_MQ_RQ_QUEUE_BUSY (not for BLK_MQ_RQ_QUEUE_ERROR). Link: http://lkml.kernel.org/r/1470092390-25451-4-git-send-email-mauricfo@linux.vnet.ibm.comSigned-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Reviewed-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Cc: Keith Busch <keith.busch@intel.com> Cc: Jens Axboe <axboe@fb.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com>
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1633128 Add support for the DMA_ATTR_NO_WARN attribute on powerpc iommu code. Link: http://lkml.kernel.org/r/1470092390-25451-3-git-send-email-mauricfo@linux.vnet.ibm.comSigned-off-by:
Michael Ellerman <mpe@ellerman.id.au> Cc: Keith Busch <keith.busch@intel.com> Cc: Jens Axboe <axboe@fb.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Mauricio Faria de Oliveira authored
BugLink: http://bugs.launchpad.net/bugs/1633128 Introduce the DMA_ATTR_NO_WARN attribute, and document it. Link: http://lkml.kernel.org/r/1470092390-25451-2-git-send-email-mauricfo@linux.vnet.ibm.comSigned-off-by:
-
Arend Van Spriel authored
User-space can choose to omit NL80211_ATTR_SSID and only provide raw IE TLV data. When doing so it can provide SSID IE with length exceeding the allowed size. The driver further processes this IE copying it into a local variable without checking the length. Hence stack can be corrupted and used as exploit. Cc: stable@vger.kernel.org # v4.7 Reported-by:
Daxing Guo <freener.gdx@gmail.com> Reviewed-by:
Hante Meuleman <hante.meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com> Reviewed-by:
Franky Lin <franky.lin@broadcom.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Acked-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1620979 It turns out that for north and southwest communities, they can only generate GPIO interrupts for lower 8 interrupts (IntSel value). The upper part (8-15) can only generate GPEs (General Purpose Events). Now the reason why EC events such as pressing hotkeys does not work if we mask all the interrupts is that in order to generate either interrupts or GPEs the INTMASK register must have that particular interrupt unmasked. In case of GPEs the CPU does not trigger normal interrupt (and thus the GPIO driver does not see it) but instead it causes SCI (System Control Interrupt) to be triggered with the GPE in question set. To make this all work as expected we only add those GPIOs to the IRQ domain that can actually generate interrupts (IntSel value 0-7) and skip others. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> (cherry picked from commit 47c950d1) Signed-off-by:
Phidias Chiang <phidias.chiang@canonical.com> Acked-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1620979 The Cherryview GPIO controller has 8 or 16 wires connected to the I/O-APIC which can be used directly by the platform/BIOS or drivers. One such wire is used as SCI (System Control Interrupt) which ACPI depends on to be able to trigger GPEs (General Purpose Events). The pinctrl driver itself uses another IRQ resource which is wire OR of all the 8 (or 16) wires and follows what BIOS has programmed to the IntSel register of each pin. Currently the driver masks all interrupts at probe time and this prevents these direct interrupts from working as expected. The reason for this is that some early stage prototypes had some pins misconfigured causing lots of spurious interrupts. We fix this by leaving the interrupt mask untouched. This allows SCI and other direct interrupts work properly. What comes to the possible spurious interrupts we switch the default handler to be handle_bad_irq() instead of handle_simple_irq() (which was not correct anyway). Reported-by:
Yu C Chen <yu.c.chen@intel.com> Reported-by:
Anisse Astier <anisse@astier.eu> Signed-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1620979 When using GPIO irqchip helpers to setup irqchip for a gpiolib based driver, it is not possible to select which GPIOs to add to the IRQ domain. Instead it just adds all GPIOs which is not always desired. For example there might be GPIOs that for some reason cannot generated normal interrupts at all. To support this we add a flag irq_need_valid_mask to struct gpio_chip. When this flag is set the core allocates irq_valid_mask that holds one bit for each GPIO the chip has. By default all bits are set but drivers can manipulate this using set_bit() and clear_bit() accordingly. Then when gpiochip_irqchip_add() is called, this mask is checked and all GPIOs with bit is set are added to the IRQ domain created for the GPIO chip. Suggested-by:
-
Gerald Schaefer authored
When interrupting an application which was allocating DMAable memory, it was possible, that the DMA memory was deallocated twice, leading to the error symptoms below. BugLink: http://bugs.launchpad.net/bugs/1559194 Thanks to Gerald, who analyzed the problem and provided this patch. I agree with his analysis of the problem: ddcb_cmd_fixups() -> genwqe_alloc_sync_sgl() (fails in f/lpage, but sgl->sgl != NULL and f/lpage maybe also != NULL) -> ddcb_cmd_cleanup() -> genwqe_free_sync_sgl() (double free, because sgl->sgl != NULL and f/lpage maybe also != NULL) In this scenario we would have exactly the kind of double free that would explain the WARNING / Bad page state, and as expected it is caused by broken error handling (cleanup). Using the Ubuntu git source, tag Ubuntu-4.4.0-33.52, he was able to reproduce the "Bad page state" issue, and with the patch on top he could not reproduce it any more. ------------[ cut here ]------------ WARNING: at /build/linux-o03cxz/linux-4.4.0/arch/s390/include/asm/pci_dma.h:141 Modules linked in: qeth_l2 ghash_s390 prng aes_s390 des_s390 des_generic sha512_s390 sha256_s390 sha1_s390 sha_common genwqe_card qeth crc_itu_t qdio ccwgroup vmur dm_multipath dasd_eckd_mod dasd_mod CPU: 2 PID: 3293 Comm: genwqe_gunzip Not tainted 4.4.0-33-generic #52-Ubuntu task: 0000000032c7e270 ti: 00000000324e4000 task.ti: 00000000324e4000 Krnl PSW : 0404c00180000000 0000000000156346 (dma_update_cpu_trans+0x9e/0xa8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3 Krnl GPRS: 00000000324e7bcd 0000000000c3c34a 0000000027628298 000000003215b400 0000000000000400 0000000000001fff 0000000000000400 0000000116853000 07000000324e7b1e 0000000000000001 0000000000000001 0000000000000001 0000000000001000 0000000116854000 0000000000156402 00000000324e7a38 Krnl Code: 000000000015633a: 95001000 cli 0(%r1),0 000000000015633e: a774ffc3 brc 7,1562c4 #0000000000156342: a7f40001 brc 15,156344 >0000000000156346: 92011000 mvi 0(%r1),1 000000000015634a: a7f4ffbd brc 15,1562c4 000000000015634e: 0707 bcr 0,%r7 0000000000156350: c00400000000 brcl 0,156350 0000000000156356: eb7ff0500024 stmg %r7,%r15,80(%r15) Call Trace: ([<00000000001563e0>] dma_update_trans+0x90/0x228) [<00000000001565dc>] s390_dma_unmap_pages+0x64/0x160 [<00000000001567c2>] s390_dma_free+0x62/0x98 [<000003ff801310ce>] __genwqe_free_consistent+0x56/0x70 [genwqe_card] [<000003ff801316d0>] genwqe_free_sync_sgl+0xf8/0x160 [genwqe_card] [<000003ff8012bd6e>] ddcb_cmd_cleanup+0x86/0xa8 [genwqe_card] [<000003ff8012c1c0>] do_execute_ddcb+0x110/0x348 [genwqe_card] [<000003ff8012c914>] genwqe_ioctl+0x51c/0xc20 [genwqe_card] [<000000000032513a>] do_vfs_ioctl+0x3b2/0x518 [<0000000000325344>] SyS_ioctl+0xa4/0xb8 [<00000000007b86c6>] system_call+0xd6/0x264 [<000003ff9e8e520a>] 0x3ff9e8e520a Last Breaking-Event-Address: [<0000000000156342>] dma_update_cpu_trans+0x9a/0xa8 ---[ end trace 35996336235145c8 ]--- BUG: Bad page state in process jbd2/dasdb1-8 pfn:3215b page:000003d100c856c0 count:-1 mapcount:0 mapping: (null) index:0x0 flags: 0x3fffc0000000000() page dumped because: nonzero _count Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
Frank Haverkamp <haver@linux.vnet.ibm.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Andy Whitcroft <andy.whitcroft@canonical.com>
-
Dan Carpenter authored
We need to put an upper bound on "user_len" so the memcpy() doesn't overflow. Cc: <stable@vger.kernel.org> Reported-by:
Marco Grassi <marco.gra@gmail.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> CVE-2016-7425 (cherry picked from commit 7bc2b55a) Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1634705Signed-off-by:
Colin King <colin.king@canonical.com> Acked-by:
-
Alex Hung authored
Some system supports hybrid graphics and its discrete VGA does not have any connectors and therefore has no _DOD method. BugLink: http://bugs.launchpad.net/bugs/1634607Signed-off-by:
Alex Hung <alex.hung@canonical.com> Reviewed-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> (cherry picked from commit e34fbbac) Signed-off-by:
-
Ethan Hsieh authored
BugLink: http://bugs.launchpad.net/bugs/1634380 Move usb_autopm_get_interface() ahead of setup_on_usb() to prevent device from sending usb control message in usb suspend mode. The error message is as below: [ 83.944103] btusb 1-2:1.1: usb_suspend_interface: status 0 [ 83.944107] btusb 1-2:1.0: usb_suspend_interface: status 0 [ 83.960132] usb 1-2: usb auto-suspend, wakeup 0 [ 83.976156] usb 1-2: usb_suspend_device: status 0 [ 83.976162] usb 1-2: usb_suspend_both: status 0 [ 298.689106] Bluetooth: hci0 [ 298.689399] Bluetooth: hci0: Failed to access otp area (-113) Signed-off-by:
Ethan Hsieh <ethan.hsieh@canonical.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> (cherry picked from commit c7e163fe) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Wang, Rui Y authored
BugLink: http://bugs.launchpad.net/bugs/1633058 cryptd_create_hash() fails by returning -EINVAL. It is because after 8996eafd ("crypto: ahash - ensure statesize is non-zero") all ahash drivers must have a non-zero statesize. This patch fixes the problem by properly assigning the statesize. Signed-off-by:
Rui Wang <rui.y.wang@intel.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 1a078340) Signed-off-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by:
-
Wang, Rui Y authored
BugLink: http://bugs.launchpad.net/bugs/1633058 ghash_clmulni_intel fails to load on Linux 4.3+ with the following message: "modprobe: ERROR: could not insert 'ghash_clmulni_intel': Invalid argument" After 8996eafd ("crypto: ahash - ensure statesize is non-zero") all ahash drivers are required to implement import()/export(), and must have a non- zero statesize. This patch has been tested with the algif_hash interface. The calculated digest values, after several rounds of import()s and export()s, match those calculated by tcrypt. Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1634153Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 72fd50e1 upstream. The req_canceled() callback is used by tpm_transmit() periodically to check whether the request has been canceled while it is receiving a response from the TPM. The TPM_CRB_CTRL_CANCEL register was cleared already in the crb_cancel callback, which has two consequences: * Cancel might not happen. * req_canceled() always returns zero. A better place to clear the register is when starting to send a new command. The behavior of TPM_CRB_CTRL_CANCEL is described in the section 5.5.3.6 of the PTP specification. Fixes: 30fc8d13 ("tpm: TPM 2.0 CRB Interface") Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
-
Jarkko Sakkinen authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit d4816edf upstream. Unseal and load operations should be done as an atomic operation. This commit introduces unlocked tpm_transmit() so that tpm2_unseal_trusted() can do the locking by itself. Fixes: 0fe54803 ("keys, trusted: seal/unseal with TPM 2.0 chips") Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
-
Miklos Szeredi authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit e71b9dff upstream. Ima tries to call ->setxattr() on overlayfs dentry after having locked underlying inode, which results in a deadlock. Reported-by:
Krisztian Litkey <kli@iki.fi> Fixes: 4bacc9c9 ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay") Signed-off-by:
-
Christophe Jaillet authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit af48d7bc upstream. We know that 'ret = 0' because it has been tested a few lines above. So, if 'kzalloc' fails, 0 will be returned instead of an error code. Return -ENOMEM instead. Fixes: a0d46a3d ("ARM: cpuidle: Register per cpuidle device") Signed-off-by:
Christophe Jaillet <christophe.jaillet@wanadoo.fr> Acked-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
-
Linus Walleij authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit ca88696e upstream. The Qualcomm PMIC GPIO and MPP lines are problematic: the are fetched from the main MFD driver with platform_get_irq() which means that at this point they will all be assigned the flags set up for the interrupts in the device tree. That is problematic since these are flagged as rising edge and an this point the interrupt descriptor is assigned a rising edge, while the only thing the GPIO/MPP drivers really do is issue irq_get_irqchip_state() on the line to read it out and to provide a .to_irq() helper for *other* IRQ consumers. If another device tree node tries to flag the same IRQ for use as something else than rising edge, the kernel irqdomain core will protest like this: type mismatch, failed to map hwirq-NN for <FOO>! Which is what happens when the device tree defines two contradictory flags for the same interrupt line. To work around this and alleviate the problem, assign 0 as flag for the interrupts taken by the PM GPIO and MPP drivers. This will lead to the flag being unset, and a second consumer requesting rising, falling, both or level interrupts will be respected. This is what the qcom-pm*.dtsi files already do. Switched to using the symbolic name IRQ_TYPE_NONE so that we get this more readable. Fixes: bce36046 ("ARM: dts: apq8064: add pm8921 mpp support") Fixes: 874443fe ("ARM: dts: apq8064: Add pm8921 mfd and its gpio node") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Cc: Björn Andersson <bjorn.andersson@linaro.org> Cc: Ivan T. Ivanov <ivan.ivanov@linaro.org> Cc: John Stultz <john.stultz@linaro.org> Cc: Andy Gross <andy.gross@linaro.org> Signed-off-by:
Andy Gross <andy.gross@linaro.org> Signed-off-by:
-
Grzegorz Jaszczyk authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 061492cf upstream. The armada-390.dtsi was broken since the first patch which adds Device Tree files for Armada 39x SoC was introduced. Signed-off-by:
Grzegorz Jaszczyk <jaz@semihalf.com> Acked-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Fixes 538da83d ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board") Signed-off-by:
-
Josh Poimboeuf authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 72b4f6a5 upstream. On x86_32, when an interrupt happens from kernel space, SS and SP aren't pushed and the existing stack is used. So pt_regs is effectively two words shorter, and the previous stack pointer is normally the memory after the shortened pt_regs, aka '®s->sp'. But in the rare case where the interrupt hits right after the stack pointer has been changed to point to an empty stack, like for example when call_on_stack() is used, the address immediately after the shortened pt_regs is no longer on the stack. In that case, instead of '®s->sp', the previous stack pointer should be retrieved from the beginning of the current stack page. kernel_stack_pointer() wants to do that, but it forgets to dereference the pointer. So instead of returning a pointer to the previous stack, it returns a pointer to the beginning of the current stack. Note that it's probably outside of kernel_stack_pointer()'s scope to be switching stacks at all. The x86_64 version of this function doesn't do it, and it would be better for the caller to do it if necessary. But that's a patch for another day. This just fixes the original intent. Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Byungchul Park <byungchul.park@lge.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Kees Cook <keescook@chromium.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Nilay Vaish <nilayvaish@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 0788aa6a ("x86: Prepare removal of previous_esp from i386 thread_info structure") Link: http://lkml.kernel.org/r/472453d6e9f6a2d4ab16aaed4935f43117111566.1471535549.git.jpoimboe@redhat.comSigned-off-by:
-
Mika Westerberg authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit db91aa79 upstream. When a CPU is about to be offlined we call fixup_irqs() that resets IRQ affinities related to the CPU in question. The same thing is also done when the system is suspended to S-states like S3 (mem). For each IRQ we try to complete any on-going move regardless whether the IRQ is actually part of x86_vector_domain. For each IRQ descriptor we fetch its chip_data, assume it is of type struct apic_chip_data and manipulate it by clearing old_domain mask etc. For irq_chips that are not part of the x86_vector_domain, like those created by various GPIO drivers, will find their chip_data being changed unexpectly. Below is an example where GPIO chip owned by pinctrl-sunrisepoint.c gets corrupted after resume: # cat /sys/kernel/debug/gpio gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00: gpio-511 ( |sysfs ) in hi # rtcwake -s10 -mmem <10 seconds passes> # cat /sys/kernel/debug/gpio gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00: gpio-511 ( |sysfs ) in ? Note '?' in the output. It means the struct gpio_chip ->get function is NULL whereas before suspend it was there. Fix this by first checking that the IRQ belongs to x86_vector_domain before we try to use the chip_data as struct apic_chip_data. Reported-and-tested-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Dan Williams authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 917db484 upstream. In commit: ec776ef6 ("x86/mm: Add support for the non-standard protected e820 type") Christoph references the original patch I wrote implementing pmem support. The intent of the 'max_pfn' changes in that commit were to enable persistent memory ranges to be covered by the struct page memmap by default. However, that approach was abandoned when Christoph ported the patches [1], and that functionality has since been replaced by devm_memremap_pages(). In the meantime, this max_pfn manipulation is confusing kdump [2] that assumes that everything covered by the max_pfn is "System RAM". This results in kdump hanging or crashing. [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-March/000348.html [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1351098 So fix it. Reported-by:
Zhang Yi <yizhan@redhat.com> Reported-by:
Jeff Moyer <jmoyer@redhat.com> Tested-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit ac0e89bb upstream. We use logical negate where bitwise negate was intended. It means that we never return -EINVAL here. Fixes: ce11e48b ('KVM: PPC: E500: Add userspace debug stub support') Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 91e4f1b6 upstream. When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate TLB entries on the local CPU. This doesn't work correctly on an SMP host when the guest is migrated to a different physical CPU, as it could pick up stale TLB mappings from the last time the vCPU ran on that physical CPU. Therefore invalidate both user and kernel host ASIDs on other CPUs, which will cause new ASIDs to be generated when it next runs on those CPUs. We're careful only to do this if the TLB entry was already valid, and only for the kernel ASID where the virtual address it mapped is outside of the guest user address range. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: kvm@vger.kernel.org Signed-off-by:
-
Thomas Huth authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit fa73c3b2 upstream. The MMCR2 register is available twice, one time with number 785 (privileged access), and one time with number 769 (unprivileged, but it can be disabled completely). In former times, the Linux kernel was using the unprivileged register 769 only, but since commit 8dd75ccb ("powerpc: Use privileged SPR number for MMCR2"), it uses the privileged register 785 instead. The KVM-PR code then of course also switched to use the SPR 785, but this is causing older guest kernels to crash, since these kernels still access 769 instead. So to support older kernels with KVM-PR again, we have to support register 769 in KVM-PR, too. Fixes: 8dd75ccbSigned-off-by:
Thomas Huth <thuth@redhat.com> Signed-off-by:
-
Uwe Kleine-König authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 88003fb1 upstream. This fixes a compile failure: drivers/built-in.o: In function `wm8350_i2c_probe': core.c:(.text+0x828b0): undefined reference to `__devm_regmap_init_i2c' Makefile:953: recipe for target 'vmlinux' failed Fixes: 52b461b8 ("mfd: Add regmap cache support for wm8350") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: http://bugs.launchpad.net/bugs/1634153 commit 9a6dc644 upstream. set_bit() and clear_bit() take the bit number so this code is really doing "1 << (1 << irq)" which is a double shift bug. It's done consistently so it won't cause a problem unless "irq" is more than 4. Fixes: 70c6cce0 ('mfd: Support 88pm80x in 80x driver') Signed-off-by:
-
