- 13 Mar, 2018 7 commits
-
-
Benjamin Poirier authored
BugLink: http://bugs.launchpad.net/bugs/1730550 Lennart reported the following race condition: \ e1000_watchdog_task \ e1000e_has_link \ hw->mac.ops.check_for_link() === e1000e_check_for_copper_link /* link is up */ mac->get_link_status = false; /* interrupt */ \ e1000_msix_other hw->mac.get_link_status = true; link_active = !hw->mac.get_link_status /* link_active is false, wrongly */ This problem arises because the single flag get_link_status is used to signal two different states: link status needs checking and link status is down. Avoid the problem by using the return value of .check_for_link to signal the link status to e1000e_has_link(). Reported-by:
Lennart Sorensen <lsorense@csclub.uwaterloo.ca> Signed-off-by:
Benjamin Poirier <bpoirier@suse.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit 19110cfb) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Benjamin Poirier authored
BugLink: http://bugs.launchpad.net/bugs/1730550 When e1000e_poll() is not fast enough to keep up with incoming traffic, the adapter (when operating in msix mode) raises the Other interrupt to signal Receiver Overrun. This is a double problem because 1) at the moment e1000_msix_other() assumes that it is only called in case of Link Status Change and 2) if the condition persists, the interrupt is repeatedly raised again in quick succession. Ideally we would configure the Other interrupt to not be raised in case of receiver overrun but this doesn't seem possible on this adapter. Instead, we handle the first part of the problem by reverting to the practice of reading ICR in the other interrupt handler, like before commit 16ecba59 ("e1000e: Do not read ICR in Other interrupt"). Thanks to commit 0a8047ac ("e1000e: Fix msi-x interrupt automask") which cleared IAME from CTRL_EXT, reading ICR doesn't interfere with RxQ0, TxQ0 interrupts anymore. We handle the second part of the problem by not re-enabling the Other interrupt right away when there is overrun. Instead, we wait until traffic subsides, napi polling mode is exited and interrupts are re-enabled. Reported-by:
-
Alan Liu authored
BugLink: https://bugs.launchpad.net/bugs/1736317 QCA6174 WLAN.RM.2.0 firmware uses max_tx_power instead of using max_reg_power to set transmission power. The tx power was about -50dbm, after applying this change, it become -32dbm. Signed-off-by:
Alan Liu <alanliu@qca.qualcomm.com> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> (cherry picked from commit 513527c8) Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
Kai Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1720228 It's possible to use "err" without initializing it. If it happens to be a 2 which is SCSI_DH_RETRY then that could cause a bug. Bart Van Assche pointed out that we should probably re-initialize it for every iteration through the retry loop. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Hannes Reinicke <hare@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
James Bottomley <jejb@linux.vnet.ibm.com> (cherry picked from commit a4bd8520) Signed-off-by:
Dragan Stancevic <dragan.stancevic@canonical.com> Acked-by:
Kleber Souza <kleber.souza@canonical.com> Acked-by:
-
Vinson Lee authored
BugLink: http://bugs.launchpad.net/bugs/1734757Suggested-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Signed-off-by:
Vinson Lee <vlee@freedesktop.org> Acked-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1703742 The current configuration is set to always use transparent hugepages by default. There exists plenty of anecdotal evidence that this is less than perfect a choice and in some scenarios it leads to some performance issues. My own investigations with stress-ng stream and malloc tests show that the current default impacts performance. I ran various test scenarios on different MADVISE configurations, each result below is based on the average of 5 runs on an i7-3770 CPU @ 3.4GHz with 8GB memory, 8MB L3 cache, 256K L2 cache, 32K/32K L1 cache. All the above results are from an average of 5 rounds of tests. malloc allocation stressor: malloc always madvise size (MB) ops/sec ops/sec 32 1254.43 2422.49 64 2100.36 4300.28 128 3768.57 7215.38 256 7940.73 14893.85 512 17618.62 26861.29 1024 32777.17 48029.37 Clearly madvise is more performent. stream bandwidth/compute stressor: stream always madvise NOHUGEPAGE size (MB) MB/sec MB/sec 1 17713.54 18439.69 2 12460.34 13015.46 4 12195.81 12694.51 8 12085.11 12674.26 16 12054.09 12649.00 32 12082.42 12409.65 64 12262.88 12084.85 128 12235.25 11788.49 256 11808.69 11283.69 512 11970.01 12434.82 For small allocations, always is less performant. Large allocations can enable the more performant transparent huge pages with madvise(2) if we disable always as default. Other stress-ng memory allocation/writing/freeing and madvise operations showed little significant differences. I have also experimented with boot testing Ubuntu with kernels configured with different MADVISE configs and found there is little noticeable difference in performance, so I believe that there is little scope for any kitten killer performance regressions with this change. This change will by default not use transparent huge pages unless madvise(2) is used to instruct the kernel to do so on a memory mapping. According to the madvise(2) manual, this only takes effect on private anonymous mappings with MADV_HUGEPAGE. Signed-off-by:
-
Kleber Sacilotto de Souza authored
Ignore: yes Signed-off-by:
-
- 12 Feb, 2018 3 commits
-
-
Khalid Elmously authored
Signed-off-by: -
Andy Whitcroft authored
Fix a miss-backport of the upstream commit. Fixes: 63da13a9 ("net: ipv4: fix for a race condition in raw_sendmsg -- fix backport") BugLink: http://bugs.launchpad.net/bugs/1748671Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Khalid Elmously authored
Ignore: yes Signed-off-by:
-
- 11 Feb, 2018 8 commits
-
-
Andy Whitcroft authored
Signed-off-by: -
Andy Whitcroft authored
Signed-off-by: -
Andy Whitcroft authored
Signed-off-by: -
Andy Whitcroft authored
Ignore: yes Signed-off-by: -
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 Intel) Signed-off-by: -
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 Intel) Signed-off-by: -
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 Intel) When we have full retpoline enabled then we do not actually need to toggle IBRS on entering and leaving the kernel. Signed-off-by: -
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 Intel) This reverts commit d31a04f8. Signed-off-by:
-
- 09 Feb, 2018 22 commits
-
-
Khalid Elmously authored
Signed-off-by: -
Eric Desrochers authored
BugLink: https://bugs.launchpad.net/bugs/1744117 Add codec IDs for several recently released, pending, and historical NVIDIA GPU audio controllers to the patch table, to allow the correct patch functions to be selected for them. Signed-off-by:
Daniel Dadap <ddadap@nvidia.com> Reviewed-by:
Andy Ritger <aritger@nvidia.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> (cherry picked from commit 74ec1181) Signed-off-by:
Eric Desrochers <eric.desrochers@canonical.com> Acked-by:
Hui Wang <hui.wang@canonical.com> Acked-by:
-
Rafael David Tinoco authored
BugLink: https://bugs.launchpad.net/bugs/1569925 If, for any reason, userland shuts down iscsi transport interfaces before proper logouts - like when logging in to LUNs manually, without logging out on server shutdown, or when automated scripts can't umount/logout from logged LUNs - kernel will hang forever on its sd_sync_cache() logic, after issuing the SYNCHRONIZE_CACHE cmd to all still existent paths. PID: 1 TASK: ffff8801a69b8000 CPU: 1 COMMAND: "systemd-shutdow" #0 [ffff8801a69c3a30] __schedule at ffffffff8183e9ee #1 [ffff8801a69c3a80] schedule at ffffffff8183f0d5 #2 [ffff8801a69c3a98] schedule_timeout at ffffffff81842199 #3 [ffff8801a69c3b40] io_schedule_timeout at ffffffff8183e604 #4 [ffff8801a69c3b70] wait_for_completion_io_timeout at ffffffff8183fc6c #5 [ffff8801a69c3bd0] blk_execute_rq at ffffffff813cfe10 #6 [ffff8801a69c3c88] scsi_execute at ffffffff815c3fc7 #7 [ffff8801a69c3cc8] scsi_execute_req_flags at ffffffff815c60fe #8 [ffff8801a69c3d30] sd_sync_cache at ffffffff815d37d7 #9 [ffff8801a69c3da8] sd_shutdown at ffffffff815d3c3c This happens because iscsi_eh_cmd_timed_out(), the transport layer timeout helper, would tell the queue timeout function (scsi_times_out) to reset the request timer over and over, until the session state is back to logged in state. Unfortunately, during server shutdown, this might never happen again. Other option would be "not to handle" the issue in the transport layer. That would trigger the error handler logic, which would also need the session state to be logged in again. Best option, for such case, is to tell upper layers that the command was handled during the transport layer error handler helper, marking it as DID_NO_CONNECT, which will allow completion and inform about the problem. After the session was marked as ISCSI_STATE_FAILED, due to the first timeout during the server shutdown phase, all subsequent cmds will fail to be queued, allowing upper logic to fail faster. Signed-off-by:
Rafael David Tinoco <rafael.tinoco@canonical.com> Reviewed-by:
Lee Duncan <lduncan@suse.com> Signed-off-by:
Marcelo Henrique Cerri <marcelo.cerri@canonical.com> Acked-by:
-
Xinyu Lin authored
BugLink: http://bugs.launchpad.net/bugs/1743053 LITEON EP1 has the same timeout issues as CX1 series devices. Revert max_sectors to the value of 1024. 'e0edc8c5 ("libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices")' Signed-off-by:
Xinyu Lin <xinyu0123@gmail.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org (cherry picked from commit db5ff909) Signed-off-by:
-
Alexander Yarygin authored
BugLink: http://bugs.launchpad.net/bugs/1747090 Some facility bits are in a range that is defined to be "ok for guests without any necessary hypervisor changes". Enable those bits. Signed-off-by:
Alexander Yarygin <yarygin@linux.vnet.ibm.com> Reviewed-by:
David Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> (cherry picked from commit ed8dda0b) Signed-off-by:
-
Christian Borntraeger authored
BugLink: http://bugs.launchpad.net/bugs/1747090 The new firmware interfaces for branch prediction behaviour changes are transparently available for the guest. Nevertheless, there is new state attached that should be migrated and properly resetted. Provide a mechanism for handling reset and migration. Reviewed-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> (back ported from commit 35b3fde6) Signed-off-by:
-
Andy Whitcroft authored
CVE-2017-5715 (Spectre v2 Intel) When we have full retpoline enabled then we do not actually require IBPB flushes when entering the kernel. Add a new use_ibpb bit to represent when we have retpoline enabled. Further split the enable bit into two 0x1 representing whether entry IBPB is enabled and 0x10 representing whether kernel flushes for userspace/VMs etc are applied. Signed-off-by:
-
Stefan Bader authored
CVE-2017-5715 (Spectre v2 Intel) Initial change was missing code to correctly mask EDX bits of cpuid level 7.0. Fixes: 8339cae2 ("KVM: x86: Add speculative control CPUID support for guests") Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Provide the guest with the speculative control CPUID related values. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Set IBPB (Indirect Branch Prediction Barrier) when the current CPU is going to run a VCPU different from what was previously run. Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Set/restore the guests IBRS value on VM entry. On VM exit back to the kernel save the guest IBRS value and then set IBRS to 1. Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Allow guest access to the speculative control MSRs without being intercepted. Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Add an IBPB feature check to the speculative control update check after a microcode reload. Signed-off-by:
-
Tom Lendacky authored
CVE-2017-5715 (Spectre v2 Intel) Add speculative control support for AMD processors. For AMD, speculative control is indicated as follows: CPUID EAX=0x00000007, ECX=0x00 return EDX[26] indicates support for both IBRS and IBPB. CPUID EAX=0x80000008, ECX=0x00 return EBX[12] indicates support for just IBPB. On AMD family 0x10, 0x12 and 0x16 processors where either of the above features are not supported, IBPB can be achieved by disabling indirect branch predictor support in MSR 0xc0011021[14] at boot. Signed-off-by:
-
Borislav Petkov authored
CVE-2017-5715 (Spectre v2 Intel) The kernel accesses IC_CFG MSR (0xc0011021) on AMD because it checks whether the way access filter is enabled on some F15h models, and, if so, disables it. kvm doesn't handle that MSR access and complains about it, which can get really noisy in dmesg when one starts kvm guests all the time for testing. And it is useless anyway - guest kernel shouldn't be doing such changes anyway so tell it that that filter is disabled. Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit ae8b7875) Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Signed-off-by:
Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) There are 2 ways to control IBPB and IBRS 1. At boot time noibrs kernel boot parameter will disable IBRS usage noibpb kernel boot parameter will disable IBPB usage Otherwise if the above parameters are not specified, the system will enable ibrs and ibpb usage if the cpu supports it. 2. At run time echo 0 > /proc/sys/kernel/ibrs_enabled will turn off IBRS echo 1 > /proc/sys/kernel/ibrs_enabled will turn on IBRS in kernel echo 2 > /proc/sys/kernel/ibrs_enabled will turn on IBRS in both userspace and kernel Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Restore guest IBRS on VM entry and set it to 1 on VM exit back to kernel. Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Set IBPB (Indirect branch prediction barrier) when switching VM. Signed-off-by:
-
Wei Wang authored
CVE-2017-5715 (Spectre v2 Intel) Add field to access guest MSR_IA332_SPEC_CTRL and MSR_IA32_PRED_CMD state. Signed-off-by:
Wei Wang <wei.w.wang@intel.com> Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) To reduce overhead of setting IBPB, we only do that when the new thread cannot ptrace the current one. If the new thread has ptrace capability on current thread, it is safe. Signed-off-by:
-
Tim Chen authored
CVE-2017-5715 (Spectre v2 Intel) Set IBPB on context switch with changing of page table. Signed-off-by:
-
