- 06 Dec, 2016 40 commits
-
-
Ignacio Alvarado authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 1650b4eb upstream. Function user_notifier_unregister should be called only once for each registered user notifier. Function kvm_arch_hardware_disable can be executed from an IPI context which could cause a race condition with a VCPU returning to user mode and attempting to unregister the notifier. Signed-off-by:
Ignacio Alvarado <ikalvarado@google.com> Fixes: 18863bdd ("KVM: x86 shared msr infrastructure") Reviewed-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Paolo Bonzini authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit 7301d6ab upstream. Reported by syzkaller: [ INFO: suspicious RCU usage. ] 4.9.0-rc4+ #47 Not tainted ------------------------------- ./include/linux/kvm_host.h:536 suspicious rcu_dereference_check() usage! stack backtrace: CPU: 1 PID: 6679 Comm: syz-executor Not tainted 4.9.0-rc4+ #47 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffff880039e2f6d0 ffffffff81c2e46b ffff88003e3a5b40 0000000000000000 0000000000000001 ffffffff83215600 ffff880039e2f700 ffffffff81334ea9 ffffc9000730b000 0000000000000004 ffff88003c4f8420 ffff88003d3f8000 Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [<ffffffff81c2e46b>] dump_stack+0xb3/0x118 lib/dump_stack.c:51 [<ffffffff81334ea9>] lockdep_rcu_suspicious+0x139/0x180 kernel/locking/lockdep.c:4445 [< inline >] __kvm_memslots include/linux/kvm_host.h:534 [< inline >] kvm_memslots include/linux/kvm_host.h:541 [<ffffffff8105d6ae>] kvm_gfn_to_hva_cache_init+0xa1e/0xce0 virt/kvm/kvm_main.c:1941 [<ffffffff8112685d>] kvm_lapic_set_vapic_addr+0xed/0x140 arch/x86/kvm/lapic.c:2217 Reported-by:
Dmitry Vyukov <dvyukov@google.com> Fixes: fda4e2e8 Cc: Andrew Honig <ahonig@google.com> Signed-off-by:
David Hildenbrand <david@redhat.com> Signed-off-by:
-
Yazen Ghannam authored
BugLink: http://bugs.launchpad.net/bugs/1645453 commit b0b6e868 upstream. cpu_llc_id (Last Level Cache ID) derivation on AMD Fam17h has an underflow bug when extracting the socket_id value. It starts from 0 so subtracting 1 from it will result in an invalid value. This breaks scheduling topology later on since the cpu_llc_id will be incorrect. For example, the the cpu_llc_id of the *other* CPU in the loops in set_cpu_sibling_map() underflows and we're generating the funniest thread_siblings masks and then when I run 8 threads of nbench, they get spread around the LLC domains in a very strange pattern which doesn't give you the normal scheduling spread one would expect for performance. Other things like EDAC use cpu_llc_id so they will be b0rked too. So, the APIC ID is preset in APICx020 for bits 3 and above: they contain the core complex, node and socket IDs. The LLC is at the core complex level so we can find a unique cpu_llc_id by right shifting the APICID by 3 because then the least significant bit will be the Core Complex ID. Tested-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Yazen Ghannam <Yazen.Ghannam@amd.com> [ Cleaned up and extended the commit message. ] Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Aravind Gopalakrishnan <aravindksg.lkml@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Fixes: 3849e91f ("x86/AMD: Fix last level cache topology for AMD Fam17h systems") Link: http://lkml.kernel.org/r/20161108083506.rvqb5h4chrcptj7d@pd.tnicSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1645278 Andre Noll reported panics after my recent fix (commit 34fad54c "net: __skb_flow_dissect() must cap its return value") After some more headaches, Alexander root caused the problem to init_default_flow_dissectors() being called too late, in case a network driver like IGB is not a module and receives DHCP message very early. Fix is to call init_default_flow_dissectors() much earlier, as it is a core infrastructure and does not depend on another kernel service. Fixes: 06635a35 ("flow_dissect: use programable dissector in skb_flow_dissect and friends") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Andre Noll <maan@tuebingen.mpg.de> Diagnosed-by:
Alexander Duyck <alexander.h.duyck@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit c9b8af13) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
-
Luis Henriques authored
BugLink: https://launchpad.net/bugs/1644726Signed-off-by:
-
Dan Carpenter authored
BugLink: https://launchpad.net/bugs/1644726 The > here should be >= or we go beyond the end for the array. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> (backported from commit 04bf0217) Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
-
Paul Cercueil authored
BugLink: https://launchpad.net/bugs/1644726 This patch adds support for the AD5592R (spi) and AD5593R (i2c) ADC/DAC/GPIO devices. Signed-off-by:
Paul Cercueil <paul.cercueil@analog.com> Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Gregor Boirie authored
BugLink: https://launchpad.net/bugs/1642258 Implement lps22hb temperature sampling channel. Signed-off-by:
Gregor Boirie <gregor.boirie@parrot.com> Tested-by:
-
Gregor Boirie authored
BugLink: https://launchpad.net/bugs/1642258 Details scaling factors and offsets applied to raw temperature and pressure samples. Signed-off-by:
-
Gregor Boirie authored
BugLink: https://launchpad.net/bugs/1642258 Sampled pressure data are 24 bits long and should be stored in a 32 bits word. Signed-off-by:
-
Gregor Boirie authored
BugLink: https://launchpad.net/bugs/1642258 Initial support for ST LPS22HB pressure sensor. Datasheet: http://www2.st.com/resource/en/datasheet/lps22hb.pdf Features: * pressure data and timestamping channels * sampling frequency selection * interrupt based trigger * over I2C or SPI Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299Signed-off-by:
Michael Cyr <mikecyr@us.ibm.com> Signed-off-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299 This patch adds code to disconnect from the client, which will make sure any outstanding commands have been completed, before continuing on with the remove operation. Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299 This patch changes the way the IBM vSCSI server driver manages its Command/Response Queue (CRQ). We used to register the CRQ with phyp at probe time. Now we wait until tpg_enable_store. Similarly, when tpg_enable_store is called to "disable" (i.e. the stored value is 0), we unregister the queue with phyp. One consquence to this is that we have no need for the PART_UP_WAIT_ENAB state, since we can't get an Init Message from the client in our CRQ if we're waiting to be enabled, since we haven't registered the queue yet. Signed-off-by:
-
Michael Cyr authored
BugLink: http://bugs.launchpad.net/bugs/1642299 This patch reorders functions in a manner necessary for a follow-on patch. It also makes some minor styling changes (mostly removing extra spaces) and fixes some typos. There are no code changes in this patch, with one exception: due to the reordering of the functions, I needed to explicitly declare a function at the top of the file. However, this will be removed in the next patch, since the code requiring the predeclaration will be removed. Signed-off-by:
-
Yuyang Du authored
BugLink: http://bugs.launchpad.net/bugs/1643797 If a newly created task is selected to go to a different CPU in fork balance when it wakes up the first time, its load averages should not be removed from the source CPU since they are never added to it before. The same is also applicable to a never used group entity. Fix it in remove_entity_load_avg(): when entity's last_update_time is 0, simply return. This should precisely identify the case in question, because in other migrations, the last_update_time is set to 0 after remove_entity_load_avg(). Reported-by:
Steve Muckle <steve.muckle@linaro.org> Signed-off-by:
Yuyang Du <yuyang.du@intel.com> [peterz: cfs_rq_last_update_time] Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Dietmar Eggemann <dietmar.eggemann@arm.com> Cc: Juri Lelli <Juri.Lelli@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Morten Rasmussen <morten.rasmussen@arm.com> Cc: Patrick Bellasi <patrick.bellasi@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vincent Guittot <vincent.guittot@linaro.org> Link: http://lkml.kernel.org/r/20151216233427.GJ28098@intel.comSigned-off-by:
Phidias Chiang <phidias.chiang@canonical.com> Acked-by:
Robert Hooker <robert.hooker@canonical.com> Acked-by:
-
Rob Nelson authored
BugLink: http://bugs.launchpad.net/bugs/1637565 This change provides a mechanism to reduce the number of MMIO doorbell writes for the NVMe driver. When running in a virtualized environment like QEMU, the cost of an MMIO is quite hefy here. The main idea for the patch is provide the device two memory location locations: 1) to store the doorbell values so they can be lookup without the doorbell MMIO write 2) to store an event index. I believe the doorbell value is obvious, the event index not so much. Similar to the virtio specificaiton, the virtual device can tell the driver (guest OS) not to write MMIO unless you are writing past this value. FYI: doorbell values are written by the nvme driver (guest OS) and the event index is written by the virtual device (host OS). The patch implements a new admin command that will communicate where these two memory locations reside. If the command fails, the nvme driver will work as before without any optimizations. Contributions: Eric Northup <digitaleric@google.com> Frank Swiderski <fes@google.com> Ted Tso <tytso@mit.edu> Keith Busch <keith.busch@intel.com> Just to give an idea on the performance boost with the vendor extension: Running fio [1], a stock NVMe driver I get about 200K read IOPs with my vendor patch I get about 1000K read IOPs. This was running with a null device i.e. the backing device simply returned success on every read IO request. [1] Running on a 4 core machine: fio --time_based --name=benchmark --runtime=30 --filename=/dev/nvme0n1 --nrfiles=1 --ioengine=libaio --iodepth=32 --direct=1 --invalidate=1 --verify=0 --verify_fatal=0 --numjobs=4 --rw=randread --blocksize=4k --randrepeat=false Signed-off-by:
Rob Nelson <rlnelson@google.com> [mlin: port for upstream] Signed-off-by:
Ming Lin <mlin@kernel.org> [koike: updated for current APIs] Signed-off-by:
Helen Mae Koike Fornazier <helen.koike@collabora.co.uk> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1637565Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1637565 The NVMe over Fabrics specification defines a protocol interface and related extensions to NVMe that enable operation over network protocols. The NVMe over Fabrics specification has an NVMe Transport binding for each NVMe Transport. This patch adds the fabrics related definitions: - fabric specific command set and error codes - transport addressing and binding definitions - fabrics sgl extensions - controller identification fabrics enhancements - discovery log page definition Signed-off-by:
Armen Baloyan <armenx.baloyan@intel.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
Jay Freyensee <james.p.freyensee@intel.com> Signed-off-by:
Ming Lin <ming.l@ssi.samsung.com> Signed-off-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
Jens Axboe <axboe@fb.com> (back ported from commit eb793e2c) Signed-off-by:
-
Ming Lin authored
BugLink: http://bugs.launchpad.net/bugs/1637565 For some protocols like NVMe over Fabrics we need to be able to send initialization commands to a specific queue. Based on an earlier patch from Christoph Hellwig <hch@lst.de>. Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1642228Signed-off-by:
-
Jiri Pirko authored
BugLink: http://bugs.launchpad.net/bugs/1642514 The matchall classifier matches every packet and allows the user to apply actions on it. This filter is very useful in usecases where every packet should be matched, for example, packet mirroring (SPAN) can be setup very easily using that filter. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1642514Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1643637Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 0fd0ff01 ] Now that all of the user copy routines are converted to return accurate residual lengths when an exception occurs, we no longer need the broken fixup routines. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 614da3d9 ] All of __ret{,l}_mone{_asi,_fp,_asi_fpu} are now unused. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit ee841d0a ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit e93704e4 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 7ae3aaf5 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 95707704 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit cb736fdb ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit d0796b55 ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 0096ac9f ] Report the exact number of bytes which have not been successfully copied when an exception occurs, using the running remaining length. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 83a17d26 ] The fixup helper function mechanism for handling user copy fault handling is not %100 accurrate, and can never be made so. We are going to transition the code to return the running return return length, which is always kept track in one or more registers of each of these routines. In order to convert them one by one, we have to allow the existing behavior to continue functioning. Therefore make all the copy code that wants the fixup helper to be used return negative one. After all of the user copy routines have been converted, this logic and the fixup helpers themselves can be removed completely. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit aa95ce36 ] It is completely unused. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit a74ad5e6 ] When the vmalloc area gets fragmented, and because the firmware mapping area sits between where modules live and the vmalloc area, we can sometimes receive requests for enormous kernel TLB range flushes. When this happens the cpu just spins flushing billions of pages and this triggers the NMI watchdog and other problems. We took care of this on the TSB side by doing a linear scan of the table once we pass a certain threshold. Do something similar for the TLB flush, however we are limited by the TLB flush facilities provided by the different chip variants. First of all we use an (mostly arbitrary) cut-off of 256K which is about 32 pages. This can be tuned in the future. The huge range code path for each chip works as follows: 1) On spitfire we flush all non-locked TLB entries using diagnostic acceses. 2) On cheetah we use the "flush all" TLB flush. 3) On sun4v/hypervisor we do a TLB context flush on context 0, which unlike previous chips does not remove "permanent" or locked entries. We could probably do something better on spitfire, such as limiting the flush to kernel TLB entries or even doing range comparisons. However that probably isn't worth it since those chips are old and the TLB only had 64 entries. Reported-by:
James Clarke <jrtc27@jrtc27.com> Tested-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit a236441b ] Just like the non-cross-call TLB flush handlers, the cross-call ones need to avoid doing PC-relative branches outside of their code blocks. Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1643637 [ Upstream commit 830cda3f ] Noticed by James Clarke. Signed-off-by:
-
