Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 1月, 2022 8 次提交
    • Z
      md: Fix undefined behaviour in is_mddev_idle · 406295a3
      由 zhangwensheng 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4QXS1?from=project-issue
CVE: NA

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

UBSAN reports this problem:

[ 5984.281385] UBSAN: Undefined behaviour in drivers/md/md.c:8175:15
[ 5984.281390] signed integer overflow:
[ 5984.281393] -2147483291 - 2072033152 cannot be represented in type 'int'
[ 5984.281400] CPU: 25 PID: 1854 Comm: md101_resync Kdump: loaded Not tainted 4.19.90
[ 5984.281404] Hardware name: Huawei TaiShan 200 (Model 5280)/BC82AMDDA
[ 5984.281406] Call trace:
[ 5984.281415]  dump_backtrace+0x0/0x310
[ 5984.281418]  show_stack+0x28/0x38
[ 5984.281425]  dump_stack+0xec/0x15c
[ 5984.281430]  ubsan_epilogue+0x18/0x84
[ 5984.281434]  handle_overflow+0x14c/0x19c
[ 5984.281439]  __ubsan_handle_sub_overflow+0x34/0x44
[ 5984.281445]  is_mddev_idle+0x338/0x3d8
[ 5984.281449]  md_do_sync+0x1bb8/0x1cf8
[ 5984.281452]  md_thread+0x220/0x288
[ 5984.281457]  kthread+0x1d8/0x1e0
[ 5984.281461]  ret_from_fork+0x10/0x18

When the stat aacum of the disk is greater than INT_MAX, its value
becomes negative after casting to 'int', which may lead to overflow
after subtracting a positive number. In the same way, when the value
of sync_io is greater than INT_MAX,overflow may also occur. These
situations will lead to undefined behavior.

Otherwise, if the stat accum of the disk is close to INT_MAX when
creating raid arrays, the initial value of last_events would be set
close to INT_MAX when mddev initializes IO event counters.
'curr_events - rdev->last_events > 64' will always false during
synchronization. If all the disks of mddev are in this case,
is_mddev_idle() will always return 1, which may cause non-sync IO
is very slow.

To address these problems, need to use 64bit signed integer type
for sync_io,last_events, and curr_events.
Signed-off-by: Nzhangwensheng <zhangwensheng5@huawei.com>
Reviewed-by: NTao Hou <houtao1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      406295a3
    • L
      cgroup: fix compile error when CONFIG_MEMCG = n · 58824c83
      由 Lu Jialin 提交于 
      hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4IMAK?from=project-issue
CVE: NA

--------

when CONFIG_MEMCG = n, compile error occurs

mm/vmscan.c: In function ‘is_memcg_kswapd_stopped’:
mm/vmscan.c:2849:11: error: dereferencing pointer to incomplete type ‘struct mem_cgroup’
  if (memcg->memory.max == PAGE_COUNTER_MAX)

Fix the error by modify is_memcg_kswapd_stopped function return false when
CONFIG_MEMCG = n

v2: add compile error message in commit msg
Signed-off-by: NLu Jialin <lujialin4@huawei.com>
Reviewed-by: Nweiyang wang <wangweiyang2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      58824c83
    • D
      xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like fallocate · b297b0eb
      由 Darrick J. Wong 提交于 
      mainline inclusion
from mainline-v5.16-rc5
commit 983d8e60
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RCES
CVE: CVE-2021-4155

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=983d8e60f50806f90534cc5373d0ce867e5aaf79

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

The old ALLOCSP/FREESP ioctls in XFS can be used to preallocate space at
the end of files, just like fallocate and RESVSP.  Make the behavior
consistent with the other ioctls.
Reported-by: NKirill Tkhai <ktkhai@virtuozzo.com>
Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NEric Sandeen <sandeen@redhat.com>
Signed-off-by: NGuo Xuenan <guoxuenan@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>
      b297b0eb
    • F
      fbcon: fix ypos over boundary issue · 90c0d8ff
      由 Feng Tiantian 提交于 
      euleros inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4RA6U
CVE: NA

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

While using "top" on a CentOS guest's VNC-client, then continuously press
"Shift+PgUp", the guest kernel will get panic! Backtrace is attached below.
We tested it on 5.2.0, and the issue remains.

