- 21 7月, 2022 12 次提交
-
-
由 Qiuxu Zhuo 提交于
mainline inclusion from mainline-v5.14-rc1 commit 4bd4d32e category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel-SIG: commit 4bd4d32e EDAC/i10nm: Add detection of memory levels for ICX/SPR servers. Backport to add EDAC 2LM support. -------------------------------- Current i10nm_edac driver is only for system configured in 1-level memory. If the system is configured in 2-level memory, the driver doesn't report the 1st level memory DIMM for the error address, even if the error occurs in the 1st level memory. Both Ice Lake servers and Sapphire Rapids servers can be configured in 2-level memory. Add detection of memory levels to i10nm_edac for the two kinds of servers so that the driver can report the 2nd level memory DIMM or the 1st level memory DIMM according to error source. Signed-off-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20210611170123.1057025-3-tony.luck@intel.comSigned-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Qiuxu Zhuo 提交于
mainline inclusion from mainline-v5.14-rc1 commit 2f4348e5 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel-SIG: commit 2f4348e5 EDAC/skx_common: Add new ADXL components for 2-level memory. Backport to add EDAC 2LM support. -------------------------------- Some Intel servers may configure memory in 2 levels, using fast "near" memory (e.g. DDR) as a cache for larger, slower, "far" memory (e.g. 3D X-point). In these configurations the BIOS ADXL address translation for an address in a 2-level memory range will provide details of both the "near" and far components. Current exported ADXL components are only for 1-level memory system or for 2nd level memory of 2-level memory system. So add new ADXL components for 1st level memory of 2-level memory system to fully support 2-level memory system and the detection of memory error source(1st level memory or 2nd level memory). Signed-off-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20210611170123.1057025-2-tony.luck@intel.comSigned-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Youquan Song 提交于
mainline inclusion from mainline-v5.15-rc1 commit cf4e6d52 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel-SIG: commit cf4e6d52 EDAC/i10nm: Retrieve and print retry_rd_err_log registers. Backport for EDAC retry_rd_err_log for ICX/SPR support. -------------------------------- Retrieve and print retry_rd_err_log registers like the earlier change: commit e80634a7 ("EDAC, skx: Retrieve and print retry_rd_err_log registers") This is a little trickier than on Skylake because of potential interference with BIOS use of the same registers. The default behavior is to ignore these registers. A module parameter retry_rd_err_log(default=0) controls the mode of operation: - 0=off : Default. - 1=bios : Linux doesn't reset any control bits, but just reports values. This is "no harm" mode, but it may miss reporting some data. - 2=linux: Linux tries to take control and resets mode bits, clears valid/UC bits after reading. This should be more reliable (especially if BIOS interference is reduced by disabling eMCA reporting mode in BIOS setup). Co-developed-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: NYouquan Song <youquan.song@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com> Link: https://lore.kernel.org/r/20210818175701.1611513-3-tony.luck@intel.comSigned-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Qiuxu Zhuo 提交于
mainline inclusion from mainline-v5.11-rc1 commit 479f58dd category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel_SIG: commit 479f58dd EDAC/i10nm: Add Intel Sapphire Rapids server support. Backport for add EDAC SPR suppporting. -------------------------------- The Sapphire Rapids CPU model shares the same memory controller architecture with Ice Lake server. There are some configurations different from Ice Lake server as below: - The device ID for configuration agent. - The size for per channel memory-mapped I/O. - The DDR5 memory support. So add the above configurations and the Sapphire Rapids CPU model ID for EDAC support. Signed-off-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Qiuxu Zhuo 提交于
mainline inclusion from mainline-v5.13 commit bc1c99a5 category: feature bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel_SIG: commit bc1c99a5 EDAC: Add DDR5 new memory type. Backport for EDAC enhancing & bug fix. -------------------------------- Add a new entry to 'enum mem_type' and a new string to 'edac_mem_types[]' for DDR5 new memory type. Signed-off-by: NQiuxu Zhuo <qiuxu.zhuo@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Naoya Horiguchi 提交于
mainline inclusion from mainline-v5.18-rc1 commit 046545a6 category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel-SIG: commit 046545a6 mm/hwpoison: fix error page recovered but reported "not recovered". Backport for MCA recovery enhancing & bug fix. -------------------------------- When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed. If the CMCI wins that race, the page is marked poisoned when uc_decode_notifier() calls memory_failure() and the machine check processing code finds the page already poisoned. It calls kill_accessing_process() to make sure a SIGBUS is sent. But returns the wrong error code. Console log looks like this: mce: Uncorrected hardware memory error in user-access at 3710b3400 Memory failure: 0x3710b3: recovery action for dirty LRU page: Recovered Memory failure: 0x3710b3: already hardware poisoned Memory failure: 0x3710b3: Sending SIGBUS to einj_mem_uc:361438 due to hardware memory corruption mce: Memory error not recovered kill_accessing_process() is supposed to return -EHWPOISON to notify that SIGBUS is already set to the process and kill_me_maybe() doesn't have to send it again. But current code simply fails to do this, so fix it to make sure to work as intended. This change avoids the noise message "Memory error not recovered" and skips duplicate SIGBUSs. [tony.luck@intel.com: reword some parts of commit message] Link: https://lkml.kernel.org/r/20220113231117.1021405-1-naoya.horiguchi@linux.dev Fixes: a3f5d80e ("mm,hwpoison: send SIGBUS with error virutal address") Signed-off-by: NNaoya Horiguchi <naoya.horiguchi@nec.com> Reported-by: NYouquan Song <youquan.song@intel.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Youquan Song 提交于
mainline inclusion from mainline-v5.17-rc1 commit 33761363 category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel-SIG: commit 33761363 x86/mce: Reduce number of machine checks taken during recovery. Backport for MCA recovery enhancing & bug fix. -------------------------------- When any of the copy functions in arch/x86/lib/copy_user_64.S take a fault, the fixup code copies the remaining byte count from %ecx to %edx and unconditionally jumps to .Lcopy_user_handle_tail to continue the copy in case any more bytes can be copied. If the fault was #PF this may copy more bytes (because the page fault handler might have fixed the fault). But when the fault is a machine check the original copy code will have copied all the way to the poisoned cache line. So .Lcopy_user_handle_tail will just take another machine check for no good reason. Every code path to .Lcopy_user_handle_tail comes from an exception fixup path, so add a check there to check the trap type (in %eax) and simply return the count of remaining bytes if the trap was a machine check. Doing this reduces the number of machine checks taken during synthetic tests from four to three. As well as reducing the number of machine checks, this also allows Skylake generation Xeons to recover some cases that currently fail. The is because REP; MOVSB is only recoverable when source and destination are well aligned and the byte count is large. That useless call to .Lcopy_user_handle_tail may violate one or more of these conditions and generate a fatal machine check. [ Tony: Add more details to commit message. ] [ bp: Fixup comment. Also, another tip patchset which is adding straight-line speculation mitigation changes the "ret" instruction to an all-caps macro "RET". But, since gas is case-insensitive, use "RET" in the newly added asm block already in order to simplify tip branch merging on its way upstream. ] Signed-off-by: NYouquan Song <youquan.song@intel.com> Signed-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Link: https://lore.kernel.org/r/YcTW5dh8yTGucDd+@agluck-desk2.amr.corp.intel.comSigned-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Tony Luck 提交于
mainline inclusion from mainline-v5.16-rc1 commit 69065847 category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel-SIG: commit 69065847 x86/mce: Drop copyin special case for #MC. Backport for MCA recovery enhancing & bug fix. -------------------------------- Fixes to the iterator code to handle faults that are not on page boundaries mean that the special case for machine check during copy from user is no longer needed. For a full list of those fixes, see the output of: git log --oneline v5.14 ^v5.13 -- lib/iov_iter.c Intel-SIG: commit 69065847 x86/mce: Drop copyin special case for #MC. backport for MCA recovery enhance and bug fix. Signed-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210818002942.1607544-4-tony.luck@intel.comSigned-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Al Viro 提交于
mainline inclusion from mainline-v5.13 commit bc1bb416 category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel-SIG: commit bc1bb416 generic_perform_write()/iomap_write_actor(): saner logics for short copy. Backport for MCA recovery enhance and bug fix. -------------------------------- if we run into a short copy and ->write_end() refuses to advance at all, use the amount we'd managed to copy for the next iteration to handle. Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk> Signed-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Tony Luck 提交于
mainline inclusion from mainline-v5.16-rc1 commit a6e3cf70 category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel-SIG: commit a6e3cf70 x86/mce: Change to not send SIGBUS error during copy from user. Backport for MCA recovery enhance and bug fix. -------------------------------- Sending a SIGBUS for a copy from user is not the correct semantic. System calls should return -EFAULT (or a short count for write(2)). Signed-off-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20210818002942.1607544-3-tony.luck@intel.comSigned-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Naoya Horiguchi 提交于
mainline inclusion from mainline-v5.14-rc1 commit a3f5d80e category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel-SIG: commit a3f5d80e mm,hwpoison: send SIGBUS with error virutal address. Backport for MCA recovery enhancing & bug fix. -------------------------------- Now an action required MCE in already hwpoisoned address surely sends a SIGBUS to current process, but the SIGBUS doesn't convey error virtual address. That's not optimal for hwpoison-aware applications. To fix the issue, make memory_failure() call kill_accessing_process(), that does pagetable walk to find the error virtual address. It could find multiple virtual addresses for the same error page, and it seems hard to tell which virtual address is correct one. But that's rare and sending incorrect virtual address could be better than no address. So let's report the first found virtual address for now. [naoya.horiguchi@nec.com: fix walk_page_range() return] Link: https://lkml.kernel.org/r/20210603051055.GA244241@hori.linux.bs1.fc.nec.co.jp Link: https://lkml.kernel.org/r/20210521030156.2612074-4-nao.horiguchi@gmail.comSigned-off-by: NNaoya Horiguchi <naoya.horiguchi@nec.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Aili Yao <yaoaili@kingsoft.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: David Hildenbrand <david@redhat.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Jue Wang <juew@google.com> Cc: Borislav Petkov <bp@suse.de> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NYouquan Song <youquan.song@intel.com>
-
由 Naoya Horiguchi 提交于
mainline inclusion from mainline-v5.13 commit ea6d0630 category: bugfix bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5HAC1 CVE: NA Intel_SIG: commit ea6d0630 mm/hwpoison: do not lock page again when me_huge_page() successfully recovers. Backport for MCA recovery enhancing & bug fix. -------------------------------- Currently me_huge_page() temporary unlocks page to perform some actions then locks it again later. My testcase (which calls hard-offline on some tail page in a hugetlb, then accesses the address of the hugetlb range) showed that page allocation code detects this page lock on buddy page and printed out "BUG: Bad page state" message. check_new_page_bad() does not consider a page with __PG_HWPOISON as bad page, so this flag works as kind of filter, but this filtering doesn't work in this case because the "bad page" is not the actual hwpoisoned page. So stop locking page again. Actions to be taken depend on the page type of the error, so page unlocking should be done in ->action() callbacks. So let's make it assumed and change all existing callbacks that way. Link: https://lkml.kernel.org/r/20210609072029.74645-1-nao.horiguchi@gmail.com Fixes: commit 78bb9203 ("mm: hwpoison: dissolve in-use hugepage in unrecoverable memory error") Signed-off-by: NNaoya Horiguchi <naoya.horiguchi@nec.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tony Luck <tony.luck@intel.com> Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NYouquan Song <youquan.song@intel.com>
-
- 06 7月, 2022 28 次提交
-
-
由 Marc Zyngier 提交于
mainline inclusion from mainline-v5.19-rc1 commit c48c8b82 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5F4TK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c48c8b829d2b966a6649827426bcdba082ccf922 -------------------------------- Although setting the affinity of an interrupt to a set of CPUs that doesn't have any online CPU is generally frowned apon, there are a few limited cases where such affinity is set from a CPUHP notifier, setting the affinity to a CPU that isn't online yet. The saving grace is that this is always done using the 'force' attribute, which gives a hint that the affinity setting can be outside of the online CPU mask and the callsite set this flag with the knowledge that the underlying interrupt controller knows to handle it. This restores the expected behaviour on Marek's system. Fixes: 33de0aa4 ("genirq: Always limit the affinity to online CPUs") Reported-by: NMarek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NMarek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/4b7fc13c-887b-a664-26e8-45aed13f048a@samsung.com Link: https://lore.kernel.org/r/20220414140011.541725-1-maz@kernel.orgSigned-off-by: NChen Jiahao <chenjiahao16@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Reviewed-by: NLiao Chang <liaochang1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Marc Zyngier 提交于
mainline inclusion from mainline-v5.19-rc1 commit 3f893a59 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5F4TK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3f893a5962d31c0164efdbf6174ed0784f1d7603 -------------------------------- Now that the core code has been fixed to always give us an affinity that only includes online CPUs, directly use this affinity when computing a target CPU. Signed-off-by: NMarc Zyngier <maz@kernel.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220405185040.206297-4-maz@kernel.orgSigned-off-by: NChen Jiahao <chenjiahao16@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Reviewed-by: NLiao Chang <liaochang1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Marc Zyngier 提交于
mainline inclusion from mainline-v5.19-rc1 commit 33de0aa4 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5F4TK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33de0aa4bae982ed6f7c777f86b5af3e627ac937 -------------------------------- When booting with maxcpus=<small number> (or even loading a driver while most CPUs are offline), it is pretty easy to observe managed affinities containing a mix of online and offline CPUs being passed to the irqchip driver. This means that the irqchip cannot trust the affinity passed down from the core code, which is a bit annoying and requires (at least in theory) all drivers to implement some sort of affinity narrowing. In order to address this, always limit the cpumask to the set of online CPUs. Signed-off-by: NMarc Zyngier <maz@kernel.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20220405185040.206297-3-maz@kernel.org conflict: kernel/irq/manage.c Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Reviewed-by: NLiao Chang <liaochang1@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Marc Zyngier 提交于
mainline inclusion from mainline-v5.19-rc1 commit d802057c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I5F4TK CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d802057c7c553ad426520a053da9f9fe08e2c35a -------------------------------- When booting with maxcpus=<small number>, interrupt controllers such as the GICv3 ITS may not be able to satisfy the affinity of some managed interrupts, as some of the HW resources are simply not available. The same thing happens when loading a driver using managed interrupts while CPUs are offline. In order to deal with this, do not try to activate such interrupt if there is no online CPU capable of handling it. Instead, place it in shutdown state. Once a capable CPU shows up, it will be activated. Reported-by: NJohn Garry <john.garry@huawei.com> Reported-by: NDavid Decotigny <ddecotig@google.com> Signed-off-by: NMarc Zyngier <maz@kernel.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Tested-by: NJohn Garry <john.garry@huawei.com> Link: https://lore.kernel.org/r/20220405185040.206297-2-maz@kernel.org conflict: kernel/irq/msi.c Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com> Reviewed-by: NZhang Jianhua <chris.zjh@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Add klp_module_delete_safety_check for calltrace check during module deletion to avoid unsafe resource release. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Add arch_klp_module_check_calltrace to check whether stacks of all tasks are within the code segment of module. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- The calltrace check code is independent as do_check_calltrace, for calltrace check of module. No functional change. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Add arch_klp_module_check_calltrace to check whether stacks of all tasks are within the code segment of module. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- The calltrace check code is independent as do_check_calltrace, for calltrace check of module. No functional change. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Add arch_klp_module_check_calltrace to check whether stacks of all tasks are within the code segment of module. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- The calltrace check code is independent as do_check_calltrace, for calltrace check of module. No functional change. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Add arch_klp_module_check_calltrace to check whether stacks of all tasks are within the code segment of module. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- The calltrace check code is independent as do_check_calltrace, for calltrace check of module. No functional change. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Add arch_klp_module_check_calltrace to check whether stacks of all tasks are within the code segment of module. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- The calltrace check code is independent as do_check_calltrace, for calltrace check of klp module. No functional change. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Add breakpoint exception optimization support to improve livepatch success rate for ppc64/ppc32. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Signed-off-by: NLi Huafei <lihuafei1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- A trampoline needs to be created before adding a breakpoint for PPC64. Change livepatch_create_btamp to a public function and delete redundant input parameter "struct module *me". Fix an issue where the branch stub of livepatch is not created if address of the modified function is a branch function. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Add breakpoint exception optimization support to improve livepatch success rate for arm. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Add breakpoint exception optimization support to improve livepatch success rate for arm64. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yang Jihong 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- For the ARM architecture, need to register the callback function for processing BRK exception in advance. Therefore, the architecture-related init interface needs to be provided. Signed-off-by: NYang Jihong <yangjihong1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Li Huafei 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Implement the arch_klp_{check, add, remove}_breakpoint interface to support breakpoint exception optimization. Signed-off-by: NLi Huafei <lihuafei1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Li Huafei 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- The commit 86e35fae ("livepatch: checks only if the replaced instruction is on the stack") optimizes stack checking. However, for extremely hot functions, the replaced instruction may still be on the stack, and there is room for further optimization. By inserting a breakpoint exception instruction at the entry of the patched old function, we can divert calls from the old function to the new function. In this way, during stack check, only tasks that have entered the old function before the breakpoint is inserted need to be considered. This increases the probability of passing the stack check. If the stack check fails, we sleep for a period of time and try again, giving the task entering the old function a chance to run out of the instruction replacement area. We first enable the patch using the normal process, that is, do not insert breakpoints. If the first enable fails and the force flag KLP_STACK_OPTIMIZE is set for all functions of the patch, then we use breakpoint exception optimization. Signed-off-by: NLi Huafei <lihuafei1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Li Huafei 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- klp_find_func_node() is used to traverse the klp_func_list linked list. Currently, klp_find_func_node() is used only when the klp_mutex lock is held. In the subsequent submission, we need to access the klp_func_list linked list in the exception handling process and cannot hold the klp_mutex lock. We change the traversal of klp_func_list to use the rcu interface and perform rcu synchronization when deleting nodes. Signed-off-by: NLi Huafei <lihuafei1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Li Huafei 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Delete the duplicate code of klp_compare_address() in each arch. Signed-off-by: NLi Huafei <lihuafei1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Li Huafei 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- Currently, arch_klp_code_modify_{prepare, post_process} is implemented only in the x86 architecture. It is used to hold the 'text_mutex' lock before entering the stop_machine and modifying the code, and to release the lock after exiting the stop_machine. klp_mem_prepare() needs to hold the 'text_mutex' lock only when saving old instruction code on x86 to ensure that it holds valid instructions. Place klp_mem_prepare() before arch_klp_code_modify_prepare() and lock the save instruction action separately to narrow the 'text_mutex' lock. Signed-off-by: NLi Huafei <lihuafei1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Li Huafei 提交于
hulk inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5CJ7X -------------------------------- When klp_mem_prepare() fails, the requested resources are not cleared. We'd better clean up each newly requested resource upon error return. Signed-off-by: NLi Huafei <lihuafei1@huawei.com> Reviewed-by: NXu Kuohai <xukuohai@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 luhuaxin 提交于
euleros inclusion category: feature bugzilla: https://gitee.com/openeuler/kernel/issues/I5ETJZ CVE: NA -------- openeuler openssl now supports SM certificate. The type of key should be set to EVP_PKEY_SM2 before using. Signed-off-by: Nluhuaxin <luhuaxin1@huawei.com> Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Hyeonggon Yoo 提交于
mainline inclusion from mainline-v5.18-rc7 commit 2839b099 category: bugfix bugzilla: 187071, https://gitee.com/openeuler/kernel/issues/I5DLA7 CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2839b0999c20c9f6bf353849c69370e121e2fa1a -------------------------------- When kfence fails to initialize kfence pool, it frees the pool. But it does not reset memcg_data and PG_slab flag. Below is a BUG because of this. Let's fix it by resetting memcg_data and PG_slab flag before free. [ 0.089149] BUG: Bad page state in process swapper/0 pfn:3d8e06 [ 0.089149] page:ffffea46cf638180 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3d8e06 [ 0.089150] memcg:ffffffff94a475d1 [ 0.089150] flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) [ 0.089151] raw: 0017ffffc0000200 ffffea46cf638188 ffffea46cf638188 0000000000000000 [ 0.089152] raw: 0000000000000000 0000000000000000 00000000ffffffff ffffffff94a475d1 [ 0.089152] page dumped because: page still charged to cgroup [ 0.089153] Modules linked in: [ 0.089153] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G B W 5.18.0-rc1+ #965 [ 0.089154] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [ 0.089154] Call Trace: [ 0.089155] <TASK> [ 0.089155] dump_stack_lvl+0x49/0x5f [ 0.089157] dump_stack+0x10/0x12 [ 0.089158] bad_page.cold+0x63/0x94 [ 0.089159] check_free_page_bad+0x66/0x70 [ 0.089160] __free_pages_ok+0x423/0x530 [ 0.089161] __free_pages_core+0x8e/0xa0 [ 0.089162] memblock_free_pages+0x10/0x12 [ 0.089164] memblock_free_late+0x8f/0xb9 [ 0.089165] kfence_init+0x68/0x92 [ 0.089166] start_kernel+0x789/0x992 [ 0.089167] x86_64_start_reservations+0x24/0x26 [ 0.089168] x86_64_start_kernel+0xa9/0xaf [ 0.089170] secondary_startup_64_no_verify+0xd5/0xdb [ 0.089171] </TASK> Link: https://lkml.kernel.org/r/YnPG3pQrqfcgOlVa@hyeyoo Fixes: 0ce20dd8 ("mm: add Kernel Electric-Fence infrastructure") Fixes: 8f0b3649 ("mm: kfence: fix objcgs vector allocation") Signed-off-by: NHyeonggon Yoo <42.hyeyoo@gmail.com> Reviewed-by: NMarco Elver <elver@google.com> Reviewed-by: NMuchun Song <songmuchun@bytedance.com> Cc: Alexander Potapenko <glider@google.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Conflicts: mm/kfence/core.c Signed-off-by: NLiu Shixin <liushixin2@huawei.com> Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-