Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 22 8月, 2023 4 次提交
  3. 14 8月, 2023 2 次提交
  5. 09 8月, 2023 3 次提交
  7. 07 8月, 2023 1 次提交
    • W
      Revert "arm64/mpam: Fix mpam corrupt when cpu online" · 24cd9639
      由 Wang ShaoBo 提交于 
      hulk inclusion
category: bugfix
bugzilla: 189067, https://gitee.com/openeuler/kernel/issues/I7PN0A
CVE: NA

-------------------------------------------------

BUG 'sleeping function called from invalid context' reported when
setup MPAM driver, it was blamed to bc9e3f98 ("arm64/mpam:
Fix mpam corrupt when cpu online"), which reported a 'Bad PC' BUG,
but missing the right conclusion, finally disabling irqs before calling
cpuhp_setup_state() may only affect the probability of reproduction.

The reason why triggerring 'Bad PC' BUG report is because mpam_enable()
is __init type function, and may schedule out after calling
__cpuhp_setup_state()->__might_sleep(), so the space of mpam_enable()
might be freed after scheduling back.

As we have changed mpam_enable() to non-init type function, we can
revert commit bc9e3f98 directly, to solve these both two problems.

Fixes: bc9e3f98 ("arm64/mpam: Fix mpam corrupt when cpu online")
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
      24cd9639
  9. 04 8月, 2023 1 次提交
  11. 18 7月, 2023 1 次提交
  13. 29 6月, 2023 1 次提交
  15. 26 6月, 2023 1 次提交
  17. 21 6月, 2023 2 次提交
  19. 08 6月, 2023 3 次提交
  21. 07 6月, 2023 3 次提交
    • C
      x86/unwind: Fix check_paravirt() calls orc_find() before declaration · 9bfac9dd
      由 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)
      9bfac9dd
    • C
      x86/unwind: Fix orc entry for paravirt {save,restore}_fl · 809dab53
      由 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)
      809dab53
    • W
      config: Disable CONFIG_EULER_FS by default · 93804c69
      由 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)
      93804c69
  23. 06 6月, 2023 3 次提交
  25. 05 6月, 2023 3 次提交
  27. 30 5月, 2023 3 次提交
  29. 23 5月, 2023 1 次提交
  31. 20 5月, 2023 5 次提交
    • H
      LoongArch: defconfig: enable CONFIG_CACHEFILES · d58e3093
      由 Hongchen Zhang 提交于 
      LoongArch inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7362E

--------------------------------

enable cachefiles module, used by cachefilesd service.
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>
Change-Id: I2c7a60b51e5c3a656b0821d6be9e505f1f9e6768
(cherry picked from commit 850defab)
      d58e3093
    • H
      LoongArch: Set _PAGE_DIRTY only if _PAGE_MODIFIED is set in {pmd,pte}_mkwrite() · 7977bb26
      由 Huacai Chen 提交于 
      mainline inclusion
from mainline-v6.1-rc7
commit 54e6cd42
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7362E
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/loongarch?id=54e6cd42a183b602e3627ad3aaeeed44f7443e67

--------------------------------

Set _PAGE_DIRTY only if _PAGE_MODIFIED is set in {pmd,pte}_mkwrite().
Otherwise, _PAGE_DIRTY silences the TLB modify exception and make us
have no chance to mark a pmd/pte dirty (_PAGE_MODIFIED) for software.
Reviewed-by: NGuo Ren <guoren@kernel.org>
Signed-off-by: NHuacai Chen <chenhuacai@loongson.cn>
Change-Id: I05f95f28b6c2a18c44b41f253a2f4cbb987521b9
(cherry picked from commit df87bdf6)
      7977bb26
    • H
      LoongArch: Set _PAGE_DIRTY only if _PAGE_WRITE is set in {pmd,pte}_mkdirty() · ecf8bc3e
      由 Huacai Chen 提交于 
      mainline inclusion
from mainline-v6.1-rc7
commit bf2f34a5
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7362E
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/loongarch?id=bf2f34a506e66e2979de6b17c337c5d4b25b4d2c

--------------------------------

