- 21 Dec, 2019 40 commits
-
-
Thomas Zimmermann authored
commit d6d437d9 upstream. The flags field in struct mga_device has been unused so far. We now use it to store flag bits from the PCI driver. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 81da87f6 ("drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin") Cc: John Donnelly <john.p.donnelly@oracle.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: David Airlie <airlied@linux.ie> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: "Y.C. Chen" <yc_chen@aspeedtech.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: "José Roberto de Souza" <jose.souza@intel.com> Cc: Andrzej Pietrasiewicz <andrzej.p@collabora.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.3+ Link: https://patchwork.freedesktop.org/patch/msgid/20191126101529.20356-3-tzimmermann@suse.de Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Thomas Zimmermann authored
commit 3a8a5aba upstream. Adds a conversion function that extracts the device type from the PCI id-table flags. Allows for storing additional information in the other flag bits. Signed-off-by:
-
Boris Brezillon authored
commit aed44cbe upstream. panfrost_gem_shrinker_scan() might purge a BO (release the sgt and kill the GPU mapping) that's being freed by panfrost_gem_free_object() if we don't remove the BO from the shrinker list at the beginning of panfrost_gem_free_object(). Fixes: 013b6510 ("drm/panfrost: Add madvise and shrinker support") Cc: <stable@vger.kernel.org> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Acked-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-5-boris.brezillon@collabora.com Signed-off-by:
-
Boris Brezillon authored
commit 3bb69dbc upstream. We should release the reference we grabbed when an error occurs. Fixes: 187d2929 ("drm/panfrost: Add support for GPU heap allocations") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Boris Brezillon authored
commit 70cc7795 upstream. If 2 threads change the MADVISE property of the same BO in parallel we might end up with an shmem->madv value that's inconsistent with the presence of the BO in the shrinker list. The easiest solution to fix that is to protect the drm_gem_shmem_madvise() call with the shrinker lock. Fixes: 013b6510 ("drm/panfrost: Add madvise and shrinker support") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Navid Emamdoost authored
commit 6645d42d upstream. In the implementation of sync_file_merge() the allocated sync_file is leaked if number of fences overflows. Release sync_file by goto err. Fixes: a02b9dc9 ("dma-buf/sync_file: refactor fence storage in struct sync_file") Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Jiang Yi authored
commit d567fb88 upstream. Since irq_bypass_register_producer() is called after request_irq(), we should do tear-down in reverse order: irq_bypass_unregister_producer() then free_irq(). Specifically free_irq() may release resources required by the irqbypass del_producer() callback. Notably an example provided by Marc Zyngier on arm64 with GICv4 that he indicates has the potential to wedge the hardware: free_irq(irq) __free_irq(irq) irq_domain_deactivate_irq(irq) its_irq_domain_deactivate() [unmap the VLPI from the ITS] kvm_arch_irq_bypass_del_producer(cons, prod) kvm_vgic_v4_unset_forwarding(kvm, irq, ...) its_unmap_vlpi(irq) [Unmap the VLPI from the ITS (again), remap the original LPI] Signed-off-by:
Jiang Yi <giangyi@amazon.com> Cc: stable@vger.kernel.org # v4.4+ Fixes: 6d7425f1 ("vfio: Register/unregister irq_bypass_producer") Link: https://lore.kernel.org/kvm/20191127164910.15888-1-giangyi@amazon.com Reviewed-by:
Marc Zyngier <maz@kernel.org> Reviewed-by:
Eric Auger <eric.auger@redhat.com> [aw: commit log] Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Dmitry Osipenko authored
commit d70f7d31 upstream. There is an unfortunate typo in the code that results in writing to FLOW_CTLR_HALT instead of FLOW_CTLR_CSR. Cc: <stable@vger.kernel.org> Acked-by:
Peter De Schrijver <pdeschrijver@nvidia.com> Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Lihua Yao authored
commit d60d0cff upstream. fin_pll is the parent of clock-controller@7e00f000, specify the dependency to ensure proper initialization order of clock providers. without this patch: [ 0.000000] S3C6410 clocks: apll = 0, mpll = 0 [ 0.000000] epll = 0, arm_clk = 0 with this patch: [ 0.000000] S3C6410 clocks: apll = 532000000, mpll = 532000000 [ 0.000000] epll = 24000000, arm_clk = 532000000 Cc: <stable@vger.kernel.org> Fixes: 3f6d439f ("clk: reverse default clk provider initialization order in of_clk_init()") Signed-off-by:
Lihua Yao <ylhuajnu@outlook.com> Reviewed-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Paulo Alcantara (SUSE) authored
commit 5bb30a4d upstream. Make sure that DFS referrals are sent to newly resolved root targets as in a multi tier DFS setup. Signed-off-by:
Paulo Alcantara (SUSE) <pc@cjr.nz> Link: https://lkml.kernel.org/r/05aa2995-e85e-0ff4-d003-5bb08bd17a22@canonical.com Cc: stable@vger.kernel.org Tested-by:
Matthew Ruffell <matthew.ruffell@canonical.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Pavel Shilovsky authored
commit 86a7964b upstream. There is a race between a system call processing thread and the demultiplex thread when mid->resp_buf becomes NULL and later is being accessed to get credits. It happens when the 1st thread wakes up before a mid callback is called in the 2nd one but the mid state has already been set to MID_RESPONSE_RECEIVED. This causes NULL pointer dereference in mid callback. Fix this by saving credits from the response before we update the mid state and then use this value in the mid callback rather then accessing a response buffer. Cc: Stable <stable@vger.kernel.org> Fixes: ee258d79 ("CIFS: Move credit processing to mid callbacks for SMB3") Tested-by:
Frank Sorenson <sorenson@redhat.com> Reviewed-by:
Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
-
Pavel Shilovsky authored
commit 7b71843f upstream. When an OPEN command is cancelled we mark a mid as cancelled and let the demultiplex thread process it by closing an open handle. The problem is there is a race between a system call thread and the demultiplex thread and there may be a situation when the mid has been already processed before it is set as cancelled. Fix this by processing cancelled requests when mids are being destroyed which means that there is only one thread referencing a particular mid. Also set mids as cancelled unconditionally on their state. Cc: Stable <stable@vger.kernel.org> Tested-by:
-
Pavel Shilovsky authored
commit 9150c3ad upstream. If Close command is interrupted before sending a request to the server the client ends up leaking an open file handle. This wastes server resources and can potentially block applications that try to remove the file or any directory containing this file. Fix this by putting the close command into a worker queue, so another thread retries it later. Cc: Stable <stable@vger.kernel.org> Tested-by:
-
Pavel Shilovsky authored
commit 44805b0e upstream. Currently the client translates O_SYNC and O_DIRECT flags into corresponding SMB create options when openning a file. The problem is that on reconnect when the file is being re-opened the client doesn't set those flags and it causes a server to reject re-open requests because create options don't match. The latter means that any subsequent system call against that open file fail until a share is re-mounted. Fix this by properly setting SMB create options when re-openning files after reconnects. Fixes: 1013e760 : ("SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags") Cc: Stable <stable@vger.kernel.org> Signed-off-by:
-
Long Li authored
commit 14cc639c upstream. On reconnect, the transport data structure is NULL and its information is not available. Signed-off-by:
Long Li <longli@microsoft.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Long Li authored
commit acd4680e upstream. The transport should return this error so the upper layer will reconnect. Signed-off-by:
-
Long Li authored
commit 37941ea1 upstream. While it's not friendly to fail user processes that issue more iovs than we support, at least we should return the correct error code so the user process gets a chance to retry with smaller number of iovs. Signed-off-by:
-
Long Li authored
commit d63cdbae upstream. Log these activities to help production support. Signed-off-by:
-
Long Li authored
commit c21ce58e upstream. It's not necessary to queue invalidated memory registration to work queue, as all we need to do is to unmap the SG and make it usable again. This can save CPU cycles in normal data paths as memory registration errors are rare and normally only happens during reconnection. Signed-off-by:
-
Long Li authored
commit 4357d45f upstream. During reconnecting, the transport may have already been destroyed and is in the process being reconnected. In this case, return -EAGAIN to not fail and to retry this I/O. Signed-off-by:
-
Bjorn Andersson authored
commit 278bcb73 upstream. By just cancelling the deferred rx worker during GLINK instance teardown any pending deferred commands are leaked, so free them. Fixes: b4f8e52b ("rpmsg: Introduce Qualcomm RPM glink driver") Cc: stable@vger.kernel.org Acked-by:
Chris Lew <clew@codeaurora.org> Tested-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Bjorn Andersson authored
commit c3dadc19 upstream. Attempting to transmit rx_done messages after the GLINK instance is being torn down will cause use after free and memory leaks. So cancel the intent_work and free up the pending intents. With this there are no concurrent accessors of the channel left during qcom_glink_native_remove() and there is therefor no need to hold the spinlock during this operation - which would prohibit the use of cancel_work_sync() in the release function. So remove this. Fixes: 1d2ea36e ("rpmsg: glink: Add rx done command") Cc: stable@vger.kernel.org Acked-by:
-
Chris Lew authored
commit f7e71498 upstream. The device release function is set before registering with rpmsg. If rpmsg registration fails, the framework will call device_put(), which invokes the release function. The channel create logic does not need to free rpdev if rpmsg_register_device() fails and release is called. Fixes: b4f8e52b ("rpmsg: Introduce Qualcomm RPM glink driver") Cc: stable@vger.kernel.org Tested-by:
-
Chris Lew authored
commit b646293e upstream. In a remote processor crash scenario, there is no guarantee the remote processor sent close requests before it went into a bad state. Remove the reference that is normally handled by the close command in the so channel resources can be released. Fixes: b4f8e52b ("rpmsg: Introduce Qualcomm RPM glink driver") Cc: stable@vger.kernel.org Tested-by:
-
Arun Kumar Neelakantam authored
commit ac74ea01 upstream. Extra channel reference put when remote sending OPEN_ACK after timeout causes use-after-free while handling next remote CLOSE command. Remove extra reference put in timeout case to avoid use-after-free. Fixes: b4f8e52b ("rpmsg: Introduce Qualcomm RPM glink driver") Cc: stable@vger.kernel.org Tested-by:
Arun Kumar Neelakantam <aneela@codeaurora.org> Signed-off-by:
-
Arun Kumar Neelakantam authored
commit b85f6b60 upstream. Memory allocated for re-usable intents are not freed during channel cleanup which causes memory leak in system. Check and free all re-usable memory to avoid memory leak. Fixes: 933b45da ("rpmsg: glink: Add support for TX intents") Cc: stable@vger.kernel.org Acked-By:
-
Chris Lew authored
commit 4623e8bf upstream. When wrapping around the FIFO, the remote expects the tail pointer to be reset to 0 on the edge case where the tail equals the FIFO length. Fixes: caf989c3 ("rpmsg: glink: Introduce glink smem based transport") Cc: stable@vger.kernel.org Signed-off-by:
-
Max Filippov authored
commit c2d9aa3b upstream. syscall return value is in the register a2, not a0. Cc: stable@vger.kernel.org # v5.0+ Fixes: 9f24f3c1 ("xtensa: implement tracehook functions and enable HAVE_ARCH_TRACEHOOK") Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Max Filippov authored
commit 36de10c4 upstream. Virtual and translated addresses retrieved by the xtensa TLB sanity checker must be consistent, i.e. correspond to the same state of the checked TLB entry. KASAN shadow memory is mapped dynamically using auto-refill TLB entries and thus may change TLB state between the virtual and translated address retrieval, resulting in false TLB insanity report. Move read_xtlb_translation close to read_xtlb_virtual to make sure that read values are consistent. Cc: stable@vger.kernel.org Fixes: a99e07ee ("xtensa: check TLB sanity on return to userspace") Signed-off-by:
-
Bob Peterson authored
commit fe5e7ba1 upstream. Commit 9287c645 fixed a situation in which gfs2 could use a glock after it had been freed. To do that, it temporarily added a new glock reference by calling gfs2_glock_hold in function gfs2_add_revoke. However, if the bd element was removed by gfs2_trans_remove_revoke, it failed to drop the additional reference. This patch adds logic to gfs2_trans_remove_revoke to properly drop the additional glock reference. Fixes: 9287c645 ("gfs2: Fix occasional glock use-after-free") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
-
Andreas Gruenbacher authored
commit f53056c4 upstream. In gfs2_page_mkwrite's gfs2_allocate_page_backing helper, try to allocate as many blocks at once as we need. Pass in the size of the requested allocation. Fixes: 35af80ae ("gfs2: don't use buffer_heads in gfs2_allocate_page_backing") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by:
-
Max Filippov authored
commit e64681b4 upstream. KASAN shadow map doesn't need to be accessible through the linear kernel mapping, allocate its pages with MEMBLOCK_ALLOC_ANYWHERE so that high memory can be used. This frees up to ~100MB of low memory on xtensa configurations with KASAN and high memory. Cc: stable@vger.kernel.org # v5.1+ Fixes: f240ec09 ("memblock: replace memblock_alloc_base(ANYWHERE) with memblock_phys_alloc") Reviewed-by:
Mike Rapoport <rppt@linux.ibm.com> Signed-off-by:
-
Andreas Gruenbacher authored
commit cc90bc68 upstream. This partially reverts commit e3a5d8e3. Commit e3a5d8e3 ("check bi_size overflow before merge") adds a bio_full check to __bio_try_merge_page. This will cause __bio_try_merge_page to fail when the last bi_io_vec has been reached. Instead, what we want here is only the bi_size overflow check. Fixes: e3a5d8e3 ("block: check bi_size overflow before merge") Cc: stable@vger.kernel.org # v5.4+ Reviewed-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Leonard Crestez authored
commit c6a3aea9 upstream. QOS requests for DEFAULT_VALUE are supposed to be ignored but this is not the case for FREQ_QOS_MAX. Adding one request for MAX_DEFAULT_VALUE and one for a real value will cause freq_qos_read_value to unexpectedly return MAX_DEFAULT_VALUE (-1). This happens because freq_qos max value is aggregated with PM_QOS_MIN but FREQ_QOS_MAX_DEFAULT_VALUE is (-1) so it's smaller than other values. Fix this by redefining FREQ_QOS_MAX_DEFAULT_VALUE to S32_MAX. Looking at current users for freq_qos it seems that none of them create requests for FREQ_QOS_MAX_DEFAULT_VALUE. Fixes: 77751a46 ("PM: QoS: Introduce frequency QoS") Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Reported-by:
Matthias Kaehlcke <mka@chromium.org> Reviewed-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
George Cherian authored
commit f338bb9f upstream. Enhance the ACS quirk for Cavium Processors. Add the root port vendor IDs for ThunderX2 and ThunderX3 series of processors. [bhelgaas: add Fixes: and stable tag] Fixes: f2ddaf8d ("PCI: Apply Cavium ThunderX ACS quirk to more Root Ports") Link: https://lore.kernel.org/r/20191111024243.GA11408@dc5-eodlnx05.marvell.com Signed-off-by:
George Cherian <george.cherian@marvell.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Robert Richter <rrichter@marvell.com> Cc: stable@vger.kernel.org # v4.12+ Signed-off-by:
-
Yoshihiro Shimoda authored
commit 7c7e53e1 upstream. The R-Car Gen2/3 manual - available at: https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rz/rzg/rzg1m.html#documents "RZ/G Series User's Manual: Hardware" section strictly enforces the MACCTLR inizialization value - 39.3.1 - "Initial Setting of PCI Express": "Be sure to write the initial value (= H'80FF 0000) to MACCTLR before enabling PCIETCTLR.CFINIT". To avoid unexpected behavior and to match the SW initialization sequence guidelines, this patch programs the MACCTLR with the correct value. Note that the MACCTLR.SPCHG bit in the MACCTLR register description reports that "Only writing 1 is valid and writing 0 is invalid" but this "invalid" has to be interpreted as a write-ignore aka "ignored", not "prohibited". Reported-by:
Eugeniu Rosca <erosca@de.adit-jv.com> Fixes: c25da477 ("PCI: rcar: Add Renesas R-Car PCIe driver") Fixes: be20bbcb ("PCI: rcar: Add the initialization of PCIe link in resume_noirq()") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Cc: <stable@vger.kernel.org> # v5.2+ Signed-off-by:
-
Subbaraya Sundeep authored
commit 73884a70 upstream. As per PCIe r5.0, sec 7.8.5.2, fixed bus numbers of a bridge must be zero when no function that uses EA is located behind it. Hence, if EA supplies bus numbers of zero, assign bus numbers normally. A secondary bus can never have a bus number of zero, so setting a bridge's Secondary Bus Number to zero makes downstream devices unreachable. [bhelgaas: retain bool return value so "zero is invalid" logic is local] Fixes: 2dbce590 ("PCI: Assign bus numbers present in EA capability for bridges") Link: https://lore.kernel.org/r/1572850664-9861-1-git-send-email-sundeep.lkml@gmail.com Signed-off-by:
Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
-
Jian-Hong Pan authored
commit e045fa29 upstream. When a driver enables MSI-X, msix_program_entries() reads the MSI-X Vector Control register for each vector and saves it in desc->masked. Each register is 32 bits and bit 0 is the actual Mask bit. When we restored these registers during resume, we previously set the Mask bit if *any* bit in desc->masked was set instead of when the Mask bit itself was set: pci_restore_state pci_restore_msi_state __pci_restore_msix_state for_each_pci_msi_entry msix_mask_irq(entry, entry->masked) <-- entire u32 word __pci_msix_desc_mask_irq(desc, flag) mask_bits = desc->masked & ~PCI_MSIX_ENTRY_CTRL_MASKBIT if (flag) <-- testing entire u32, not just bit 0 mask_bits |= PCI_MSIX_ENTRY_CTRL_MASKBIT writel(mask_bits, desc_addr + PCI_MSIX_ENTRY_VECTOR_CTRL) This means that after resume, MSI-X vectors were masked when they shouldn't be, which leads to timeouts like this: nvme nvme0: I/O 978 QID 3 timeout, completion polled On resume, set the Mask bit only when the saved Mask bit from suspend was set. This should remove the need for 19ea025e ("nvme: Add quirk for Kingston NVME SSD running FW E8FK11.T"). [bhelgaas: commit log, move fix to __pci_msix_desc_mask_irq()] Link: https://bugzilla.kernel.org/show_bug.cgi?id=204887 Link: https://lore.kernel.org/r/20191008034238.2503-1-jian-hong@endlessm.com Fixes: f2440d9a ("PCI MSI: Refactor interrupt masking code") Signed-off-by:
Jian-Hong Pan <jian-hong@endlessm.com> Signed-off-by:
-
Steffen Liebergeld authored
commit d8558ac8 upstream. According to documentation [0] the correct offset for the Upstream Peer Decode Configuration Register (UPDCR) is 0x1014. It was previously defined as 0x1114. d99321b6 ("PCI: Enable quirks for PCIe ACS on Intel PCH root ports") intended to enforce isolation between PCI devices allowing them to be put into separate IOMMU groups. Due to the wrong register offset the intended isolation was not fully enforced. This is fixed with this patch. Please note that I did not test this patch because I have no hardware that implements this register. [0] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/4th-gen-core-family-mobile-i-o-datasheet.pdf (page 325) Fixes: d99321b6 ("PCI: Enable quirks for PCIe ACS on Intel PCH root ports") Link: https://lore.kernel.org/r/7a3505df-79ba-8a28-464c-88b83eefffa6@kernkonzept.com Signed-off-by:
Steffen Liebergeld <steffen.liebergeld@kernkonzept.com> Signed-off-by:
Andrew Murray <andrew.murray@arm.com> Acked-by:
Ashok Raj <ashok.raj@intel.com> Cc: stable@vger.kernel.org # v3.15+ Signed-off-by:
-
Lukas Wunner authored
commit 157c1062 upstream. A sysfs request to enable or disable a PCIe hotplug slot should not return before it has been carried out. That is sought to be achieved by waiting until the controller's "pending_events" have been cleared. However the IRQ thread pciehp_ist() clears the "pending_events" before it acts on them. If pciehp_sysfs_enable_slot() / _disable_slot() happen to check the "pending_events" after they have been cleared but while pciehp_ist() is still running, the functions may return prematurely with an incorrect return value. Fix by introducing an "ist_running" flag which must be false before a sysfs request is allowed to return. Fixes: 32a8cef2 ("PCI: pciehp: Enable/disable exclusively from IRQ thread") Link: https://lore.kernel.org/linux-pci/1562226638-54134-1-git-send-email-wangxiongfeng2@huawei.com Link: https://lore.kernel.org/r/4174210466e27eb7e2243dd1d801d5f75baaffd8.1565345211.git.lukas@wunner.de Reported-and-tested-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
