提交 · 6a5a682d4ad5f7a92ae74da5b1bc86709844ade5 · openeuler / Kernel

23 2月, 2022 36 次提交

mm: Reserve field in mm_struct for memory reliable · 6a5a682d

由 Peng Wu 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4SK3S
DTS: #896
CVE: NA

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

Reserved a variable in mm_struct while will be used by memory reliable.
Signed-off-by: NPeng Wu <wupeng58@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

6a5a682d

mm: Introduce reliable flag for user task · 8ee6e050

由 Peng Wu 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01
CVE: NA

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

Adding reliable flag for user task. User task with reliable flag can
only alloc memory from mirrored region. PF_RELIABLE is added to represent
the task's reliable flag.

- For init task, which is regarded as special task which alloc memory
  from mirrored region.

- For normal user tasks, The reliable flag can be set via procfs interface
  shown as below and can be inherited via fork().

User can change a user task's reliable flag by

	$ echo [0/1] > /proc/<pid>/reliable

and check a user task's reliable flag by

	$ cat /proc/<pid>/reliable

Note, global init task's reliable file can not be accessed.
Signed-off-by: NPeng Wu <wupeng58@huawei.com>
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

8ee6e050

meminfo: Show reliable memory info · 9e47d0cc

由 Ma Wupeng 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01
CVE: NA

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

Add ReliMemTotal & ReliMemUsed in /proc/meminfo to show memory info about
reliable memory.

- ReliableTotal: total reliable RAM

- ReliableUsed: thei used amount of reliable memory kernel
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

9e47d0cc

mm: Introduce memory reliable · 6c59ddf2

由 Ma Wupeng 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01
CVE: NA

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

Introduction

============

Memory reliable feature is a memory tiering mechanism. It is based on
kernel mirror feature, which splits memory into two sperate regions,
mirrored(reliable) region and non-mirrored (non-reliable) region.

for kernel mirror feature:

- allocate kernel memory from mirrored region by default
- allocate user memory from non-mirrored region by default

non-mirrored region will be arranged into ZONE_MOVABLE.

for kernel reliable feature, it has additional features below:

- normal user tasks never alloc memory from mirrored region with userspace
  apis(malloc, mmap, etc.)
- special user tasks will allocate memory from mirrored region by default
- tmpfs/pagecache allocate memory from mirrored region by default
- upper limit of mirrored region allcated for user tasks, tmpfs and
  pagecache

Support Reliable fallback mechanism which allows special user tasks, tmpfs
and pagecache can fallback to alloc non-mirrored region, it's the default
setting.

In order to fulfil the goal

- ___GFP_RELIABLE flag added for alloc memory from mirrored region.

- the high_zoneidx for special user tasks/tmpfs/pagecache is set to
  ZONE_NORMAL.

- normal user tasks could only alloc from ZONE_MOVABLE.

This patch is just the main framework, memory reliable support for special
user tasks, pagecache and tmpfs has own patches.

To enable this function, mirrored(reliable) memory is needed and
"kernelcore=reliable" should be added to kernel parameters.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

6c59ddf2

efi: Disable mirror feature if kernelcore is not specified · 856090e5

由 Ma Wupeng 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01
CVE: NA

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

With this patch, kernel will check mirrored_kernelcore before calling
efi_find_mirror() which will enable basic mirrored feature.

If system have some mirrored memory and mirrored feature is not specified
in boot parameter, the basic mirrored feature will be enabled and this will
lead to the following situations:

- memblock memory allocation perfers mirrored region. This may have some
  unexpected influence on numa affinity.

- contiguous memory will be splited into server parts if parts of them
is mirrored memroy via memblock_mark_mirror().
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

856090e5

mm: Demote warning message in vmemmap_verify() to debug level · e876fd13

由 Ma Wupeng 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01
CVE: NA

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

For a system only have limited mirrored memory or some numa node without
mirrored memory, the per node vmemmap page_structs prefer to allocate
memory from mirrored region, which will lead to vmemmap_verify() report
lots of warning message.

This patch demote the "potential offnode page_structs" warning messages
to debug level to avoid a very long print during bootup.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

