- 06 Apr, 2016 40 commits
-
-
Sebastian Ott authored
BugLink: http://bugs.launchpad.net/bugs/1558625 The function measurement block must not cross a page boundary. Ensure that by raising the alignment requirement to the smallest power of 2 larger than the size of the fmb. Fixes: d0b08853 ("s390/pci: performance statistics and debug infrastructure") Cc: stable@vger.kernel.org # v3.8+ Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> (cherry picked from commit 80c544de) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Martin Schwidefsky authored
BugLink: http://bugs.launchpad.net/bugs/1558624 Provide a user space interface to issue call logical-processor instructions. Only selected CLP commands are allowed, enough to get the full overview of the installed PCI functions. Reviewed-by:
-
Sebastian Ott authored
BugLink: http://bugs.launchpad.net/bugs/1558624 For each PCI function we need to maintain arch specific data in struct zpci_dev which also contains a pointer to struct pci_dev. When a function is registered or deregistered (which is triggered by PCI common code) we need to adjust that pointer which could interfere with the machine check handler (triggered by FW) using zpci_dev->pdev. Since multiple instances of the same pdev could exist at a time this can't be solved with locking. Fix that by ditching the pdev pointer and use a bus walk to reach struct pci_dev (only one instance of a pdev can be registered at the bus at a time). Signed-off-by:
Gerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by:
-
Sebastian Ott authored
BugLink: http://bugs.launchpad.net/bugs/1558624 Since each iomap_entry handles only one bar of one pci function (even when disjunct ranges of a bar are mapped) the sanity check in pci_iomap_range is not needed and can be removed. Also convert the remaining BUG_ONs to WARN_ONs. Signed-off-by:
-
Sebastian Ott authored
BugLink: http://bugs.launchpad.net/bugs/1558624 We receive special notifications from firmware when an error was detected and a pci function became unusable. Set the error_state accordingly to give device drivers a hint that they don't need to try error recovery. Suggested-by:
Alexander Schmidt <alexschm@de.ibm.com> Signed-off-by:
-
Sebastian Ott authored
BugLink: http://bugs.launchpad.net/bugs/1558624 Fix the check which bar space we should map to allow available bars only. Signed-off-by:
-
Sebastian Ott authored
BugLink: http://bugs.launchpad.net/bugs/1558624 On s390 we need to maintain a mapping between iomem addresses and arch specific function identifiers. Currently the mapping table is created as such that we could span the whole iomem address space. Since we can only map each bar space from each possible function we have an upper bound for the number of mapping entries. This reduces the size of the iomap from 256K to less than 4K (using the defconfig). Signed-off-by:
-
Sebastian Ott authored
BugLink: http://bugs.launchpad.net/bugs/1558624 Most of the constants defined in pci_io.h depend on each other and thus can be calculated. Signed-off-by:
-
Sebastian Ott authored
BugLink: http://bugs.launchpad.net/bugs/1558624 Provide and use a ZPCI_ADDR macro as the complement of ZPCI_IDX to get rid of some constants in the code. Signed-off-by:
-
Al Viro authored
BugLink: http://bugs.launchpad.net/bugs/1558624Acked-by:
Al Viro <viro@zeniv.linux.org.uk> (cherry picked from commit bdb97e91) Signed-off-by:
-
Gerald Schaefer authored
BugLink: http://bugs.launchpad.net/bugs/1558624 DMA addresses returned from map_page() are calculated by using an iommu bitmap plus a start_dma offset. The size of this bitmap is based on the main memory size. If we have more than (4 TB - start_dma) main memory, the DMA address calculation will also produce addresses > 4 TB. Such addresses cannot be inserted in the 3-level DMA page table, instead the entries modulo 4 TB will be overwritten. Fix this by restricting the iommu bitmap size to (4 TB - start_dma). Also set zdev->end_dma to the actual end address of the usable range, instead of the theoretical maximum as reported by the hardware, which fixes a sanity check in dma_map() and also the IOMMU API domain geometry aperture calculation. Signed-off-by:
-
Mehmet Kayaalp authored
BugLink: http://bugs.launchpad.net/bugs/1558553 The config option SYSTEM_EXTRA_CERTIFICATE reserves space in vmlinux file, which is compressed to create the self-extracting bzImage. This patch adds the capability of extracting the vmlinux, inserting the certificate, and repackaging the result into a bzImage. It only works if the resulting compressed vmlinux is smaller than the original. Otherwise re-linking would be required. To make the reserved space allocate actual space in bzImage, a null key is inserted into vmlinux before creating the bzImage: make vmlinux scripts/insert-sys-cert -b vmlinux -c /dev/null make bzImage After null key insertion, the script populates the rest of the reserved space with random bytes, which have poor compression. After receiving a bzImage that is created this way, actual certificate can be inserted into the bzImage: scripts/insert-sys-cert -s <System.map> -z <bzImage> -c <certfile> Signed-off-by:
Mehmet Kayaalp <mkayaalp@linux.vnet.ibm.com> Signed-off-by:
-
Mehmet Kayaalp authored
BugLink: http://bugs.launchpad.net/bugs/1558553 Place a system_extra_cert buffer of configurable size, right after the system_certificate_list, so that inserted keys can be readily processed by the existing mechanism. Added script takes a key file and a kernel image and inserts its contents to the reserved area. The system_certificate_list_size is also adjusted accordingly. Call the script as: scripts/insert-sys-cert -b <vmlinux> -c <certfile> If vmlinux has no symbol table, supply System.map file with -s flag. Subsequent runs replace the previously inserted key, instead of appending the new one. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> (cherry picked from commit c4c36105) Signed-off-by:
-
Mehmet Kayaalp authored
BugLink: http://bugs.launchpad.net/bugs/1558553 When a certificate is inserted to the image using scripts/writekey, the value of __cert_list_end does not change. The updated size can be found out by reading the value pointed by the system_certificate_list_size symbol. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1558553Signed-off-by:
-
Hannes Frederic Sowa authored
BugLink: http://bugs.launchpad.net/bugs/1558025 Otherwise we break the contract with GSO to only pass CHECKSUM_PARTIAL skbs down. This can easily happen with UDP+IPv4 sockets with the first MSG_MORE write smaller than the MTU, second write is a sendfile. Returning -EOPNOTSUPP lets the callers fall back into normal sendmsg path, were we calculate the checksum manually during copying. Commit d749c9cb ("ipv4: no CHECKSUM_PARTIAL on MSG_MORE corked sockets") started to exposes this bug. Fixes: d749c9cb ("ipv4: no CHECKSUM_PARTIAL on MSG_MORE corked sockets") Reported-by:
Jiri Benc <jbenc@redhat.com> Cc: Jiri Benc <jbenc@redhat.com> Reported-by:
Wakko Warner <wakko@animx.eu.org> Cc: Wakko Warner <wakko@animx.eu.org> Signed-off-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit a8c4a252) Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1558342 The cavium,pci-thunder-ecam devices are exactly ECAM-based PCI root complexes. These root complexes (loosely referred to as ECAM units in the hardware manuals) are used to access the Thunder on-chip devices. They are special in that all the BARs on devices behind these root complexes are at fixed addresses. Add a driver for these devices that synthesizes Enhanced Allocation (EA) capability entries for each BAR. Since this EA synthesis is needed for exactly two chip models, we can hard- code some assumptions about the device topology and the layout of the config space of specific DEVFNs in the driver. [bhelgaas: changelog, whitespace] Signed-off-by:
David Daney <david.daney@cavium.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Rob Herring <robh@kernel.org> (cherry picked from linux-next commit 7b6e7ba8) [dannf: offset fixups to apply to v4.4] Signed-off-by:
dann frazier <dann.frazier@canonical.com>
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1558342 The root complexes used to access off-chip PCIe devices (called PEM units in the hardware manuals) on some Cavium ThunderX processors require quirky access methods for the config space of the PCIe bridge. Add a driver to provide these config space accessor functions. Use the pci-host-common code to configure the PCI machinery. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> (cherry picked from linux-next commit f12b76e5) [dannf: offset fixups to apply to v4.4] Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1558342 Move pci_host_common_probe() and associated functions to pci-host-common.c, where it can be shared with other drivers. Make it public (not static) and update Kconfig and Makefile to build it. No functional change intended. [bhelgaas: split into separate patch, changelog] Signed-off-by:
Will Deacon <will.deacon@arm.com> (cherry picked from linux-next commit 4e64dbe2) Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1558342 Factor gen_pci_probe(), moving most of it into pci_host_common_probe() where it can be shared with other drivers that have slightly different config accessors. No functional change intended. [bhelgaas: split into separate patch, changelog] Signed-off-by:
-
David Daney authored
BugLink: http://bugs.launchpad.net/bugs/1558342 Move definitions for generic PCI host controller driver structures to a separate header file so we can share them with other drivers. No functional change intended. [bhelgaas: split into separate patch, changelog] Signed-off-by:
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1558342Signed-off-by:
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1558342Signed-off-by:
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1558342Signed-off-by:
-
Joseph Salisbury authored
BugLink: http://bugs.launchpad.net/bugs/1556264 This patch has been submitted upstream, but has not landed in the mainline tree as of yet. On the consumer side, we have interrupt driven flow management of the producer. It is sufficient to base the signalling decision on the amount of space that is available to write after the read is complete. The current code samples the previous available space and uses this in making the signalling decision. This state can be stale and is unnecessary. Since the state can be stale, we end up not signalling the host (when we should) and this can result in a hang. Fix this problem by removing the unnecessary check. I would like to thank Arseney Romanenko <arseneyr@microsoft.com> for pointing out this bug. OriginalAuthor: kys@microsoft.com Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1558330Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit 4b7b1ef2 upstream. The ld-version.sh script fails on some versions of awk with the following error, resulting in build failures for MIPS: awk: scripts/ld-version.sh: line 4: regular expression compile failed (missing '(') This is due to the regular expression ".*)", meant to strip off the beginning of the ld version string up to the close bracket, however brackets have a meaning in regular expressions, so lets escape it so that awk doesn't expect a corresponding open bracket. Fixes: ccbef167 ("Kbuild, lto: add ld-version and ld-ifversion ...") Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
James Hogan <james.hogan@imgtec.com> Tested-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Cc: Michal Marek <mmarek@suse.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-mips@linux-mips.org Cc: linux-kbuild@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12838/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Nicholas Bellinger authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit 7f54ab5f upstream. This patch fixes a recent ABORT_TASK regression associated with commit febe562c, where a left-over target_put_sess_cmd() would still be called when __target_check_io_state() detected a command has already been completed, and explicit ABORT must be avoided. Note commit febe562c dropped the local kref_get_unless_zero() check in core_tmr_abort_task(), but did not drop this extra corresponding target_put_sess_cmd() in the failure path. So go ahead and drop this now bogus target_put_sess_cmd(), and avoid this potential use-after-free. Reported-by:
Dan Lane <dracodan@gmail.com> Cc: Quinn Tran <quinn.tran@qlogic.com> Cc: Himanshu Madhani <himanshu.madhani@qlogic.com> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.de> Cc: Andy Grover <agrover@redhat.com> Cc: Mike Christie <mchristi@redhat.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Ming Lei authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit 90d0f0f1 upstream. For !BIO_CLONED bio, we can use .bi_vcnt safely, but it doesn't mean we can just simply return .bi_io_vec[.bi_vcnt - 1] because the start postion may have been moved in the middle of the bvec, such as splitting in the middle of bvec. Fixes: 7bcd79ac(block: bio: introduce helpers to get the 1st and last bvec) Reported-by:
Kent Overstreet <kent.overstreet@gmail.com> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit d825c06b upstream. When calculate_cpu_foreign_map() recalculates the cpu_foreign_map cpumask it uses the local variable temp_foreign_map without initialising it to zero. Since the calculation only ever sets bits in this cpumask any existing bits at that memory location will remain set and find their way into cpu_foreign_map too. This could potentially lead to cache operations suboptimally doing smp calls to multiple VPEs in the same core, even though the VPEs share primary caches. Therefore initialise temp_foreign_map using cpumask_clear() before use. Fixes: cccf34e9 ("MIPS: c-r4k: Fix cache flushing for MT cores") Signed-off-by:
-
Hauke Mehrtens authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit 7a50e468 upstream. The MIPS_GIC_IPI should only be selected when MIPS_GIC is also selected, otherwise it results in a compile error. smp-gic.c uses some functions from include/linux/irqchip/mips-gic.h like plat_ipi_call_int_xlate() which are only added to the header file when MIPS_GIC is set. The Lantiq SoC does not use the GIC, but supports SMP. The calls top the functions from smp-gic.c are already protected by some #ifdefs The first part of this was introduced in commit 72e20142 ("MIPS: Move GIC IPI functions out of smp-cmp.c") Signed-off-by:
Hauke Mehrtens <hauke@hauke-m.de> Cc: Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/12774/Signed-off-by:
-
Rui Wang authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit ce9113bb upstream. ovl_remove_upper() should do d_drop() only after it successfully removes the dir, otherwise a subsequent getcwd() system call will fail, breaking userspace programs. This is to fix: https://bugzilla.kernel.org/show_bug.cgi?id=110491Signed-off-by:
Rui Wang <rui.y.wang@intel.com> Reviewed-by:
Konstantin Khlebnikov <koct9i@gmail.com> Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Signed-off-by:
-
Linus Torvalds authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit 39680f50 upstream. The exit path will do some final updates to the VM of an exiting process to inform others of the fact that the process is going away. That happens, for example, for robust futex state cleanup, but also if the parent has asked for a TID update when the process exits (we clear the child tid field in user space). However, at the time we do those final VM accesses, we've already stopped accepting signals, so the usual "stop waiting for userfaults on signal" code in fs/userfaultfd.c no longer works, and the process can become an unkillable zombie waiting for something that will never happen. To solve this, just make handle_userfault() abort any user fault handling if we're already in the exit path past the signal handling state being dead (marked by PF_EXITING). This VM special case is pretty ugly, and it is possible that we should look at finalizing signals later (or move the VM final accesses earlier). But in the meantime this is a fairly minimally intrusive fix. Reported-and-tested-by:
Dmitry Vyukov <dvyukov@google.com> Acked-by:
Andrea Arcangeli <aarcange@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit d74e766e upstream. This reverts commit 39d42750. This caused a regression on some older hardware. bug: https://bugzilla.kernel.org/show_bug.cgi?id=113891Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Mario Kleiner authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit 1e1490a3 upstream. This is a port of the patch "drm/amdgpu: Fix error handling in amdgpu_flip_work_func." to fix the following problem for radeon as well which was reported against amdgpu: The patch e1d09dc0: "drm/amdgpu: Don't hang in amdgpu_flip_work_func on disabled crtc." from Feb 19, 2016, leads to the following static checker warning, as reported by Dan Carpenter in https://lists.freedesktop.org/archives/dri-devel/2016-February/101987.html drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:127 amdgpu_flip_work_func() warn: should this be 'repcnt == -1' drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:136 amdgpu_flip_work_func() error: double unlock 'spin_lock:&crtc->dev->event_lock' drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:136 amdgpu_flip_work_func() error: double unlock 'irqsave:flags' This patch fixes both reported problems: Change post-decrement of repcnt to pre-decrement, so it can't underflow anymore, but still performs up to three repetitions - three is the maximum one could expect in practice. Move the spin_unlock_irqrestore to where it actually belongs. Reviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Michel Dänzer <michel.daenzer@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Mario Kleiner authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit 90e94b16 upstream. The patch e1d09dc0: "drm/amdgpu: Don't hang in amdgpu_flip_work_func on disabled crtc." from Feb 19, 2016, leads to the following static checker warning, as reported by Dan Carpenter in https://lists.freedesktop.org/archives/dri-devel/2016-February/101987.html drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:127 amdgpu_flip_work_func() warn: should this be 'repcnt == -1' drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:136 amdgpu_flip_work_func() error: double unlock 'spin_lock:&crtc->dev->event_lock' drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:136 amdgpu_flip_work_func() error: double unlock 'irqsave:flags' This patch fixes both reported problems: Change post-decrement of repcnt to pre-decrement, so it can't underflow anymore, but still performs up to three repetitions - three is the maximum one could expect in practice. Move the spin_unlock_irqrestore to where it actually belongs. Reviewed-by:
-
Philipp Zabel authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit 17e05217 upstream. The port nodes are documented as optional, treat them accordingly. Reported-by:
Martin Fuzzey <mfuzzey@parkeon.com> Reported-by:
Chris Healy <Chris.Healy@zii.aero> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Fixes: 304e6be6 ("gpu: ipu-v3: Assign of_node of child platform devices to corresponding ports") Signed-off-by:
-
Jouni Malinen authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit 1ec7bae8 upstream. Public Action frames use special rules for how the BSSID field (Address 3) is set. A wildcard BSSID is used in cases where the transmitter and recipient are not members of the same BSS. As such, we need to accept Public Action frames with wildcard BSSID. Commit db8e1732 ("mac80211: ignore frames between TDLS peers when operating as AP") added a rule that drops Action frames to TDLS-peers based on an Action frame having different DA (Address 1) and BSSID (Address 3) values. This is not correct since it misses the possibility of BSSID being a wildcard BSSID in which case the Address 1 would not necessarily match. Fix this by allowing mac80211 to accept wildcard BSSID in an Action frame when in AP mode. Fixes: db8e1732 ("mac80211: ignore frames between TDLS peers when operating as AP") Signed-off-by:
Jouni Malinen <jouni@qca.qualcomm.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Johannes Berg authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit 9acc54be upstream. Just like for CCMP we need to check that for GCMP the fragments have PNs that increment by one; the spec was updated to fix this security issue and now has the following text: The receiver shall discard MSDUs and MMPDUs whose constituent MPDU PN values are not incrementing in steps of 1. Adapt the code for CCMP to work for GCMP as well, luckily the relevant fields already alias each other so no code duplication is needed (just check the aliasing with BUILD_BUG_ON.) Signed-off-by:
-
Felix Fietkau authored
BugLink: http://bugs.launchpad.net/bugs/1558330 commit c36dd3ea upstream. RTS/CTS needs to be enabled if the rate is a fallback rate *or* if it's a dual-stream rate and the sta is in dynamic SMPS mode. Fixes: a3ebb4e1 ("mac80211: minstrel_ht: handle peers in dynamic SMPS") Reported-by:
Matías Richart <mrichart@fing.edu.uy> Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
