- 19 7月, 2023 21 次提交
-
-
由 Maxim Levitsky 提交于
stable inclusion from stable-v5.10.154 commit c8a2fd7a715d9882eed5ddb4105bce2f6a8163c2 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c8a2fd7a715d9882eed5ddb4105bce2f6a8163c2 -------------------------------- commit 5015bb89 upstream. SYSEXIT is one of the instructions that can change the processor mode, thus ctxt->mode should be updated after it. Note that this is likely a benign bug, because the only problematic mode change is from 32 bit to 64 bit which can lead to truncation of RIP, and it is not possible to do with sysexit, since sysexit running in 32 bit mode will be limited to 32 bit version. Signed-off-by: NMaxim Levitsky <mlevitsk@redhat.com> Message-Id: <20221025124741.228045-11-mlevitsk@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 78979ae9)
-
由 Jim Mattson 提交于
stable inclusion from stable-v5.10.154 commit e0c7410378cd1adbfd35a65faca5df8936631b1a category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e0c7410378cd1adbfd35a65faca5df8936631b1a -------------------------------- commit 0469e56a upstream. KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM actually supports. CPUID.80000001:EBX[27:16] are reserved bits and should be masked off. Fixes: 07716717 ("KVM: Enhance guest cpuid management") Signed-off-by: NJim Mattson <jmattson@google.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit d6c7c247)
-
由 Jim Mattson 提交于
stable inclusion from stable-v5.10.154 commit 9302ebc1c21d93ef7004cd228c8b493dc64f7194 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9302ebc1c21d93ef7004cd228c8b493dc64f7194 -------------------------------- commit 7030d853 upstream. KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM actually supports. The following ranges of CPUID.80000008H are reserved and should be masked off: ECX[31:18] ECX[11:8] In addition, the PerfTscSize field at ECX[17:16] should also be zero because KVM does not set the PERFTSC bit at CPUID.80000001H.ECX[27]. Fixes: 24c82e57 ("KVM: Sanitize cpuid") Signed-off-by: NJim Mattson <jmattson@google.com> Message-Id: <20220929225203.2234702-3-jmattson@google.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit c5b7da51)
-
由 Jim Mattson 提交于
stable inclusion from stable-v5.10.154 commit cc40c5f3e9211523873c001d34e2f6695d57249b category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cc40c5f3e9211523873c001d34e2f6695d57249b -------------------------------- commit 079f6889 upstream. KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM actually supports. In the case of CPUID.8000001AH, only three bits are currently defined. The 125 reserved bits should be masked off. Fixes: 24c82e57 ("KVM: Sanitize cpuid") Signed-off-by: NJim Mattson <jmattson@google.com> Message-Id: <20220929225203.2234702-4-jmattson@google.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit f7e9643b)
-
由 Jim Mattson 提交于
stable inclusion from stable-v5.10.154 commit bd64a88f364cbe2e19b5f55be1cffef2b47bd0a5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bd64a88f364cbe2e19b5f55be1cffef2b47bd0a5 -------------------------------- commit eeb69eab upstream. KVM_GET_SUPPORTED_CPUID should only enumerate features that KVM actually supports. CPUID.80000006H:EDX[17:16] are reserved bits and should be masked off. Fixes: 43d05de2 ("KVM: pass through CPUID(0x80000006)") Signed-off-by: NJim Mattson <jmattson@google.com> Message-Id: <20220929225203.2234702-2-jmattson@google.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 4a3cecf6)
-
由 Helge Deller 提交于
stable inclusion from stable-v5.10.154 commit c9598cf629530823fd5d6c3342311895de504707 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=c9598cf629530823fd5d6c3342311895de504707 -------------------------------- commit 2b6ae096 upstream. Avoid that the hardware path is shown twice in the kernel log, and clean up the output of the version numbers to show up in the same order as they are listed in the hardware database in the hardware.c file. Additionally, optimize the memory footprint of the hardware database and mark some code as init code. Fixes: cab56b51 ("parisc: Fix device names in /proc/iomem") Signed-off-by: NHelge Deller <deller@gmx.de> Cc: <stable@vger.kernel.org> # v4.9+ Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit e0f691de)
-
由 Kan Liang 提交于
stable inclusion from stable-v5.10.154 commit 29d106d086d2f39f8635f402004d1c17a6205583 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=29d106d086d2f39f8635f402004d1c17a6205583 -------------------------------- commit 6f8faf47 upstream. The intel_pebs_isolation quirk checks both model number and stepping. Cooper Lake has a different stepping (11) than the other Skylake Xeon. It cannot benefit from the optimization in commit 9b545c04 ("perf/x86/kvm: Avoid unnecessary work in guest filtering"). Add the stepping of Cooper Lake into the isolation_ucodes[] table. Signed-off-by: NKan Liang <kan.liang@linux.intel.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221031154550.571663-1-kan.liang@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit af05d8ef)
-
由 Kan Liang 提交于
stable inclusion from stable-v5.10.154 commit 98f6e7c337036dff5a851f557950f5846d3f7d73 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=98f6e7c337036dff5a851f557950f5846d3f7d73 -------------------------------- commit acc5568b upstream. According to the latest event list, update the MEM_INST_RETIRED events which support the DataLA facility. Fixes: 60176089 ("perf/x86/intel: Add Icelake support") Reported-by: NJannis Klinkenberg <jannis.klinkenberg@rwth-aachen.de> Signed-off-by: NKan Liang <kan.liang@linux.intel.com> Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221031154119.571386-1-kan.liang@linux.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 6a9a09a5)
-
由 Cristian Marussi 提交于
stable inclusion from stable-v5.10.154 commit fc3e2fa0a5fb432927fed3f2cdfda22c41340c16 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=fc3e2fa0a5fb432927fed3f2cdfda22c41340c16 -------------------------------- [ Upstream commit c4a7b9b5 ] When thermnal zones are defined, trip points definitions are mandatory. Define a couple of critical trip points for monitoring of existing PMIC and SOC thermal zones. This was lost between txt to yaml conversion and was re-enforced recently via the commit 8c596324 ("dt-bindings: thermal: Fix missing required property") Cc: Rob Herring <robh+dt@kernel.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org> Cc: devicetree@vger.kernel.org Signed-off-by: NCristian Marussi <cristian.marussi@arm.com> Fixes: f7b636a8 ("arm64: dts: juno: add thermal zones for scpi sensors") Link: https://lore.kernel.org/r/20221028140833.280091-8-cristian.marussi@arm.comSigned-off-by: NSudeep Holla <sudeep.holla@arm.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 98f27aab)
-
由 Tim Harvey 提交于
stable inclusion from stable-v5.10.154 commit d7b1e2cbe0a467b300409ccd9008515bc18dceea category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=d7b1e2cbe0a467b300409ccd9008515bc18dceea -------------------------------- [ Upstream commit bb5ad739 ] The GW5910 and GW5913 have a user pushbutton that is tied to the Gateworks System Controller GPIO offset 2. Fix the invalid offset of 0. Fixes: 64bf0a0a ("ARM: dts: imx6qdl-gw: add Gateworks System Controller support") Signed-off-by: NTim Harvey <tharvey@gateworks.com> Signed-off-by: NShawn Guo <shawnguo@kernel.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 89cb436f)
-
由 Peter Oberparleiter 提交于
stable inclusion from stable-v5.10.154 commit 6b24d9c2acdac63cb161f677a86a4e380523cf46 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6b24d9c2acdac63cb161f677a86a4e380523cf46 -------------------------------- [ Upstream commit aa127a06 ] This patch enhances the kernel image adding a trailer as required for secure boot by future firmware versions. Cc: <stable@vger.kernel.org> # 5.2+ Signed-off-by: NPeter Oberparleiter <oberpar@linux.ibm.com> Reviewed-by: NSven Schnelle <svens@linux.ibm.com> Signed-off-by: NVasily Gorbik <gor@linux.ibm.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 53572566)
-
由 Alexander Graf 提交于
stable inclusion from stable-v5.10.154 commit 4dbb739eb29c99c8b59bbb7bbaa71ec1b438f37c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=4dbb739eb29c99c8b59bbb7bbaa71ec1b438f37c -------------------------------- [ Upstream commit 1739c701 ] The KVM_X86_SET_MSR_FILTER ioctls contains a pointer in the passed in struct which means it has a different struct size depending on whether it gets called from 32bit or 64bit code. This patch introduces compat code that converts from the 32bit struct to its 64bit counterpart which then gets used going forward internally. With this applied, 32bit QEMU can successfully set MSR bitmaps when running on 64bit kernels. Reported-by: NAndrew Randrianasulu <randrianasulu@gmail.com> Fixes: 1a155254 ("KVM: x86: Introduce MSR filtering") Signed-off-by: NAlexander Graf <graf@amazon.com> Message-Id: <20221017184541.2658-4-graf@amazon.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 28455b50)
-
由 Alexander Graf 提交于
stable inclusion from stable-v5.10.154 commit bb584caee8957469dfd7549dc7accdce806f23dd category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=bb584caee8957469dfd7549dc7accdce806f23dd -------------------------------- [ Upstream commit 2e3272bc ] In the next patch we want to introduce a second caller to set_msr_filter() which constructs its own filter list on the stack. Refactor the original function so it takes it as argument instead of reading it through copy_from_user(). Signed-off-by: NAlexander Graf <graf@amazon.com> Message-Id: <20221017184541.2658-3-graf@amazon.com> Cc: stable@vger.kernel.org Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 418a1835)
-
由 Aaron Lewis 提交于
stable inclusion from stable-v5.10.154 commit 9faacf442d11c872e7e2a66a6d1844459336dfb1 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9faacf442d11c872e7e2a66a6d1844459336dfb1 -------------------------------- [ Upstream commit cf5029d5 ] The flags for KVM_CAP_X86_USER_SPACE_MSR and KVM_X86_SET_MSR_FILTER have no protection for their unused bits. Without protection, future development for these features will be difficult. Add the protection needed to make it possible to extend these features in the future. Signed-off-by: NAaron Lewis <aaronlewis@google.com> Message-Id: <20220714161314.1715227-1-aaronlewis@google.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Stable-dep-of: 2e3272bc ("KVM: x86: Copy filter arg outside kvm_vm_ioctl_set_msr_filter()") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit 9c3c43a4)
-
由 Zhang Rui 提交于
stable inclusion from stable-v5.10.154 commit 5bdbccc79c86424fef1960de76abab9e83cfbdc9 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=5bdbccc79c86424fef1960de76abab9e83cfbdc9 -------------------------------- [ Upstream commit 71eac706 ] Today, core ID is assumed to be unique within each package. But an AlderLake-N platform adds a Module level between core and package, Linux excludes the unknown modules bits from the core ID, resulting in duplicate core ID's. To keep core ID unique within a package, Linux must include all APIC-ID bits for known or unknown levels above the core and below the package in the core ID. It is important to understand that core ID's have always come directly from the APIC-ID encoding, which comes from the BIOS. Thus there is no guarantee that they start at 0, or that they are contiguous. As such, naively using them for array indexes can be problematic. [ dhansen: un-known -> unknown ] Fixes: 7745f03e ("x86/topology: Add CPUID.1F multi-die/package support") Suggested-by: NLen Brown <len.brown@intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NLen Brown <len.brown@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221014090147.1836-5-rui.zhang@intel.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit d065f1f2)
-
由 Zhang Rui 提交于
stable inclusion from stable-v5.10.154 commit 6c31fc028a657e8d53cec5127a39a35cce6dba08 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=6c31fc028a657e8d53cec5127a39a35cce6dba08 -------------------------------- [ Upstream commit 2b12a7a1 ] CPUID.1F/B does not enumerate Package level explicitly, instead, all the APIC-ID bits above the enumerated levels are assumed to be package ID bits. Current code gets package ID by shifting out all the APIC-ID bits that Linux supports, rather than shifting out all the APIC-ID bits that CPUID.1F enumerates. This introduces problems when CPUID.1F enumerates a level that Linux does not support. For example, on a single package AlderLake-N, there are 2 Ecore Modules with 4 atom cores in each module. Linux does not support the Module level and interprets the Module ID bits as package ID and erroneously reports a multi module system as a multi-package system. Fix this by using APIC-ID bits above all the CPUID.1F enumerated levels as package ID. [ dhansen: spelling fix ] Fixes: 7745f03e ("x86/topology: Add CPUID.1F multi-die/package support") Suggested-by: NLen Brown <len.brown@intel.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com> Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com> Reviewed-by: NLen Brown <len.brown@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221014090147.1836-4-rui.zhang@intel.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit c73302dc)
-
由 Yazen Ghannam 提交于
stable inclusion from stable-v5.10.154 commit f5ad52da145a460b11d3a02a74c995fc33cce2f0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f5ad52da145a460b11d3a02a74c995fc33cce2f0 -------------------------------- [ Upstream commit cb09a379 ] CPUID Leaf 0x1F defines a DIE_TYPE level (nb: ECX[8:15] level type == 0x5), but CPUID Leaf 0xB does not. However, detect_extended_topology() will set struct cpuinfo_x86.cpu_die_id regardless of whether a valid Die ID was found. Only set cpu_die_id if a DIE_TYPE level is found. CPU topology code may use another value for cpu_die_id, e.g. the AMD NodeId on AMD-based systems. Code ordering should be maintained so that the CPUID Leaf 0x1F Die ID value will take precedence on systems that may use another value. Suggested-by: NBorislav Petkov <bp@alien8.de> Signed-off-by: NYazen Ghannam <yazen.ghannam@amd.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20201109210659.754018-5-Yazen.Ghannam@amd.com Stable-dep-of: 2b12a7a1 ("x86/topology: Fix multiple packages shown on a single-package system") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit e6bbde6c)
-
由 Sean Christopherson 提交于
stable inclusion from stable-v5.10.154 commit 570fa3bcd2f9328efc2123f8c46a50ea6b64b004 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=570fa3bcd2f9328efc2123f8c46a50ea6b64b004 -------------------------------- [ Upstream commit 5623f751 ] Add a dedicated "exception type" for #DBs, as #DBs can be fault-like or trap-like depending the sub-type of #DB, and effectively defer the decision of what to do with the #DB to the caller. For the emulator's two calls to exception_type(), treat the #DB as fault-like, as the emulator handles only code breakpoint and general detect #DBs, both of which are fault-like. For event injection, which uses exception_type() to determine whether to set EFLAGS.RF=1 on the stack, keep the current behavior of not setting RF=1 for #DBs. Intel and AMD explicitly state RF isn't set on code #DBs, so exempting by failing the "== EXCPT_FAULT" check is correct. The only other fault-like #DB is General Detect, and despite Intel and AMD both strongly implying (through omission) that General Detect #DBs should set RF=1, hardware (multiple generations of both Intel and AMD), in fact does not. Through insider knowledge, extreme foresight, sheer dumb luck, or some combination thereof, KVM correctly handled RF for General Detect #DBs. Fixes: 38827dbd ("KVM: x86: Do not update EFLAGS on faulting emulation") Cc: stable@vger.kernel.org Signed-off-by: NSean Christopherson <seanjc@google.com> Reviewed-by: NMaxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20220830231614.3580124-9-seanjc@google.comSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit dfdc32ea)
-
由 Sean Christopherson 提交于
stable inclusion from stable-v5.10.154 commit e5d7c6786befe4aca0ba645dc5b836fc60ea733c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e5d7c6786befe4aca0ba645dc5b836fc60ea733c -------------------------------- [ Upstream commit a61d7c54 ] Trace exceptions that are re-injected, not just those that KVM is injecting for the first time. Debugging re-injection bugs is painful enough as is, not having visibility into what KVM is doing only makes things worse. Delay propagating pending=>injected in the non-reinjection path so that the tracing can properly identify reinjected exceptions. Signed-off-by: NSean Christopherson <seanjc@google.com> Reviewed-by: NMaxim Levitsky <mlevitsk@redhat.com> Signed-off-by: NMaciej S. Szmigiero <maciej.szmigiero@oracle.com> Message-Id: <25470690a38b4d2b32b6204875dd35676c65c9f2.1651440202.git.maciej.szmigiero@oracle.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Stable-dep-of: 5623f751 ("KVM: x86: Treat #DBs from the emulator as fault-like (code and DR7.GD=1)") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit fff0a58b)
-
由 Sean Christopherson 提交于
stable inclusion from stable-v5.10.154 commit 8364786152d5abf887162612c23f932d8cda164f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8364786152d5abf887162612c23f932d8cda164f -------------------------------- [ Upstream commit def9d705 ] Don't propagate vmcs12's VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL to vmcs02. KVM doesn't disallow L1 from using VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL even when KVM itself doesn't use the control, e.g. due to the various CPU errata that where the MSR can be corrupted on VM-Exit. Preserve KVM's (vmcs01) setting to hopefully avoid having to toggle the bit in vmcs02 at a later point. E.g. if KVM is loading PERF_GLOBAL_CTRL when running L1, then odds are good KVM will also load the MSR when running L2. Fixes: 8bf00a52 ("KVM: VMX: add support for switching of PERF_GLOBAL_CTRL") Cc: stable@vger.kernel.org Signed-off-by: NSean Christopherson <seanjc@google.com> Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com> Link: https://lore.kernel.org/r/20220830133737.1539624-18-vkuznets@redhat.comSigned-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> (cherry picked from commit ad9e97af)
-
由 Sean Christopherson 提交于
stable inclusion from stable-v5.10.154 commit 523e1dd9f8d4d8cf064488473ef518c8dedcfeec category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCB Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=523e1dd9f8d4d8cf064488473ef518c8dedcfeec -------------------------------- [ Upstream commit 389ab252 ] When preparing controls for vmcs02, grab KVM's desired controls from vmcs01's shadow state instead of recalculating the controls from scratch, or in the secondary execution controls, instead of using the dedicated cache. Calculating secondary exec controls is eye-poppingly expensive due to the guest CPUID checks, hence the dedicated cache, but the other calculations aren't exactly free either. Explicitly clear several bits (x2APIC, DESC exiting, and load EFER on exit) as appropriate as they may be set in vmcs01, whereas the previous implementation relied on dynamic bits being cleared in the calculator. Intentionally propagate VM_{ENTRY,EXIT}_LOAD_IA32_PERF_GLOBAL_CTRL from vmcs01 to vmcs02. Whether or not PERF_GLOBAL_CTRL is loaded depends on whether or not perf itself is active, so unless perf stops between the exit from L1 and entry to L2, vmcs01 will hold the desired value. This is purely an optimization as atomic_switch_perf_msrs() will set/clear the control as needed at VM-Enter, i.e. it avoids two extra VMWRITEs in the case where perf is active (versus starting with the bits clear in vmcs02, which was the previous behavior). Cc: Zeng Guang <guang.zeng@intel.com> Signed-off-by: NSean Christopherson <seanjc@google.com> Message-Id: <20210810171952.2758100-3-seanjc@google.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Stable-dep-of: def9d705 ("KVM: nVMX: Don't propagate vmcs12's PERF_GLOBAL_CTRL settings to vmcs02") Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NLipeng Sang <sanglipeng1@jd.com> Conflicts: arch/x86/kvm/vmx/vmx.h (cherry picked from commit 63a8a234)
-
- 18 7月, 2023 1 次提交
-
-
由 Stephen Hemminger 提交于
stable inclusion from stable-v5.10.184 commit 1c004b379b0327992c1713334198cf5eba29a4ba category: bugfix bugzilla: 188948 CVE: CVE-2023-3338 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1c004b379b0327992c1713334198cf5eba29a4ba --------------------------- commit 1202cdd6 upstream. DECnet is an obsolete network protocol that receives more attention from kernel janitors than users. It belongs in computer protocol history museum not in Linux kernel. It has been "Orphaned" in kernel since 2010. The iproute2 support for DECnet was dropped in 5.0 release. The documentation link on Sourceforge says it is abandoned there as well. Leave the UAPI alone to keep userspace programs compiling. This means that there is still an empty neighbour table for AF_DECNET. The table of /proc/sys/net entries was updated to match current directories and reformatted to be alphabetical. Signed-off-by: NStephen Hemminger <stephen@networkplumber.org> Acked-by: NDavid Ahern <dsahern@kernel.org> Acked-by: NNikolay Aleksandrov <razor@blackwall.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com> (cherry picked from commit 44083b0c)
-
- 26 6月, 2023 2 次提交
-
-
由 Zhang Zekun 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7ASVH CVE: NA --------------------------------------- iova mag size will be iova_rcache size to 128, to support more concurrency in iova allocation, and can fix the problem dixcribe in bugzilla. Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
-
由 Ma Wupeng 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7F3NP CVE: NA -------------------------------- EFI_FAKE_MEMMAP is used specific memory range by updating original (firmware provided) EFI memmap. This can only be used for debug propose. Disable it by default. Signed-off-by: NMa Wupeng <mawupeng1@huawei.com> (cherry picked from commit 13ecd6fc)
-
- 25 6月, 2023 1 次提交
-
-
由 Zheng Zengkai 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ -------------------------------- 5a2451f1 ("x86/fpu: Avoid kabi change caused by struct fpu") will lead to performance degradation of libmicro pthread_create testcase. Assuming that no 3rd party driver will reach into struct fpu, replace kabi fix macro from KABI_DEPRECATE to KABI_BROKEN_REMOVE for element "union fpregs_state state" of struct fpu. Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com> (cherry picked from commit b60bbfca)
-
- 21 6月, 2023 1 次提交
-
-
由 Tong Tiangen 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7F28R CVE: NA -------------------------------- On Hisilicon LINXICORE9100 cores, sharing tlb entries on two cores when TTBRx.CNP=1 differs from the standard ARM core. This causes issues when tlb entries sharing between CPU cores. Avoid these issues by disabling CNP feature for Hisilicon LINXICORE9100 cores. Signed-off-by: NTong Tiangen <tongtiangen@huawei.com>
-
- 14 6月, 2023 1 次提交
-
-
由 Liu Jian 提交于
hulk inclusion category: feature bugzilla: NA CVE: N/A ---------------------------------------------------- Some network acceleration solutions, such as sockmap, are valid only for internal packets of the local host. The bpf_is_local_ipaddr() bpf helper function is added so that the ebpf program can determine whether a packet is an internal packet of the local host. Signed-off-by: NLiu Jian <liujian56@huawei.com>
-
- 13 6月, 2023 1 次提交
-
-
由 Xiang Chen 提交于
driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7C103 -------------------------------------------------------------------------- When enabled GICv4.1 in hip09, there are some invalid vPE configurations in configuration table for some situations, which will cause some vSGI interrupts lost. To fix the issue, need to send vinvall command after vmovp. Signed-off-by: NNianyao Tang <tangnianyao@huawei.com> Signed-off-by: NXiang Chen <chenxiang66@hisilicon.com> Signed-off-by: NCaiJian <caijian11@h-partners.com>
-
- 09 6月, 2023 1 次提交
-
-
由 Yu Liao 提交于
openeuler inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I77UDW CVE: NA -------------------------------- Support ACPI for MPAM 2.0 [1]. Compatible with MPAM ACPI 1.0 by reading ACPI revision. [1] https://developer.arm.com/documentation/den0065/latestSigned-off-by: NYu Liao <liaoyu15@huawei.com>
-
- 08 6月, 2023 3 次提交
-
-
由 Stefan Metzmacher 提交于
stable inclusion from stable-v5.10.162 commit f0a5f0dc0131c6483908601f6e4907befb609c97 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6LQMS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=f0a5f0dc0131c6483908601f6e4907befb609c97 -------------------------------- [ Upstream commit 50b7b6f2 ] As io_threads are fully set up USER threads it's clearer to separate the code path from the KTHREAD logic. The only remaining difference to user space threads is that io_threads never return to user space again. Instead they loop within the given worker function. The fact that they never return to user space means they don't have an user space thread stack. In order to indicate that to tools like gdb we reset the stack and instruction pointers to 0. This allows gdb attach to user space processes using io-uring, which like means that they have io_threads, without printing worrying message like this: warning: Selected architecture i386:x86-64 is not compatible with reported target architecture i386 warning: Architecture rejected target-supplied description The output will be something like this: (gdb) info threads Id Target Id Frame * 1 LWP 4863 "io_uring-cp-for" syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38 2 LWP 4864 "iou-mgr-4863" 0x0000000000000000 in ?? () 3 LWP 4865 "iou-wrk-4863" 0x0000000000000000 in ?? () (gdb) thread 3 [Switching to thread 3 (LWP 4865)] #0 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () Backtrace stopped: Cannot access memory at address 0x0 Fixes: 4727dc20 ("arch: setup PF_IO_WORKER threads like PF_KTHREAD") Link: https://lore.kernel.org/io-uring/044d0bad-6888-a211-e1d3-159a4aeed52d@polymtl.ca/T/#m1bbf5727e3d4e839603f6ec7ed79c7eebfba6267Signed-off-by: NStefan Metzmacher <metze@samba.org> cc: Linus Torvalds <torvalds@linux-foundation.org> cc: Jens Axboe <axboe@kernel.dk> cc: Andy Lutomirski <luto@kernel.org> cc: linux-kernel@vger.kernel.org cc: io-uring@vger.kernel.org cc: x86@kernel.org Link: https://lore.kernel.org/r/20210505110310.237537-1-metze@samba.orgReviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 6e14bf4c)
-
由 Jens Axboe 提交于
stable inclusion from stable-v5.10.162 commit dd26e2cec74f88cb7910deec77897d04ade299bd category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6LQMS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=dd26e2cec74f88cb7910deec77897d04ade299bd -------------------------------- [ Upstream commit 0100e6bb ] In the arch addition of PF_IO_WORKER, I missed parisc and powerpc for some reason. Fix that up, ensuring they handle PF_IO_WORKER like they do PF_KTHREAD in copy_thread(). Reported-by: NBruno Goncalves <bgoncalv@redhat.com> Fixes: 4727dc20 ("arch: setup PF_IO_WORKER threads like PF_KTHREAD") Signed-off-by: NJens Axboe <axboe@kernel.dk> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 820fe456)
-
由 Jens Axboe 提交于
stable inclusion from stable-v5.10.162 commit 320c8057eceb18c5d836fcbe0ffb0035fcfe28ff category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6LQMS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=320c8057eceb18c5d836fcbe0ffb0035fcfe28ff -------------------------------- PF_IO_WORKER are kernel threads too, but they aren't PF_KTHREAD in the sense that we don't assign ->set_child_tid with our own structure. Just ensure that every arch sets up the PF_IO_WORKER threads like kthreads in the arch implementation of copy_thread(). Signed-off-by: NJens Axboe <axboe@kernel.dk> Conflict: arch/s390/kernel/process.c arch/x86/kernel/process.c Signed-off-by: NLi Lingfeng <lilingfeng3@huawei.com> (cherry picked from commit 5b0c03b1)
-
- 07 6月, 2023 4 次提交
-
-
由 Zeng Heng 提交于
hulk inclusion category: bugfix issue: https://gitee.com/openeuler/kernel/issues/I69VF6 -------------------------------- If kdump is enabled, when using mce_inject to inject errors, EFI boot loader would decompress & load second kernel for saving the vmcore file. For normal errors that is fine. However, in the MCE case, the panic CPU that firstly enters into mce_panic() is running within NMI interrupt context, and the processor blocks delivery of subsequent NMIs until the next execution of the IRET instruction. When the panic CPU takes long time in the panic processing route, and causes the watchdog timeout, at this moment, the processor already receives NMI interrupt in the background. In the reproducer sequence below, panic CPU would run into EFI loader and raise page fault exception (like visiting `vidmem` variable when attempting to call debug_putstr()), the CPU would execute IRET instruction when it exits from the page fault handler. But the loader never registers handler for NMI vector in IDT, lack of vector handler would cause reboot, which interrupts kdump procedure and fails to save the vmcore file. Here is steps to reproduce the above issue (it's sporadic): 1. # cat uncorrected CPU 1 BANK 4 STATUS uncorrected 0xc0 MCGSTATUS EIPV MCIP ADDR 0x1234 RIP 0xdeadbabe RAISINGCPU 0 MCGCAP SER CMCI TES 0x6 2. # modprobe mce_inject 3. # mce-inject uncorrected For increasing the probability of reproduction of this issue, there are two ways to increase the probability of the bug: 1. modify the threshold value of watchdog (increase NMI frequency); 2. and/or add delays before panic() in mce_panic() and modify PANIC_TIMEOUT macro; Fixes: ca0e22d4 ("x86/boot/compressed/64: Always switch to own page table") Signed-off-by: NZeng Heng <zengheng4@huawei.com> [ Tidy up changelog, add comments. ] Signed-off-by: NIngo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20230110102745.2514694-1-zengheng4@huawei.com (cherry picked from commit 28410785)
-
由 Chen Zhongjin 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6DK3O CVE: NA -------------------------------- check_paravirt() calls orc_find() before its implementation code. If CONFIG_DYNAMIC_FTRACE is enabled, orc_find() will be declared earlier and compiling will not fail. Otherwise it will fail for "implicit declaration of function 'orc_find'". Move declaration of orc_find() out of CONFIG_DYNAMIC_FTRACE macro to fix this. Fixes: cbb12ea4718a ("[Huawei] x86/unwind: Fix orc entry for paravirt {save,restore}_fl") Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> (cherry picked from commit 78380898)
-
由 Chen Zhongjin 提交于
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I6DK3O CVE: NA -------------------------------- When CONFIG_PARAVIRT_XXL is enabled, the code of {save,restore}_fl is defined as: ff 14 25 00 00 00 00 callq *0x0 which will be patched to call the xen paravirt function, or native implementation, in 'paravirt_patch_64.c': pushfq; popq %rax // for native_save_fl pushq %rdi; popfq // for native_restore_fl The orc metadata is generated with insn 'callq', so it can become inconsistent with the real insn 'push;pop'. This makes stacktrace on the 'pop' insn fail and incorrect stacktrace result can be returned. To prevent reliable stacktrace broken, check the insns when unwind pt_regs stack frame: When there are 'push;pop' combination and both insns don't change orc entry, it means the stack state is inconsistent with orc on pop. Add one slot to sp_offset for on original orc entry to get the correct orc entry. Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> (cherry picked from commit cd5fe777)
-
由 Wei Li 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I7BAJ0 -------------------------------- EulerFS was introduced as a technical preview feature in the 21.09 innovation version. Considering the current discontinuation of Intel Optane hardware and immature ecosystem, it has been decided to turn it off in the 22.03 LTS version. It will continue to evolve as an innovative feature in future innovation versions. Signed-off-by: NWei Li <liwei391@huawei.com> (cherry picked from commit 42e496a1)
-
- 03 6月, 2023 1 次提交
-
-
由 Liu Jian 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I79J3X CVE: N/A ---------------------------------------------------- It is already enabled by default on the x86 and loongarch platforms, so let's enable it on the arm64 platform. Signed-off-by: NLiu Jian <liujian56@huawei.com> Reviewed-by: NWei Yongjun <weiyongjun1@huawe.com> (cherry picked from commit ace86952)
-
- 02 6月, 2023 2 次提交
-
-
由 Yang Yingliang 提交于
hulk inclusion category: performance bugzilla: https://gitee.com/openeuler/kernel/issues/I7ADMY -------------------------------- Enable MITIGATION_FALSE_SHARING by default on x86 and arm64 Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
-
由 Yanan Wang 提交于
mainline inclusion from mainline-v5.19-rc1 commit b2c4caf3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I78WD0 ------------------------------------------------- Currently, the bitfield of HWCAP2_WFXT is (1 << 23) inconsistent with mainline set (1UL << 31). To avoid possible uapi break, keep the bitfield consistent with mainline. Signed-off-by: NYanan Wang <wangyanan55@huawei.com> (cherry picked from commit c0da3054)
-
- 30 5月, 2023 1 次提交
-
-
由 xiongzhou4 提交于
GCC inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I734PM --------------------------------- This feature add value profile support for kernel by changing GCOV option "-fprofile-arcs" to "-fprofile-generate" when the new added config "PGO_KERNEL" is set to y. Like GCOV, the symbols required by value profile are migrated from GCC source codes as they cannot be linked to kernel. Specifically, from libgcc/libgcov-profiler.c to kernel/gcov/gcc_base.c. kernel options: CONFIG_PGO_KERNEL=y Signed-off-by: NXiong Zhou <xiongzhou4@huawei.com> Reviewed-by: NLi Yancheng <liyancheng@huawei.com>
-