Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 27 3月, 2022 2 次提交
  3. 15 3月, 2022 1 次提交
  5. 08 3月, 2022 7 次提交
    • T
      arm64: config: enable CONFIG_ARM64_UCE_KERNEL_RECOVERY · 042bf6a8
      由 Tong Tiangen 提交于 
      hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM10
CVE: NA

--------------------------------
Signed-off-by: NTong Tiangen <tongtiangen@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      042bf6a8
    • T
      arm64: ras: copy_from_user scenario support uce kernel recovery · 39a27d1e
      由 Tong Tiangen 提交于 
      hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM10
CVE: NA

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

During kernel copy_from_user processing, the kernel triggers a RAS
exception when reading pages. In this solution, we identify this
scenario in the kernel do_sea processing process, send SIGBUS signals
to the process that triggers copy_from_user and isolate memory pages,
preventing kernel panic.

At the same time, we use cmdline(uce_kernel_recovery) or proc
(/proc/sys/kernel/uce_kernel_recovery) to control this feature on/off.

Usage:
1. Each bit controls whether this feature is turned on in a scene,
    1 means turned on and 0 means turned off.
2. Bit2 represents copy_from_user scene, other bits are currently
    reserved.

eg: make copy_from_user scene open this feature:
1. echo 4 > /proc/sys/kernel/uce_kernel_recovery.
or
2. uce_kernel_recovery=4 add to cmdline.
Signed-off-by: NTong Tiangen <tongtiangen@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      39a27d1e
    • M
      efi: Fix efi_find_mirror redefine in x86 · 5f406a26
      由 Ma Wupeng 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S
CVE: NA

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

Commit cc3d801f ("efi: Make efi_find_mirror() public") add
efi_find_mirror() defination into linux/efi.h, but forget to
drop this in arch/x86/include/asm/efi.h, kill it.

Fixes: cc3d801f ("efi: Make efi_find_mirror() public")
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      5f406a26
    • W
      timekeeping: Avoiding false sharing in field access of tk_core · ee0afb75
      由 Wang ShaoBo 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I47W8L
CVE: NA

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

