Skip to content

K
Kernel

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

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 6月, 2023 1 次提交
    • H
      sched: fix performance degradation on lmbench · d8f77f89
      由 Hui Tang 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7A718

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

There are worse performance with the 'Fixes'
when running "./lat_ctx -P $SYNC_MAX -s 64 16".

The 'Fixes' which allocates memory for p->prefer_cpus
even if "prefer_cpus" not be set.

Before the 'Fixes', only test "p->prefer_cpus",
after, add test "!cpumask_empty(p->prefer_cpus)"
which causing performance degradation.

select_task_rq_fair
  ->set_task_select_cpus
    ->prefer_cpus_valid  ----  test cpumask_empty(p->prefer_cpus)

Fixes: ebeb84ad ("cpuset: Introduce new interface for scheduler ...")
Signed-off-by: NHui Tang <tanghui20@huawei.com>
      d8f77f89
  3. 18 5月, 2023 1 次提交
  5. 08 4月, 2023 3 次提交
  7. 28 2月, 2023 2 次提交
  9. 02 12月, 2022 1 次提交
  11. 29 11月, 2022 2 次提交
  13. 25 11月, 2022 3 次提交
  15. 24 11月, 2022 2 次提交
  17. 21 11月, 2022 4 次提交
  19. 18 11月, 2022 1 次提交
  21. 30 9月, 2022 6 次提交
  23. 23 5月, 2022 1 次提交
  25. 10 5月, 2022 2 次提交
  27. 23 2月, 2022 1 次提交
  29. 29 1月, 2022 2 次提交
  31. 31 12月, 2021 1 次提交
  33. 29 12月, 2021 1 次提交
  35. 10 12月, 2021 1 次提交
  37. 15 11月, 2021 2 次提交
  39. 21 10月, 2021 1 次提交
    • T
      x86/mce: Avoid infinite loop for copy from user recovery · c6a9d0e7
      由 Tony Luck 提交于 
      stable inclusion
from stable-5.10.68
commit 619d747c1850bab61625ca9d8b4730f470a5947b
bugzilla: 182671 https://gitee.com/openeuler/kernel/issues/I4EWUH

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=619d747c1850bab61625ca9d8b4730f470a5947b

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

commit 81065b35 upstream.

There are two cases for machine check recovery:

1) The machine check was triggered by ring3 (application) code.
   This is the simpler case. The machine check handler simply queues
   work to be executed on return to user. That code unmaps the page
   from all users and arranges to send a SIGBUS to the task that
   triggered the poison.

2) The machine check was triggered in kernel code that is covered by
   an exception table entry. In this case the machine check handler
   still queues a work entry to unmap the page, etc. but this will
   not be called right away because the #MC handler returns to the
   fix up code address in the exception table entry.

Problems occur if the kernel triggers another machine check before the
return to user processes the first queued work item.

Specifically, the work is queued using the ->mce_kill_me callback
structure in the task struct for the current thread. Attempting to queue
a second work item using this same callback results in a loop in the
linked list of work functions to call. So when the kernel does return to
user, it enters an infinite loop processing the same entry for ever.

There are some legitimate scenarios where the kernel may take a second
machine check before returning to the user.

1) Some code (e.g. futex) first tries a get_user() with page faults
   disabled. If this fails, the code retries with page faults enabled
   expecting that this will resolve the page fault.

2) Copy from user code retries a copy in byte-at-time mode to check
   whether any additional bytes can be copied.

On the other side of the fence are some bad drivers that do not check
the return value from individual get_user() calls and may access
multiple user addresses without noticing that some/all calls have
failed.

Fix by adding a counter (current->mce_count) to keep track of repeated
machine checks before task_work() is called. First machine check saves
the address information and calls task_work_add(). Subsequent machine
checks before that task_work call back is executed check that the address
is in the same page as the first machine check (since the callback will
offline exactly one page).

Expected worst case is four machine checks before moving on (e.g. one
user access with page faults disabled, then a repeat to the same address
with page faults enabled ... repeat in copy tail bytes). Just in case
there is some code that loops forever enforce a limit of 10.

 [ bp: Massage commit message, drop noinstr, fix typo, extend panic
   messages. ]

Fixes: 5567d11c ("x86/mce: Send #MC singal from task work")
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/YT/IJ9ziLqmtqEPu@agluck-desk2.amr.corp.intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Acked-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      c6a9d0e7
  41. 28 7月, 2021 1 次提交
  43. 14 7月, 2021 1 次提交