Now {pmd,pte}_mkdirty() set _PAGE_DIRTY bit unconditionally, this causes
random segmentation fault after commit 0ccf7f16 ("mm/thp: carry
over dirty bit when thp splits on pmd").

The reason is: when fork(), parent process use pmd_wrprotect() to clear
huge page's _PAGE_WRITE and _PAGE_DIRTY (for COW); then pte_mkdirty() set
_PAGE_DIRTY as well as _PAGE_MODIFIED while splitting dirty huge pages;
once _PAGE_DIRTY is set, there will be no tlb modify exception so the COW
machanism fails; and at last memory corruption occurred between parent
and child processes.

So, we should set _PAGE_DIRTY only when _PAGE_WRITE is set in {pmd,pte}_
mkdirty().

Cc: stable@vger.kernel.org
Cc: Peter Xu <peterx@redhat.com>
Signed-off-by: NHuacai Chen <chenhuacai@loongson.cn>
Change-Id: Iade25111367c20f3cf777630e09eb6a10a62b6a8
(cherry picked from commit 1267d8f9)
      ecf8bc3e
    • H
      LoongArch: Clear FPU/SIMD thread info flags for kernel thread · 7c303a90
      由 Huacai Chen 提交于 
      mainline inclusion
from mainline-v6.1-rc7
commit e428e961
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7362E
CVE: NA

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/loongarch?id=e428e9613531d1ef6bd0d91352899712b29134fb

--------------------------------

If a kernel thread is created by a user thread, it may carry FPU/SIMD
thread info flags (TIF_USEDFPU, TIF_USEDSIMD, etc.). Then it will be
considered as a fpu owner and kernel try to save its FPU/SIMD context
and cause such errors:

[   41.518931] do_fpu invoked from kernel context![#1]:
[   41.523933] CPU: 1 PID: 395 Comm: iou-wrk-394 Not tainted 6.1.0-rc5+ #217
[   41.530757] Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.pre-beta8 08/18/2022
[   41.544064] $ 0   : 0000000000000000 90000000011e9468 9000000106c7c000 9000000106c7fcf0
[   41.552101] $ 4   : 9000000106305d40 9000000106689800 9000000106c7fd08 0000000003995818
[   41.560138] $ 8   : 0000000000000001 90000000009a72e4 0000000000000020 fffffffffffffffc
[   41.568174] $12   : 0000000000000000 0000000000000000 0000000000000020 00000009aab7e130
[   41.576211] $16   : 00000000000001ff 0000000000000407 0000000000000001 0000000000000000
[   41.584247] $20   : 0000000000000000 0000000000000001 9000000106c7fd70 90000001002f0400
[   41.592284] $24   : 0000000000000000 900000000178f740 90000000011e9834 90000001063057c0
[   41.600320] $28   : 0000000000000000 0000000000000001 9000000006826b40 9000000106305140
[   41.608356] era   : 9000000000228848 _save_fp+0x0/0xd8
[   41.613542] ra    : 90000000011e9468 __schedule+0x568/0x8d0
[   41.619160] CSR crmd: 000000b0
[   41.619163] CSR prmd: 00000000
[   41.622359] CSR euen: 00000000
[   41.625558] CSR ecfg: 00071c1c
[   41.628756] CSR estat: 000f0000
[   41.635239] ExcCode : f (SubCode 0)
[   41.638783] PrId  : 0014c010 (Loongson-64bit)
[   41.643191] Modules linked in: acpi_ipmi vfat fat ipmi_si ipmi_devintf cfg80211 ipmi_msghandler rfkill fuse efivarfs
[   41.653734] Process iou-wrk-394 (pid: 395, threadinfo=0000000004ebe913, task=00000000636fa1be)
[   41.662375] Stack : 00000000ffff0875 9000000006800ec0 9000000006800ec0 90000000002d57e0
[   41.670412]         0000000000000001 0000000000000000 9000000106535880 0000000000000001
[   41.678450]         9000000105291800 0000000000000000 9000000105291838 900000000178e000
[   41.686487]         9000000106c7fd90 9000000106305140 0000000000000001 90000000011e9834
[   41.694523]         00000000ffff0875 90000000011f034c 9000000105291838 9000000105291830
[   41.702561]         0000000000000000 9000000006801440 00000000ffff0875 90000000002d48c0
[   41.710597]         9000000128800001 9000000106305140 9000000105291838 9000000105291838
[   41.718634]         9000000105291830 9000000107811740 9000000105291848 90000000009bf1e0
[   41.726672]         9000000105291830 9000000107811748 2d6b72772d756f69 0000000000343933
[   41.734708]         0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   41.742745]         ...
[   41.745252] Call Trace:
[   42.197868] [<9000000000228848>] _save_fp+0x0/0xd8
[   42.205214] [<90000000011ed468>] __schedule+0x568/0x8d0
[   42.210485] [<90000000011ed834>] schedule+0x64/0xd4
[   42.215411] [<90000000011f434c>] schedule_timeout+0x88/0x188
[   42.221115] [<90000000009c36d0>] io_wqe_worker+0x184/0x350
[   42.226645] [<9000000000221cf0>] ret_from_kernel_thread+0xc/0x9c

This can be easily triggered by ltp testcase syscalls/io_uring02 and it
can also be easily fixed by clearing the FPU/SIMD thread info flags for
kernel threads in copy_thread().

Cc: stable@vger.kernel.org
Reported-by: NQi Hu <huqi@loongson.cn>
Signed-off-by: NHuacai Chen <chenhuacai@loongson.cn>
(cherry picked from commit dd318f86)
      7c303a90
    • J
      LoongArch: Remove generic irq migration · 72156ebc
      由 Jianmin Lv 提交于 
      LoongArch inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7362E

--------------------------------

Change-Id: I68a4dfac179ea2575925c3cd256e1179a5934c33
Signed-off-by: NJianmin Lv <lvjianmin@loongson.cn>
Signed-off-by: NJuxin Gao <gaojuxin@loongson.cn>
(cherry picked from commit f24b8441)
      72156ebc
  33. 18 5月, 2023 3 次提交
    • Y
      LoongArch: Fix kdump failure on v40 interface specification · 63dc7825
      由 Youling Tang 提交于 
      LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I736HO

--------------------------------

The old memory should be reserved after efi_runtime_init() to avoid destroying
the EFI space and causing failure when executing svam().

Fix the following problems when executing kdump:

[    0.000000] The BIOS Version: Loongson-UDK2018-V2.0.04082-beta7
[    0.000000] CPU 0 Unable to handle kernel paging request at virtual address 00000000fdeb0e7c, era == 00000000fdeb0e7c, ra == 90000000dae6585c
[    0.000000] Oops[#1]:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.137+ #86
[    0.000000] Hardware name: Loongson Loongson-3A5000-7A1000-1w-A2101/Loongson-LS3A5000-7A1000-1w-A2101, BIOS vUDK2018-LoongArch-V2.0.pre-beta8 06/15/2022
[    0.000000] $ 0   : 0000000000000000 90000000dae6585c 90000000db200000 90000000db203840
[    0.000000] $ 4   : 0000000000000078 0000000000000028 0000000000000001 00000000db203860
[    0.000000] $ 8   : 0000000000000000 0000000000000040 90000000db203680 0000000000000000
[    0.000000] $12   : 00000000fdeb0e7c ffffffffffffffc0 00000000fbffffff 0000000020000000
[    0.000000] $16   : 000000000003e780 0000000020000000 90000000dad8c348 0000000000003fff
[    0.000000] $20   : 0000000000000018 90000000dad8bdd0 90000000db203850 0000000000000040
[    0.000000] $24   : 000000000000000f 90000000db21a570 90000000daeb07a0 90000000db217000
[    0.000000] $28   : 90000000db203858 0000000001ffffff 90000000db2171b0 0000000000000040
[    0.000000] era   : 00000000fdeb0e7c 0xfdeb0e7c
[    0.000000] ra    : 90000000dae6585c set_virtual_map.isra.0+0x23c/0x394
[    0.000000] CSR crmd: 90000000db21a570
[    0.000000] CSR prmd: 00000000
[    0.000000] CSR euen: 00000000
[    0.000000] CSR ecfg: 90000000db203850
[    0.000000] CSR estat: 90000000dae65800
[    0.000000] ExcCode : 26 (SubCode 16b)
[    0.000000] PrId  : 0014c012 (Loongson-64bit)
[    0.000000] Modules linked in:
[    0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____))
[    0.000000] Stack : 0000000000000001 00000000fdeb0e7c 0000000000036780 000000000003e780
[    0.000000]         0000000000000006 0000000010000000 8000000010000000 0000000000010000
[    0.000000]         8000000000000001 0000000000000005 00000000fde40000 90000000fde40000
[    0.000000]         0000000000000100 800000000000000f 0000000000000006 00000000fdf40000
[    0.000000]         90000000fdf40000 0000000000000300 800000000000000f 00000000000000b0
[    0.000000]         0000000000000001 90000000da094cf0 0000000000000000 ffffffffffffffea
[    0.000000]         90000000db2039b8 ffff0a1000000609 0000000000000035 0000000000000030
[    0.000000]         90000000dad7b258 0000000000000400 00000000000000b0 ffff0a1000000609
[    0.000000]         90000000db2039a8 90000000db095730 000000007fffffff ffff0a1000000609
[    0.000000]         90000000db203a90 90000000db203a30 90000000db2039d8 90000000db09570b
[    0.000000]         ...
[    0.000000] Call Trace:
[    0.000000]
[    0.000000] Code: (Bad address in era)
[    0.000000]
[    0.000000]
Signed-off-by: NYouling Tang <tangyouling@loongson.cn>
Change-Id: I1cdf06f520fd16fa2c2dcc6b852d76d038771a86
(cherry picked from commit f45a5a99)
      63dc7825
    • Y
      LoongArch: configs: Enable kexec/kdump · 8cbcfa05
      由 Youling Tang 提交于 
      LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I736HO

--------------------------------
Signed-off-by: NYouling Tang <tangyouling@loongson.cn>
Change-Id: Ia09d55c506f16f622ed52c2e7e17d5c490635f7d
(cherry picked from commit 12d99260)
      8cbcfa05
    • Y
      LoongArch: kdump: Add crashkernel=YM handling · ae4bf227
      由 Youling Tang 提交于 
      LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I736HO

--------------------------------

When the kernel crashkernel parameter is specified with just a size,
we are supposed to allocate a region from RAM to store the crashkernel,
"crashkernel=512M" would be recommended for kdump.

Fix this by lifting similar code from x86, importing it to LoongArch
with LoongArch specific parameters added. We allocate the crashkernel
region from the first 4GB of physical memory (because SWIOTLB should be
allocated below 4GB). However, LoongArch currently does not implement
crashkernel_low and crashkernel_high the same as x86.

When X is not specified, crash_base defaults to 0 (crashkernel=YM@XM).
Signed-off-by: NYouling Tang <tangyouling@loongson.cn>
Change-Id: Id744bf55c2ccbe32e7d44eac8901b8849586baa3
(cherry picked from commit ab4bfe57)
      ae4bf227