- 13 Nov, 2018 40 commits
-
-
Jayachandran C authored
BugLink: https://bugs.launchpad.net/bugs/1797092 Add config option PCI_ECAM and file drivers/pci/ecam.c to provide generic functions for accessing memory-mapped PCI config space. The API is defined in drivers/pci/ecam.h and is written to replace the API in drivers/pci/host/pci-host-common.h. The file defines a new 'struct pci_config_window' to hold the information related to a PCI config area and its mapping. This structure is expected to be used as sysdata for controllers that have ECAM based mapping. Helper functions are provided to setup the mapping, free the mapping and to implement the map_bus method in 'struct pci_ops' Signed-off-by:
Jayachandran C <jchandra@broadcom.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> (cherry picked from commit 35ff9477) Signed-off-by:
dann frazier <dann.frazier@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
dann frazier authored
BugLink: https://bugs.launchpad.net/bugs/1797092Signed-off-by:
-
Sai Praneeth authored
BugLink: https://launchpad.net/bugs/1786139 Future Intel processors will support "Enhanced IBRS" which is an "always on" mode i.e. IBRS bit in SPEC_CTRL MSR is enabled once and never disabled. From the specification [1]: "With enhanced IBRS, the predicted targets of indirect branches executed cannot be controlled by software that was executed in a less privileged predictor mode or on another logical processor. As a result, software operating on a processor with enhanced IBRS need not use WRMSR to set IA32_SPEC_CTRL.IBRS after every transition to a more privileged predictor mode. Software can isolate predictor modes effectively simply by setting the bit once. Software need not disable enhanced IBRS prior to entering a sleep state such as MWAIT or HLT." If Enhanced IBRS is supported by the processor then use it as the preferred spectre v2 mitigation mechanism instead of Retpoline. Intel's Retpoline white paper [2] states: "Retpoline is known to be an effective branch target injection (Spectre variant 2) mitigation on Intel processors belonging to family 6 (enumerated by the CPUID instruction) that do not have support for enhanced IBRS. On processors that support enhanced IBRS, it should be used for mitigation instead of retpoline." The reason why Enhanced IBRS is the recommended mitigation on processors which support it is that these processors also support CET which provides a defense against ROP attacks. Retpoline is very similar to ROP techniques and might trigger false positives in the CET defense. If Enhanced IBRS is selected as the mitigation technique for spectre v2, the IBRS bit in SPEC_CTRL MSR is set once at boot time and never cleared. Kernel also has to make sure that IBRS bit remains set after VMEXIT because the guest might have cleared the bit. This is already covered by the existing x86_spec_ctrl_set_guest() and x86_spec_ctrl_restore_host() speculation control functions. Enhanced IBRS still requires IBPB for full mitigation. [1] Speculative-Execution-Side-Channel-Mitigations.pdf [2] Retpoline-A-Branch-Target-Injection-Mitigation.pdf Both documents are available at: https://bugzilla.kernel.org/show_bug.cgi?id=199511Originally-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: Tim C Chen <tim.c.chen@intel.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Ravi Shankar <ravi.v.shankar@intel.com> Link: https://lkml.kernel.org/r/1533148945-24095-1-git-send-email-sai.praneeth.prakhya@intel.com (backported from commit 706d5168) [tyhicks: Minor context changes and properly place the check in cpu_set_bug_bits()] Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
-
Jiang Biao authored
BugLink: https://launchpad.net/bugs/1786139 SPECTRE_V2_IBRS in enum spectre_v2_mitigation is never used. Remove it. Signed-off-by:
Jiang Biao <jiang.biao2@zte.com.cn> Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 linux/prefetch.h is never explicitly included in ena_com, although functions from it, such as prefetchw(), are used throughout ena_com. This is an inclusion bug, and we fix it here by explicitly including linux/prefetch.h. The bug was exposed when the driver was compiled for the xtensa architecture. Fixes: 689b2bda ("net: ena: add functions for handling Low Latency Queues in ena_com") Fixes: 8c590f97 ("ena: Fix Kconfig dependency on X86") Signed-off-by:
Arthur Kiyanovski <akiyano@amazon.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 00f17a82 net-next) Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Use the new API to enable usage of LLQ. Signed-off-by:
-
Netanel Belgazal authored
BugLink: http://bugs.launchpad.net/bugs/1798182 The Kconfig limitation of X86 is to too wide. The ENA driver only requires a little endian dependency. Change the dependency to be on little endian CPU. Signed-off-by:
Netanel Belgazal <netanel@amazon.com> Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Remove redundant spinlock acquire parameter from ena_com_admin_init() Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Improves socket memory utilization when receiving packets larger than 128 bytes (the previous rx copybreak) and smaller than 256 bytes. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Currently Rx refill is done when the number of required descriptors is above 1/8 queue size. With a default of 1024 entries per queue the threshold is 128 descriptors. There is intention to increase the queue size to 8196 entries. In this case threshold of 1024 descriptors is too large and can hurt latency. Add another limitation to Rx threshold to be at most 256 descriptors. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Set skb->ip_summed to the correct value as reported by the device. Add counter for the case where rx csum offload is enabled but device didn't check it. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 This patch includes all code changes necessary in ena_netdev to enable packet sending via the LLQ placemnt mode. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 This patch introduces APIs for detection, initialization, configuration and actual usage of low latency queues(LLQ). It extends transmit API with creation of LLQ descriptors in device memory (which include host buffers descriptors as well as packet header) Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Low Latency Queues(LLQ) allow usage of device's memory for descriptors and headers. Such queues decrease processing time since data is already located on the device when driver rings the doorbell. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Add new fields and definitions to host info and fill them according to the latest ENA spec version. Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Reduce fastpath overhead by making ena_com_tx_comp_req_id_get() inline. Also move it to ena_eth_com.h file with its dependency function ena_com_cq_inc_head(). Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Eliminate potential auto casting compilation error. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 napi poll functions should be initialized before running request_irq(), to handle a rare condition where there is a pending interrupt, causing the ISR to fire immediately while the poll function wasn't set yet, causing a NULL dereference. Fixes: 1738cd3e ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 In a rare scenario when ena_device_restore() fails, followed by device remove, an FLR will not be issued. In this case, the device will keep sending asynchronous AENQ keep-alive events, even after driver removal, leading to memory corruption. Fixes: 8c5c7abd ("net: ena: add power management ops to the ENA driver") Signed-off-by:
-
Arthur Kiyanovski authored
BugLink: http://bugs.launchpad.net/bugs/1798182 Memory mapped with devm_ioremap is automatically freed when the driver is disconnected from the device. Therefore there is no need to explicitly call devm_iounmap. Fixes: 0857d92f ("net: ena: add missing unmap bars on device removal") Fixes: 411838e7 ("net: ena: fix rare kernel crash when bar memory remap fails") Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1798182 As diagnosed by Song Liu, ndo_poll_controller() can be very dangerous on loaded hosts, since the cpu calling ndo_poll_controller() might steal all NAPI contexts (for all RX/TX queues of the NIC). This capture can last for unlimited amount of time, since one cpu is generally not able to drain all the queues under load. ena uses NAPI for TX completions, so we better let core networking stack call the napi->poll() to avoid the capture. Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Netanel Belgazal <netanel@amazon.com> Cc: Saeed Bishara <saeedb@amazon.com> Cc: Zorik Machulsky <zorik@amazon.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1801900Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
-
Long Li authored
BugLink: https://bugs.launchpad.net/bugs/1801900 commit a3ade8cc upstream. The host may send multiple negotiation packets (due to timeout) before the KVP user-mode daemon is connected. KVP user-mode daemon is connected. We need to defer processing those packets until the daemon is negotiated and connected. It's okay for guest to respond to all negotiation packets. In addition, the host may send multiple staged KVP requests as soon as negotiation is done. We need to properly process those packets using one tasklet for exclusive access to ring buffer. This patch is based on the work of Nick Meier <Nick.Meier@microsoft.com>. The above is the original changelog of a3ade8cc ("HV: properly delay KVP packets when negotiation is in progress" Here I re-worked the original patch because the mainline version can't work for the linux-4.4.y branch, on which channel->callback_event doesn't exist yet. In the mainline, channel->callback_event was added by: 631e63a9 ("vmbus: change to per channel tasklet"). Here we don't want to backport it to v4.4, as it requires extra supporting changes and fixes, which are unnecessary as to the KVP bug we're trying to resolve. NOTE: before this patch is used, we should cherry-pick the other related 3 patches from the mainline first: The background of this backport request is that: recently Wang Jian reported some KVP issues: https://github.com/LIS/lis-next/issues/593: e.g. the /var/lib/hyperv/.kvp_pool_* files can not be updated, and sometimes if the hv_kvp_daemon doesn't timely start, the host may not be able to query the VM's IP address via KVP. Reported-by:
Wang Jian <jianjian.wang1@gmail.com> Tested-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
Long Li <longli@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Stephen Warren authored
BugLink: https://bugs.launchpad.net/bugs/1801900 commit daa35bd9 upstream. When the gadget serial device has no associated TTY, do not pass any received data into the TTY layer for processing; simply drop it instead. This prevents the TTY layer from calling back into the gadget serial driver, which will then crash in e.g. gs_write_room() due to lack of gadget serial device to TTY association (i.e. a NULL pointer dereference). Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Alexey Brodkin authored
BugLink: https://bugs.launchpad.net/bugs/1801900 commit 615f6445 upstream. This check is very naive: we simply test if GCC invoked without "-mcpu=XXX" has ARC700 define set. In that case we think that GCC was built with "--with-cpu=arc700" and has libgcc built for ARC700. Otherwise if ARC700 is not defined we think that everythng was built for ARCv2. But in reality our life is much more interesting. 1. Regardless of GCC configuration (i.e. what we pass in "--with-cpu" it may generate code for any ARC core). 2. libgcc might be built with explicitly specified "--mcpu=YYY" That's exactly what happens in case of multilibbed toolchains: - GCC is configured with default settings - All the libs built for many different CPU flavors I.e. that check gets in the way of usage of multilibbed toolchains. And even non-multilibbed toolchains are affected. OpenEmbedded also builds GCC without "--with-cpu" because each and every target component later is compiled with explicitly set "-mcpu=ZZZ". Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Michael Neuling authored
BugLink: https://bugs.launchpad.net/bugs/1801900 [ Upstream commit 96dc89d5 ] Current we store the userspace r1 to PACATMSCRATCH before finally saving it to the thread struct. In theory an exception could be taken here (like a machine check or SLB miss) that could write PACATMSCRATCH and hence corrupt the userspace r1. The SLB fault currently doesn't touch PACATMSCRATCH, but others do. We've never actually seen this happen but it's theoretically possible. Either way, the code is fragile as it is. This patch saves r1 to the kernel stack (which can't fault) before we turn MSR[RI] back on. PACATMSCRATCH is still used but only with MSR[RI] off. We then copy r1 from the kernel stack to the thread struct once we have MSR[RI] back on. Suggested-by:
Breno Leitao <leitao@debian.org> Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Michael Neuling authored
BugLink: https://bugs.launchpad.net/bugs/1801900 [ Upstream commit cf13435b ] When we treclaim we store the userspace checkpointed r13 to a scratch SPR and then later save the scratch SPR to the user thread struct. Unfortunately, this doesn't work as accessing the user thread struct can take an SLB fault and the SLB fault handler will write the same scratch SPRG that now contains the userspace r13. To fix this, we store r13 to the kernel stack (which can't fault) before we access the user thread struct. Found by running P8 guest + powervm + disable_1tb_segments + TM. Seen as a random userspace segfault with r13 looking like a kernel address. Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1801900 [ Upstream commit 8ac1ee6f ] Clang warns that the address of a pointer will always evaluated as true in a boolean context: drivers/net/ethernet/mellanox/mlx4/eq.c:243:11: warning: address of array 'eq->affinity_mask' will always evaluate to 'true' [-Wpointer-bool-conversion] if (!eq->affinity_mask || cpumask_empty(eq->affinity_mask)) ~~~~~^~~~~~~~~~~~~ 1 warning generated. Use cpumask_available, introduced in commit f7e30f01 ("cpumask: Add helper cpumask_available()"), which does the proper checking and avoids this warning. Link: https://github.com/ClangBuiltLinux/linux/issues/86Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
-
Michael Schmitz authored
BugLink: https://bugs.launchpad.net/bugs/1801900 [ Upstream commit 52d2c7bf ] The CapsLock key on Atari keyboards is not a toggle, it does send the normal make and break scancodes. Drop the CapsLock toggle handling code, which did cause the CapsLock key to merely act as a Shift key. Tested-by:
Michael Schmitz <schmitzmic@gmail.com> Signed-off-by:
Andreas Schwab <schwab@linux-m68k.org> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Andreas Schwab authored
BugLink: https://bugs.launchpad.net/bugs/1801900 [ Upstream commit 9e62df51 ] Fix errors in Atari keymap (mostly in keypad, help and undo keys). Patch provided on debian-68k ML by Andreas Schwab <schwab@linux-m68k.org>, keymap array size and unhandled scancode limit adjusted to 0x73 by me. Tested-by:
-
Keerthy authored
BugLink: https://bugs.launchpad.net/bugs/1801900 [ Upstream commit 3b7d96a0 ] The 32k clocksource is NONSTOP for non-am43 SoCs. Hence add the flag for all the other SoCs. Reported-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Keerthy <j-keerthy@ti.com> Acked-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
-
Jozef Balga authored
BugLink: https://bugs.launchpad.net/bugs/1801900 [ Upstream commit 312f73b6 ] When less than 3 bytes are written to the device, memcpy is called with negative array size which leads to buffer overflow and kernel panic. This patch adds a condition and returns -EOPNOTSUPP instead. Fixes bugzilla issue 64871 [mchehab+samsung@kernel.org: fix a merge conflict and changed the condition to match the patch's comment, e. g. len == 3 could also be valid] Signed-off-by:
Jozef Balga <jozef.balga@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Andy Lutomirski authored
BugLink: https://bugs.launchpad.net/bugs/1801900 commit e6365084 upstream. Now that eagerfpu= is gone, remove it from the docs and some comments. Also sync the changes to tools/. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com> Cc: Rik van Riel <riel@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/cf430dd4481d41280e93ac6cf0def1007a67fc8e.1476740397.git.luto@kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp> Signed-off-by:
-
Rik van Riel authored
BugLink: https://bugs.launchpad.net/bugs/1801900 commit 3913cc35 upstream. With the lazy FPU code gone, we no longer use the counter field in struct fpu for anything. Get rid it. Signed-off-by:
Rik van Riel <riel@redhat.com> Reviewed-by:
-
Andy Lutomirski authored
BugLink: https://bugs.launchpad.net/bugs/1801900 commit c592b573 upstream. This removes all the obvious code paths that depend on lazy FPU mode. It shouldn't change the generated code at all. Signed-off-by:
-
Paolo Bonzini authored
BugLink: https://bugs.launchpad.net/bugs/1801900 commit 5a5fbdc0 upstream. It is now equal to use_eager_fpu(), which simply tests a cpufeature bit. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: https://bugs.launchpad.net/bugs/1801900 [ Upstream commit 0e1d6eca ] We have an impressive number of syzkaller bugs that are linked to the fact that syzbot was able to create a networking device with millions of TX (or RX) queues. Let's limit the number of RX/TX queues to 4096, this really should cover all known cases. A separate patch will add various cond_resched() in the loops handling sysfs entries at device creation and dismantle. Tested: lpaa6:~# ip link add gre-4097 numtxqueues 4097 numrxqueues 4097 type ip6gretap RTNETLINK answers: Invalid argument lpaa6:~# time ip link add gre-4096 numtxqueues 4096 numrxqueues 4096 type ip6gretap real 0m0.180s user 0m0.000s sys 0m0.107s Fixes: 76ff5cc9 ("rtnl: allow to specify number of rx and tx queues on device creation") Signed-off-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