[   66.946362] Unable to handle kernel paging request at virtual address ffff00000e240840
[   66.946363] Mem abort info:
[   66.946364]   Exception class = DABT (current EL), IL = 32 bits
[   66.946365]   SET = 0, FnV = 0
[   66.946366]   EA = 0, S1PTW = 0
[   66.946367] Data abort info:
[   66.946368]   ISV = 0, ISS = 0x00000047
[   66.946368]   CM = 0, WnR = 1
[   66.946370] swapper pgtable: 64k pages, 48-bit VAs, pgd = ffff000009660000
[   66.946372] [ffff00000e240840] *pgd=000000023ffe0003, *pud=000000023ffe0003, *pmd=000000023ffd0003, *pte=0000000000000000
[   66.946378] Internal error: Oops: 96000047 [#1] SMP
[   66.946379] Modules linked in: vfat fat crc32_ce ghash_ce sg sha2_ce sha256_arm64 virtio_balloon virtio_net sha1_ce ip_tables ext4 mbcache jbd2 virtio_gpu drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm i2c_core virtio_scsi virtio_pci virtio_mmio virtio_ring virtio
[   66.946403] CPU: 0 PID: 1035 Comm: top Not tainted 4.14.0-49.el7a.aarch64 #1
[   66.946404] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[   66.946405] task: ffff8001c18fdc00 task.stack: ffff00000d4e0000
[   66.946409] PC is at sys_imageblit+0x40c/0x10000 [sysimgblt]
[   66.946431] LR is at drm_fb_helper_sys_imageblit+0x28/0x4c [drm_kms_helper]
[   66.946433] pc : [<ffff0000020a040c>] lr : [<ffff000002202e74>] pstate: 00000005
[   66.946433] sp : ffff00000d4ef7f0
[   66.946434] x29: ffff00000d4ef7f0 x28: 00000000000001ff
[   66.946436] x27: ffff8001c1c88100 x26: 0000000000000001
[   66.946438] x25: 00000000000001f0 x24: 0000000000000018
[   66.946440] x23: 0000000000000000 x22: ffff00000d4ef978
[   66.946442] x21: ffff00000e240840 x20: 0000000000000000
[   66.946444] x19: ffff8001c98c9000 x18: 0000fffff9d56670
[   66.946445] x17: 0000000000000000 x16: 0000000000000000
[   66.946447] x15: 0000000000000008 x14: 1b20202020202020
[   66.946449] x13: 00000000000001f0 x12: 000000000000003e
[   66.946450] x11: 000000000000000f x10: ffff8001c8400000
[   66.946452] x9 : 0000000000aaaaaa x8 : 0000000000000001
[   66.946454] x7 : ffff0000020b0090 x6 : 0000000000000001
[   66.946456] x5 : 0000000000000000 x4 : 0000000000000000
[   66.946457] x3 : ffff8001c8400000 x2 : ffff00000e240840
[   66.946459] x1 : 00000000000001ef x0 : 0000000000000007
[   66.946461] Process top (pid: 1035, stack limit = 0xffff00000d4e0000)
[   66.946462] Call trace:
[   66.946464] Exception stack(0xffff00000d4ef6b0 to 0xffff00000d4ef7f0)
[   66.946465] f6a0:                                   0000000000000007 00000000000001ef
[   66.946467] f6c0: ffff00000e240840 ffff8001c8400000 0000000000000000 0000000000000000
[   66.946468] f6e0: 0000000000000001 ffff0000020b0090 0000000000000001 0000000000aaaaaa
[   66.946470] f700: ffff8001c8400000 000000000000000f 000000000000003e 00000000000001f0
[   66.946471] f720: 1b20202020202020 0000000000000008 0000000000000000 0000000000000000
[   66.946472] f740: 0000fffff9d56670 ffff8001c98c9000 0000000000000000 ffff00000e240840
[   66.946474] f760: ffff00000d4ef978 0000000000000000 0000000000000018 00000000000001f0
[   66.946475] f780: 0000000000000001 ffff8001c1c88100 00000000000001ff ffff00000d4ef7f0
[   66.946476] f7a0: ffff000002202e74 ffff00000d4ef7f0 ffff0000020a040c 0000000000000005
[   66.946478] f7c0: ffff00000d4ef7e0 ffff0000080ea614 0001000000000000 ffff000008152f08
[   66.946479] f7e0: ffff00000d4ef7f0 ffff0000020a040c
[   66.946481] [<ffff0000020a040c>] sys_imageblit+0x40c/0x10000 [sysimgblt]
[   66.946501] [<ffff000002202e74>] drm_fb_helper_sys_imageblit+0x28/0x4c [drm_kms_helper]
[   66.946510] [<ffff0000022a12dc>] virtio_gpu_3d_imageblit+0x2c/0x78 [virtio_gpu]
[   66.946515] [<ffff00000847f458>] bit_putcs+0x288/0x49c
[   66.946517] [<ffff00000847ad24>] fbcon_putcs+0x114/0x148
[   66.946519] [<ffff0000084fe92c>] do_update_region+0x118/0x19c
[   66.946521] [<ffff00000850413c>] do_con_trol+0x114c/0x1314
[   66.946523] [<ffff0000085044dc>] do_con_write.part.22+0x1d8/0x890
[   66.946525] [<ffff000008504c88>] con_write+0x84/0x8c
[   66.946527] [<ffff0000084ec7f0>] n_tty_write+0x19c/0x408
[   66.946529] [<ffff0000084e9120>] tty_write+0x150/0x270
[   66.946532] [<ffff00000829d558>] __vfs_write+0x58/0x180
[   66.946534] [<ffff00000829d880>] vfs_write+0xa8/0x1a0
[   66.946536] [<ffff00000829db40>] SyS_write+0x60/0xc0
[   66.946537] Exception stack(0xffff00000d4efec0 to 0xffff00000d4f0000)
[   66.946539] fec0: 0000000000000001 0000000000457958 0000000000000800 0000000000000000
[   66.946540] fee0: 00000000fbad2885 0000000000000bd0 0000ffff8556add4 0000000000000000
[   66.946541] ff00: 0000000000000040 0000000000000000 0000000000434a88 0000000000000012
[   66.946543] ff20: 0000000100000000 0000fffff9d564f0 0000fffff9d564a0 0000000000000008
[   66.946544] ff40: 0000000000000000 0000ffff85593b1c 0000fffff9d56670 0000000000000800
[   66.946546] ff60: 0000000000457958 0000ffff856a1158 0000000000000800 0000ffff85720000
[   66.946547] ff80: 0000000000000000 0000ffff856f604c 0000000000000000 0000000000436000
[   66.946548] ffa0: 000000001c90a160 0000fffff9d56f20 0000ffff855965f4 0000fffff9d56f20
[   66.946549] ffc0: 0000ffff855f12c8 0000000020000000 0000000000000001 0000000000000040
[   66.946551] ffe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   66.946554] [<ffff00000808359c>] __sys_trace_return+0x0/0x4
[   66.946556] Code: 0a080084 b86478e4 0a040124 4a050084 (b9000044)
[   66.946561] ---[ end trace 32d49c68b19c4796 ]---
[   66.946562] Kernel panic - not syncing: Fatal exception
[   66.946564] SMP: stopping secondary CPUs
[   66.946596] Kernel Offset: disabled
[   66.946598] CPU features: 0x1802008
[   66.946598] Memory Limit: none
[   67.092353] ---[ end Kernel panic - not syncing: Fatal exception

From our non-expert analysis, fbcon ypos will sometimes over boundary and
then fbcon_putcs() access invalid VGA framebuffer address. We modify the
real_y() to make sure fbcon ypos is always less than rows.
Reported-by: NZengruan Ye <yezengruan@huawei.com>
Signed-off-by: NFeng Tiantian <fengtiantian@huawei.com>
Signed-off-by: NZenghui Yu <yuzenghui@huawei.com>
Reviewed-by: NHailiang Zhang <zhang.zhanghailiang@huawei.com>
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Link: https://gitee.com/openeuler/kernel/commit/45aa9689e6d2Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      90c0d8ff
    • B
      mm/zswap: move to use crypto_acomp API for hardware acceleration · 95e75096
      由 Barry Song 提交于 
      mainline inclusion
from mainline-v5.11
commit 1ec3b5fe
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4QEIH
CVE: NA

Reference:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/mm/zswap.c?id=1ec3b5fe6eec782f4e5e0a80e4ce1909ffd5d161

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

Right now, all new ZIP drivers are adapted to crypto_acomp APIs rather
than legacy crypto_comp APIs.  Tradiontal ZIP drivers like lz4,lzo etc
have been also wrapped into acomp via scomp backend.  But zswap.c is still
using the old APIs.  That means zswap won't be able to work on any new ZIP
drivers in kernel.

This patch moves to use cryto_acomp APIs to fix the disconnected bridge
between new ZIP drivers and zswap.  It is probably the first real user to
use acomp but perhaps not a good example to demonstrate how multiple acomp
requests can be executed in parallel in one acomp instance.  frontswap is
doing page load and store page by page synchronously.  swap_writepage()
depends on the completion of frontswap_store() to decide if it should call
__swap_writepage() to swap to disk.

However this patch creates multiple acomp instances, so multiple threads
running on multiple different cpus can actually do (de)compression
parallelly, leveraging the power of multiple ZIP hardware queues.  This is
also consistent with frontswap's page management model.

The old zswap code uses atomic context and avoids the race conditions
while shared resources like zswap_dstmem are accessed.  Here since acomp
can sleep, per-cpu mutex is used to replace preemption-disable.

While it is possible to make mm/page_io.c and mm/frontswap.c support async
(de)compression in some way, the entire design requires careful thinking
and performance evaluation.  For the first step, the base with fixed
connection between ZIP drivers and zswap should be built.

Link: https://lkml.kernel.org/r/20201107065332.26992-1-song.bao.hua@hisilicon.comSigned-off-by: NBarry Song <song.bao.hua@hisilicon.com>
Acked-by: NVitaly Wool <vitalywool@gmail.com>
Cc: Luis Claudio R. Goncalves <lgoncalv@redhat.com>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: David S. Miller <davem@davemloft.net>
Cc: Mahipal Challa <mahipalreddy2006@gmail.com>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: Zhou Wang <wangzhou1@hisilicon.com>
Cc: Colin Ian King <colin.king@canonical.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reviewed-by: NHao Fang <fanghao11@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      95e75096
    • D
      net: fix a data race when get vlan device · 5a60fc9d
      由 Di Zhu 提交于 
      mainline inclusion
from mainline-v5.13-rc1
commit c1102e9d
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I4RJ4X
CVE: NA

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

We encountered a crash: in the packet receiving process, we got an
illegal VLAN device address, but the VLAN device address saved in vmcore
is correct. After checking the code, we found a possible data
competition:
CPU 0:                             CPU 1:
    (RCU read lock)                  (RTNL lock)
    vlan_do_receive()		       register_vlan_dev()
      vlan_find_dev()

        ->__vlan_group_get_device()	 ->vlan_group_prealloc_vid()

In vlan_group_prealloc_vid(), We need to make sure that memset()
in kzalloc() is executed before assigning  value to vlan devices array:
=================================
kzalloc()
    ->memset(object, 0, size)

smp_wmb()

vg->vlan_devices_arrays[pidx][vidx] = array;
==================================

Because __vlan_group_get_device() function depends on this order.
otherwise we may get a wrong address from the hardware cache on
another cpu.

So fix it by adding memory barrier instruction to ensure the order
of memory operations.
Signed-off-by: NDi Zhu <zhudi21@huawei.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Reviewed-by: Nwuchangye <wuchangye@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      5a60fc9d
    • G
      ipvlan: Add handling of NETDEV_UP events · b6461fe5
      由 gaoxingwang 提交于 
      mainline inclusion
from mainline-v5.16-rc5
category: bugfix
commit 57fb346c
bugzilla: https://gitee.com/openeuler/kernel/issues/I4NDLN
CVE: NA

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

When an ipvlan device is created on a bond device, the link state
of the ipvlan device may be abnormal. This is because bonding device
allows to add physical network card device in the down state and so
NETDEV_CHANGE event will not be notified to other listeners, so ipvlan
has no chance to update its link status.

The following steps can cause such problems:
	1) bond0 is down
	2) ip link add link bond0 name ipvlan type ipvlan mode l2
	3) echo +enp2s7 >/sys/class/net/bond0/bonding/slaves
	4) ip link set bond0 up

