- 06 Apr, 2016 40 commits
-
-
dann frazier authored
BugLink: http://bugs.launchpad.net/bugs/1558765Signed-off-by:
dann frazier <dann.frazier@canonical.com> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Ganapatrao Kulkarni authored
BugLink: http://bugs.launchpad.net/bugs/1558765 Add DT bindings for numa mapping of memory, CPUs and IOs. Reviewed-by:
Robert Richter <rrichter@cavium.com> Signed-off-by:
Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com> Signed-off-by:
David Daney <david.daney@cavium.com> Acked-by:
Rob Herring <robh@kernel.org> [ dannf: v15 submittal ] Reference: http://www.spinics.net/lists/arm-kernel/msg489636.htmlSigned-off-by:
-
Ard Biesheuvel authored
BugLink: http://bugs.launchpad.net/bugs/1558765 There are two problems with the UEFI stub DT memory node removal routine: - it deletes nodes as it traverses the tree, which happens to work but is not supported, as deletion invalidates the node iterator; - deleting memory nodes entirely may discard annotations in the form of additional properties on the nodes. Since the discovery of DT memory nodes occurs strictly before the UEFI init sequence, we can simply clear the memblock memory table before parsing the UEFI memory map. This way, it is no longer necessary to remove the nodes, so we can remove that logic from the stub as well. Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Joseph Salisbury authored
BugLink: http://bugs.launchpad.net/bugs/1558447 This reverts commit d45d44e0. Signed-off-by:
-
Andy Whitcroft authored
Signed-off-by:Andy Whitcroft <apw@canonical.com>
-
Alex Ng authored
BugLink: http://bugs.launchpad.net/bugs/1558720 WS2012 R2 and above hosts can support kexec in that thay can support reconnecting to the host (as would be needed in the kexec path) on any CPU. Enable this. Pre ws2012 r2 hosts don't have this ability and consequently cannot support kexec. Signed-off-by:
Alex Ng <alexng@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from linux-next commit 72686447) Signed-off-by:
-
K. Y. Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1558720 Starting with Windows 2012 R2, message inteerupts can be delivered on any VCPU in the guest. Support this functionality. Signed-off-by:
-
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:
-
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:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
-
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:
-
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:
-