We detect a performance deterioration when using Unixbench, we use the dichotomy to
locate the patch 7e66740a ("MPAM / ACPI: Refactoring MPAM init process and set
MPAM ACPI as entrance"), In comparing two commit df5defd9 ("KVM: X86: MMU: Use
the correct inherited permissions to get shadow page") and ac4dbb75 ("ACPI 6.x:
Add definitions for MPAM table") we get following testing result:

CMD: ./Run -c xx context1
RESULT:
+-------------UnixBench context1-----------+
+---------+--------------+-----------------+
+         + ac4dbb75 +  df5defd9   +
+---------+--------------+---------+-------+
+  Cores  +    Score     +      Score      +
+---------+--------------+-----------------+
+    1    +    522.8     +      535.7      +
+---------+--------------+-----------------+
+   24    +   11231.5    +     12111.2     +
+---------+--------------+-----------------+
+   48    +   8535.1     +     8745.1      +
+---------+--------------+-----------------+
+   72    +   10821.9    +     10343.8     +
+---------+--------------+-----------------+
+   96    +   15238.5    +     42947.8     +
+---------+--------------+-----------------+

We found a irrefutable difference in latency sampling when using the perf tool:

HEAD:ac4dbb75                                   HEAD:df5defd9

45.18% [kernel] [k] ktime_get_coarse_real_ts64  ->  1.78% [kernel] [k] ktime_get_coarse_real_ts64
                                                                               ...
                                                                       65.87 │ dmb ishld //smp_rmb()

Through ftrace we get the calltrace and and detected the number of visits of
ktime_get_coarse_real_ts64, which frequently visits tk_core->seq and
tk_core->timekeeper->tkr_mono:

-   48.86%  [kernel]                 [k] ktime_get_coarse_real_ts64
   - 5.76% ktime_get_coarse_real_ts64   #about 111437657 times per 10 seconds
      - 14.70% __audit_syscall_entry
           syscall_trace_enter
           el0_svc_common
           el0_svc_handler
         + el0_svc
      - 2.85% current_time

So this may be performance degradation caused by interference when happened different
fields access, We compare .bss and .data section of this two version:

    HEAD:ac4dbb75
`->
    ffff00000962e680 l     O .bss   0000000000000110 tk_core
    ffff000009355680 l     O .data  0000000000000078 tk_fast_mono
    ffff0000093557a0 l     O .data  0000000000000090 dummy_clock
    ffff000009355700 l     O .data  0000000000000078 tk_fast_raw
    ffff000009355778 l     O .data  0000000000000028 timekeeping_syscore_ops
    ffff00000962e640 l     O .bss   0000000000000008 cycles_at_suspend

    HEAD:df5defd9
`->
    ffff00000957dbc0 l     O .bss   0000000000000110 tk_core
    ffff0000092b4e80 l     O .data  0000000000000078 tk_fast_mono
    ffff0000092b4fa0 l     O .data  0000000000000090 dummy_clock
    ffff0000092b4f00 l     O .data  0000000000000078 tk_fast_raw
    ffff0000092b4f78 l     O .data  0000000000000028 timekeeping_syscore_ops
    ffff00000957db80 l     O .bss   0000000000000008 cycles_at_suspend

By comparing this two version tk_core's address: ffff00000962e680 is 128Byte aligned
but latter df5defd9 is 64Byte aligned, the memory storage layout of tk_core has
undergone subtle changes:

    HEAD:ac4dbb75
`->                     |<--------formmer 64Bytes---------->|<------------latter 64Byte------------->|
    0xffff00000957dbc0_>|<-seq 8Bytes->|<-tkr_mono 56Bytes->|<-thr_raw 56Bytes->|<-xtime_sec 8Bytes->|
    0xffff00000957dc00_>...

    HEAD:df5defd9
`->                     |<------formmer 64Bytes---->|<------------latter 64Byte-------->|
    0xffff00000962e680_>|<-Other variables 64Bytes->|<-seq 8Bytes->|<-tkr_mono 56Bytes->|
    0xffff00000962e6c0_>..

We testified thr_raw,xtime_sec fields interfere strongly with seq,tkr_mono field because of
frequent load/store operation, this will cause as known false sharing.

We add a 64Bytes padding field in tk_core for reservation of any after usefull usage and
keep tk_core 128Byte aligned, this can avoid changes in the way tk_core's layout is stored,
In this solution, layout of tk_core always like this:

crash>  struct -o tk_core_t
struct tk_core_t {
    [0] u64 padding[8];
   [64] seqcount_t seq;
   [72] struct timekeeper timekeeper;
}
SIZE: 336
crash> struct -o timekeeper
struct timekeeper {
    [0] struct tk_read_base tkr_mono;
   [56] struct tk_read_base tkr_raw;
  [112] u64 xtime_sec;
  [120] unsigned long ktime_sec;
  ...
}
SIZE: 264

After appling our own solution:

+---------+--------------+
+         + Our solution +
+---------+--------------+
+  Cores  +    Score     +
+---------+--------------+
+    1    +    548.9     +
+---------+--------------+
+   24    +   11018.3    +
+---------+--------------+
+   48    +   8938.2     +
+---------+--------------+
+   72    +   14610.7    +
+---------+--------------+
+   96    +   40811.7    +
+---------+--------------+
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      ee0afb75
    • Z
      config: close CONFIG_ARM64_ILP32 · 41e8bf06
      由 Zhen Lei 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4V6F8
CVE: NA

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

No one currently uses IPL32, close it to simplify the code logic of
TASK_SIZE_MAX, thereby improving benchmark performance. For example,
all test items of libMicro can be improved by 4.89% on average.
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: Nliuchao (CR) <liuchao173@huawei.com>
Reviewed-by: Liu Chao (CR) < liuchao173@huawei.com >
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      41e8bf06
    • Z
      arm64: replace is_compat_task() with is_ilp32_compat_task() in TASK_SIZE_MAX · cb478b93
      由 Zhen Lei 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4V6F8
CVE: NA

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

access_ok() is used to preliminarily check 'uaddr' to avoid unnecessary
page fault caused by invalid input. The page fault will do the accurate
address verification based on task's mm. It's also used to do a check on
the get_fs(), see the comments of __access_ok().

But now the support for get_fs() on arm64 has been deleted by commit
edf84200 ("arm64: uaccess: remove set_fs()"). So access_ok()
does not need to perform such strict checks for compat tasks.

Remove the is_compact_task() check can improve the performance of
syscalls. For example, all test items of libMicro can be improved by
4.89% on average.

The next patch will avoid calling is_ilp32_compat_task() by default by
close its build option, because ILP32 has specific requirements.
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: Nliuchao (CR) <liuchao173@huawei.com>
Reviewed-by: Liu Chao (CR) < liuchao173@huawei.com >
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      cb478b93
    • C
      configs: disable CONFIG_RODATA_FULL_DEFAULT_ENABLED · 45791588
      由 Chao Liu 提交于 
      euler inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4VPIB
CVE: NA

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

If this config is enabled, block mapping is not used. The linear address page
table is mapped to 4 KB. As a result, the TLB miss rate is high, affecting
performance.

For examples, tested by libMicro benchmark:
		enable		disable		Improve
memsetP2_10m	3540.37760	2129.715200	66.2%
memset_4k	0.38400		0.204800	87.5%
mprot_twz8k	7.16800		3.072000	133.3%
unmap_ra8k	7.93600		4.096000	93.8%
unmap_wa128k	68.86400	33.024000	108.5%

This additional enhancement can be turned on with rodata=full if this option
is set to 'n'.
Signed-off-by: NChao Liu <liuchao173@huawei.com>
Reviewed-by: NKai Liu <kai.liu@suse.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      45791588
  7. 03 3月, 2022 1 次提交
  9. 02 3月, 2022 3 次提交
  11. 23 2月, 2022 9 次提交
  13. 22 2月, 2022 17 次提交