After these steps, use ip link command, we found ipvlan has NO-CARRIER:
  ipvlan@bond0: <NO-CARRIER, BROADCAST,MULTICAST,UP,M-DOWN> mtu ...>

We can deal with this problem like VLAN: Add handling of NETDEV_UP
events. If we receive NETDEV_UP event, we will update the link status
of the ipvlan.
Signed-off-by: Ngaoxingwang <gaoxingwang@huawei.com>
Reviewed-by: Nwuchangye <wuchangye@huawei.com>
Reviewed-by: Nwuchangye <wuchangye@huawei.com>
Signed-off-by: Ngaoxingwang <gaoxingwang@huawei.com>
Reviewed-by: Nwuchangye <wuchangye@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      b6461fe5
    • S
      perf vendor events amd: Add Zen3 events · 9c5a512a
      由 Smita Koralahalli 提交于 
      mainline inclusion
from mainline-v5.13-rc1
commit da666586
category: feature
feature: milan cpu
bugzilla: https://gitee.com/openeuler/kernel/issues/I4OBEH?from=project-issue
CVE: NA

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

Add PMU events for AMD Zen3 processors as documented in the AMD Processor
Programming Reference for Family 19h and Model 01h [1].

Below are the events which are new on Zen3:

  PMCx041 ls_mab_alloc.{all_allocations|hardware_prefetcher_allocations|load_store_allocations}
  PMCx043 ls_dmnd_fills_from_sys.ext_cache_local
  PMCx044 ls_any_fills_from_sys.{mem_io_remote|ext_cache_remote|mem_io_local|ext_cache_local|int_cache|lcl_l2}
  PMCx047 ls_misal_loads.{ma4k|ma64}
  PMCx059 ls_sw_pf_dc_fills.ext_cache_local
  PMCx05a ls_hw_pf_dc_fills.ext_cache_local
  PMCx05f ls_alloc_mab_count
  PMCx085 bp_l1_tlb_miss_l2_tlb_miss.coalesced_4k
  PMCx0ab de_dis_cops_from_decoder.disp_op_type.{any_integer_dispatch|any_fp_dispatch}
  PMCx0cc ex_ret_ind_brch_instr
  PMCx18e ic_tag_hit_miss.{all_instruction_cache_accesses|instruction_cache_miss|instruction_cache_hit}
  PMCx1c7 ex_ret_msprd_brnch_instr_dir_msmtch
  PMCx28f op_cache_hit_miss.{all_op_cache_accesses|op_cache_miss|op_cache_hit}