e876fd13

mm: Ratelimited mirrored memory related warning messages · bfd30cf1

由 Ma Wupeng 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01
CVE: NA

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

If system has mirrored memory, memblock will try to allocate mirrored
memory firstly and fallback to non-mirrored memory when fails, but if with
limited mirrored memory or some numa node without mirrored memory, lots of
warning message about memblock allocation will occur.

This patch ratelimit the warning message to avoid a very long print during
bootup.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

bfd30cf1

efi: Find mirrored memory ranges for arm64 · f5a5c792

由 Ma Wupeng 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01
CVE: NA

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

Mirrored memory could be used on HiSilion's arm64 SoC. So efi_find_mirror()
is added in efi_init() so that systems can get memblock about any mirrored
ranges.
Co-developed-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

f5a5c792

efi: Make efi_find_mirror() public · cc3d801f

由 Ma Wupeng 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01
CVE: NA

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

Commit b05b9f5f ("x86, mirror: x86 enabling - find mirrored memory
ranges") introduce the efi_find_mirror function on x86. In order to reuse
the API we make it public in preparation for arm64 to support mirrord
memory.
Co-developed-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

cc3d801f

arm64: efi: Add fake memory support · 4159882e

由 Ma Wupeng 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01
CVE: NA

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

Fake memory map is used for faking memory's attribute values.
Commit 0f96a99d ("efi: Add "efi_fake_mem" boot option") introduce the
efi_fake_mem function. Now it can support arm64 with this patch.
For example you can mark 0-6G memory as EFI_MEMORY_MORE_RELIABLE by adding
efi_fake_mem=6G@0:0x10000 in the bootarg. You find more info about
fake memmap in kernel-parameters.txt.

Variable memstart_addr is only confirmed after arm64_memblock_init(). So
efi_fake_memmap() is needed to add after arm64_memblock_init().

Otherwise:

efi_memmap_alloc
   memblock_phys_alloc
     kmemleak_alloc_phys
        kmemleak_alloc(__va(phys), size, min_count, gfp);

this __va() will convert phys to a fault va and lead to a kmemleak error.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

4159882e

efi: Make efi_print_memmap() public · 2e5602aa

由 Ma Wupeng 提交于 2月 23, 2022

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PM01
CVE: NA

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

Make efi_print_memmap() public in preparation for adding fake memory
support for architecture with efi support, eg, arm64.
Co-developed-by: NJing Xiangfeng <jingxiangfeng@huawei.com>
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

2e5602aa

arm64: openeuler_defconfig: Enable config for ultrasoc driver · b9853df0

由 Qi Liu 提交于 2月 23, 2022

driver inclusion
ategory: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4UA33

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

Enable configs for ultrasoc driver.
Signed-off-by: NQi Liu <liuqi115@huawei.com>
Reviewed-by: NJay Fang <f.fangjian@huawei.com>
Reviewed-by: NKai Liu <kai.liu@suse.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b9853df0

drivers/coresight: Add Ultrasoc System Memory Buffer driver · b7525bf1

由 Qi Liu 提交于 2月 23, 2022

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4UA33

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

This patch adds driver for Ultrasoc SMB(System Memory Buffer)
device. SMB provides a way to buffer messages from ETM, and
store these CPU instructions in system memory.

SMB is developed by Ultrasoc technology, which is acquired by
Siemens, and we still use "Ultrasoc" to name driver.
Signed-off-by: NQi Liu <liuqi115@huawei.com>
Tested-by: NJunHao He <hejunhao2@hisilicon.com>
Reviewed-by: NJay Fang <f.fangjian@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b7525bf1

coresight: etm4x: Modify core-commit to avoid HiSilicon ETM overflow · c29c172b

由 Qi Liu 提交于 2月 23, 2022

mainline inclusion
from mainline-v5.11-rc1
commit e7255092
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4UA33
CVE: NA

Reference: https://lore.kernel.org/r/20201208182651.1597945-4-mathieu.poirier@linaro.org

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

The ETM device can't keep up with the core pipeline when cpu core
is at full speed. This may cause overflow within core and its ETM.
This is a common phenomenon on ETM devices.

On HiSilicon Hip08 platform, a specific feature is added to set
core pipeline. So commit rate can be reduced manually to avoid ETM
overflow.
Reviewed-by: NSuzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: NQi Liu <liuqi115@huawei.com>
[Modified changelog title and Kconfig description]
Signed-off-by: NMathieu Poirier <mathieu.poirier@linaro.org>
Link: https://lore.kernel.org/r/20201208182651.1597945-4-mathieu.poirier@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NQi Liu <liuqi115@huawei.com>
Reviewed-by: NJay Fang <f.fangjian@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c29c172b

RAS: Report ARM processor information to userspace · fe3f0ee8

由 Shengwei Luo 提交于 2月 23, 2022

kunpeng inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4OUGN?from=project-issue
CVE: NA

The original arm_event trace code only traces out ARM processor error
information data. It's not enough for user to take appropriate action.

According to UEFI_2_9 specification chapter N2.4.4, the ARM processor
error section includes several ARM processor error information, several
ARM processor context information and several vendor specific error
information structures. In addition to these info, there are error
severity and cpu logical index about the event. Report all of these
information to userspace via perf i/f. So that the user can do cpu core
isolation according to error severity and other info.

Original-Author: Jason Tian <jason@os.amperecomputing.com>
Signed-off-by: NShengwei Luo <luoshengwei@huawei.com>
Reviewed-by: NLv Ying <lvying6@huawei.com>
Reviewed-by: NTan Xiaofei <tanxiaofei@huawei.com>
Acked-by: NXie XiuQi <xiexiuqi@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

fe3f0ee8

configs: enable CONFIG_NTB_INTEL · c37700f3

由 Chao Liu 提交于 2月 23, 2022

euler inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4UP2Q
CVE: NA

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

Enable CONFIG_NTB_INTEL in openeuler_defconfig for x86.
Support Intel NTB on capable Xeon and Atom hardware.
Signed-off-by: NChao Liu <liuchao173@huawei.com>
Reviewed-by: NKai Liu <kai.liu@suse.com>
Reviewed-by: NLiu Sirui <liusirui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

c37700f3

udf: Restore i_lenAlloc when inode expansion fails · 0dd50252

由 Jan Kara 提交于 2月 23, 2022

mainline inclusion
from mainline-v5.17-rc2
commit ea856919
category: bugfix
bugzilla: 186269 https://gitee.com/openeuler/kernel/issues/I4UATL?from=project-issue
CVE: CVE-2022-0617

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

When we fail to expand inode from inline format to a normal format, we
restore inode to contain the original inline formatting but we forgot to
set i_lenAlloc back. The mismatch between i_lenAlloc and i_size was then
causing further problems such as warnings and lost data down the line.
Reported-by: Nbutt3rflyh4ck <butterflyhuangxx@gmail.com>
CC: stable@vger.kernel.org
Fixes: 7e49b6f2 ("udf: Convert UDF to new truncate calling sequence")
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJan Kara <jack@suse.cz>
Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0dd50252

udf: Fix NULL ptr deref when converting from inline format · 7f2ba6e5

由 Jan Kara 提交于 2月 23, 2022

mainline inclusion
from mainline-v5.17-rc2
commit 7fc3b7c2
category: bugfix
bugzilla: 186269 https://gitee.com/openeuler/kernel/issues/I4UATL?from=project-issue
CVE: CVE-2022-0617

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

udf_expand_file_adinicb() calls directly ->writepage to write data
expanded into a page. This however misses to setup inode for writeback
properly and so we can crash on inode->i_wb dereference when submitting
page for IO like:

  BUG: kernel NULL pointer dereference, address: 0000000000000158
  #PF: supervisor read access in kernel mode
...
  <TASK>
  __folio_start_writeback+0x2ac/0x350
  __block_write_full_page+0x37d/0x490
  udf_expand_file_adinicb+0x255/0x400 [udf]
  udf_file_write_iter+0xbe/0x1b0 [udf]
  new_sync_write+0x125/0x1c0
  vfs_write+0x28e/0x400

Fix the problem by marking the page dirty and going through the standard
writeback path to write the page. Strictly speaking we would not even
have to write the page but we want to catch e.g. ENOSPC errors early.
Reported-by: Nbutt3rflyh4ck <butterflyhuangxx@gmail.com>
CC: stable@vger.kernel.org
Fixes: 52ebea74 ("writeback: make backing_dev_info host cgroup-specific bdi_writebacks")
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NJan Kara <jack@suse.cz>
Signed-off-by: NZhang Wensheng <zhangwensheng5@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

7f2ba6e5

rcu: Do not report strict GPs for outgoing CPUs · b73b74dc

由 Paul E. McKenney 提交于 2月 23, 2022

mainline inclusion
from mainline-v5.12-rc1
commit bfb3aa73
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4UAEG
CVE: NA

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

An outgoing CPU is marked offline in a stop-machine handler and most
of that CPU's services stop at that point, including IRQ work queues.
However, that CPU must take another pass through the scheduler and through
a number of CPU-hotplug notifiers, many of which contain RCU readers.
In the past, these readers were not a problem because the outgoing CPU
has interrupts disabled, so that rcu_read_unlock_special() would not
be invoked, and thus RCU would never attempt to queue IRQ work on the
outgoing CPU.

This changed with the advent of the CONFIG_RCU_STRICT_GRACE_PERIOD
Kconfig option, in which rcu_read_unlock_special() is invoked upon exit
from almost all RCU read-side critical sections.  Worse yet, because
interrupts are disabled, rcu_read_unlock_special() cannot immediately
report a quiescent state and will therefore attempt to defer this
reporting, for example, by queueing IRQ work.  Which fails with a splat
because the CPU is already marked as being offline.

But it turns out that there is no need to report this quiescent state
because rcu_report_dead() will do this job shortly after the outgoing
CPU makes its final dive into the idle loop.  This commit therefore
makes rcu_read_unlock_special() refrain from queuing IRQ work onto
outgoing CPUs.

Fixes: 44bad5b3 ("rcu: Do full report for .need_qs for strict GPs")
Signed-off-by: NPaul E. McKenney <paulmck@kernel.org>
Cc: Jann Horn <jannh@google.com>
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

b73b74dc

rcu-tasks: Make ksoftirqd provide RCU Tasks quiescent states · 0f83cef0

由 Paul E. McKenney 提交于 2月 23, 2022

mainline inclusion
from mainline-v5.14-rc1
commit cf868c2a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4U05V
CVE: NA

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

Heavy networking load can cause a CPU to execute continuously and
indefinitely within ksoftirqd, in which case there will be no voluntary
task switches and thus no RCU-tasks quiescent states.  This commit
therefore causes the exiting rcu_softirq_qs() to provide an RCU-tasks
quiescent state.

This of course means that __do_softirq() and its callers cannot be
invoked from within a tracing trampoline.
Reported-by: NToke Høiland-Jørgensen <toke@redhat.com>
Tested-by: NToke Høiland-Jørgensen <toke@redhat.com>
Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NPaul E. McKenney <paulmck@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

0f83cef0

entry: Explicitly flush pending rcuog wakeup before last rescheduling point · 6c7ab876

由 Frederic Weisbecker 提交于 2月 23, 2022

mainline inclusion
from mainline-v5.12-rc1
commit 47b8ff19
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4U05V
CVE: NA

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

Following the idle loop model, cleanly check for pending rcuog wakeup
before the last rescheduling point on resuming to user mode. This
way we can avoid to do it from rcu_user_enter() with the last resort
self-IPI hack that enforces rescheduling.
Signed-off-by: NFrederic Weisbecker <frederic@kernel.org>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20210131230548.32970-5-frederic@kernel.org
Conflicts:
	kernel/entry/common.c
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

6c7ab876

rcu/nocb: Trigger self-IPI on late deferred wake up before user resume · a19ce198

由 Frederic Weisbecker 提交于 2月 23, 2022

mainline inclusion
from mainline-v5.12-rc1
commit f8bb5cae
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4U05V
CVE: NA

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

Entering RCU idle mode may cause a deferred wake up of an RCU NOCB_GP
kthread (rcuog) to be serviced.

Unfortunately the call to rcu_user_enter() is already past the last
rescheduling opportunity before we resume to userspace or to guest mode.
We may escape there with the woken task ignored.

The ultimate resort to fix every callsites is to trigger a self-IPI
(nohz_full depends on arch to implement arch_irq_work_raise()) that will
trigger a reschedule on IRQ tail or guest exit.

Eventually every site that want a saner treatment will need to carefully
place a call to rcu_nocb_flush_deferred_wakeup() before the last explicit
need_resched() check upon resume.

Fixes: 96d3fd0d (rcu: Break call_rcu() deadlock involving scheduler and perf)
Reported-by: NPaul E. McKenney <paulmck@kernel.org>
Signed-off-by: NFrederic Weisbecker <frederic@kernel.org>
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: NIngo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lkml.kernel.org/r/20210131230548.32970-4-frederic@kernel.orgSigned-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

a19ce198

irq_work: Cleanup · 44a47613

由 Peter Zijlstra 提交于 2月 23, 2022

mainline inclusion
from mainline-v5.11-rc1
commit 7a9f50a0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4U05V
CVE: NA

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

Get rid of the __call_single_node union and clean up the API a little
to avoid external code relying on the structure layout as much.
Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: NFrederic Weisbecker <frederic@kernel.org>
Signed-off-by: NZhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

44a47613

powerpc/process, kasan: Silence KASAN warnings in __get_wchan() · 1d22158a

由 He Ying 提交于 2月 23, 2022

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4U2S3
CVE: NA

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

The following KASAN warning was reported in our kernel.

  BUG: KASAN: stack-out-of-bounds in get_wchan+0x188/0x250
  Read of size 4 at addr d216f958 by task ps/14437

  CPU: 3 PID: 14437 Comm: ps Tainted: G           O      5.10.0 #1
  Call Trace:
  [daa63858] [c0654348] dump_stack+0x9c/0xe4 (unreliable)
  [daa63888] [c035cf0c] print_address_description.constprop.3+0x8c/0x570
  [daa63908] [c035d6bc] kasan_report+0x1ac/0x218
  [daa63948] [c00496e8] get_wchan+0x188/0x250
  [daa63978] [c0461ec8] do_task_stat+0xce8/0xe60
  [daa63b98] [c0455ac8] proc_single_show+0x98/0x170
  [daa63bc8] [c03cab8c] seq_read_iter+0x1ec/0x900
  [daa63c38] [c03cb47c] seq_read+0x1dc/0x290
  [daa63d68] [c037fc94] vfs_read+0x164/0x510
  [daa63ea8] [c03808e4] ksys_read+0x144/0x1d0
  [daa63f38] [c005b1dc] ret_from_syscall+0x0/0x38
  --- interrupt: c00 at 0x8fa8f4
      LR = 0x8fa8cc

  The buggy address belongs to the page:
  page:98ebcdd2 refcount:0 mapcount:0 mapping:00000000 index:0x2 pfn:0x1216f
  flags: 0x0()
  raw: 00000000 00000000 01010122 00000000 00000002 00000000 ffffffff 00000000
  raw: 00000000
  page dumped because: kasan: bad access detected

  Memory state around the buggy address:
   d216f800: 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00
   d216f880: f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  >d216f900: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
                                            ^
   d216f980: f2 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
   d216fa00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

After looking into this issue, I find the buggy address belongs
to the task stack region. It seems KASAN has something wrong.
I look into the code of __get_wchan in x86 architecture and
find the same issue has been resolved by the commit
f7d27c35 ("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to powerpc architecture too.

As Andrey Ryabinin said, get_wchan() is racy by design, it may
access volatile stack of running task, thus it may access
redzone in a stack frame and cause KASAN to warn about this.

Use READ_ONCE_NOCHECK() to silence these warnings.
Reported-by: NWanming Hu <huwanming@huaweil.com>
Signed-off-by: NHe Ying <heying24@huawei.com>
Signed-off-by: NChen Jingwen <chenjingwen6@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

1d22158a

net/spnic: Reduce the timeout of the channel between driver and firmware · 82a493e3