Section 2.1.17.2 "Performance Measurement" of "PPR for AMD Family 19h,
Model 01h, Revision B1 Processors - 55898 Rev 0.35 - Feb 5, 2021." lists
new metrics. Add them.

Preserve the events for Zen3 if they are measurable and non-zero as taken
from Zen2 directory even if the PPR of Zen3 [1] omits them. Those events
are the following:

  PMCx000 fpu_pipe_assignment.{total|total0|total1|total2|total3}
  PMCx004 fp_num_mov_elim_scal_op.{optimized|opt_potential|sse_mov_ops_elim|sse_mov_ops}
  PMCx02D ls_rdtsc
  PMCx040 ls_dc_accesses
  PMCx046 ls_tablewalker.{iside|ic_type1|ic_type0|dside|dc_type1|dc_type0}
  PMCx061 l2_request_g2.{group1|ls_rd_sized|ls_rd_sized_nc|ic_rd_sized|ic_rd_sized_nc|smc_inval|bus_lock_originator|bus_locks_responses}
  PMCx062 l2_latency.l2_cycles_waiting_on_fills
  PMCx063 l2_wcb_req.{wcb_write|wcb_close|zero_byte_store|cl_zero}
  PMCx06d l2_fill_pending.l2_fill_busy
  PMCx080 ic_fw32
  PMCx081 ic_fw32_miss
  PMCx086 bp_snp_re_sync
  PMCx087 ic_fetch_stall.{ic_stall_any|ic_stall_dq_empty|ic_stall_back_pressure}
  PMCx08a bp_l1_btb_correct
  PMCx08c ic_cache_inval.{l2_invalidating_probe|fill_invalidated}
  PMCx099 bp_tlb_rel
  PMCx0a9 de_dis_uop_queue_empty_di0
  PMCx0c7 ex_ret_brn_resync
  PMCx28a ic_oc_mode_switch.{oc_ic_mode_switch|ic_oc_mode_switch}
  L3PMCx01 l3_request_g1.caching_l3_cache_accesses
  L3PMCx06 l3_comb_clstr_state.{other_l3_miss_typs|request_miss}

[1] Processor Programming Reference (PPR) for AMD Family 19h, Model 01h,
Revision B1 Processors - 55898 Rev 0.35 - Feb 5, 2021.

[2] Processor Programming Reference (PPR) for AMD Family 17h Model 71h,
Revision B0 Processors, 56176 Rev 3.06 - Jul 17, 2019.

[3] Processor Programming Reference (PPR) for AMD Family 17h Models
01h,08h, Revision B2 Processors, 54945 Rev 3.03 - Jun 14, 2019.

All of the PPRs can be found at:

https://bugzilla.kernel.org/show_bug.cgi?id=206537Reviewed-by: NRobert Richter <rrichter@amd.com>
Signed-off-by: NSmita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Kim Phillips <kim.phillips@amd.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Martin Liška <mliska@suse.cz>
Cc: Michael Petlan <mpetlan@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Vijay Thakkar <vijaythakkar@me.com>
Cc: linux-perf-users@vger.kernel.org
Link: https://lore.kernel.org/r/20210406215944.113332-5-Smita.KoralahalliChannabasappa@amd.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
      9c5a512a
  3. 19 1月, 2022 24 次提交
  5. 17 1月, 2022 8 次提交