Merge Pull Request from: @liaoyu15 
 
Currently, only x86 architecture supports the CLOCKSOURCE_VALIDATE_LAST_CYCLE
option. This option ensures that the timestamps returned by the clocksource are
monotonically increasing, and helps avoid issues caused by hardware failures.

This commit makes CLOCKSOURCE_VALIDATE_LAST_CYCLE configurable on
the arm64 architecture, helps increase system stability and reliability. 
 
Link:https://gitee.com/openeuler/kernel/pulls/772 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Reviewed-by: Wei Li <liwei391@huawei.com> 
Reviewed-by: Liu Chao <liuchao173@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

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

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

The ARM ARM states the following (where a CPU is a device):

	The system counter must provide a uniform view of system time. More
	precisely, it must be impossible for the following sequence of events
	to show system time going backwards:

	1) Device A reads the time from the system counter.

	2) Device A communicates with another agent in the system, Device B.

	3) After recognizing the communication from Device A, Device B reads
	   the time from the system counter.

So make CLOCKSOURCE_VALIDATE_LAST_CYCLE unset by default.
Signed-off-by: NYu Liao <liaoyu15@huawei.com>

Merge Pull Request from: @sanglipeng 
 
Backport 5.10.151 LTS patches from upstream.

Total patches: 5 
 
Link:https://gitee.com/openeuler/kernel/pulls/768 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @Tom_zc 
 
Enabling bcache causes interface changes and needs to be rolled back。 
 
Link:https://gitee.com/openeuler/kernel/pulls/771 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

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

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

Currently, only x86 architecture supports the CLOCKSOURCE_VALIDATE_LAST_CYCLE
option. This option ensures that the timestamps returned by the clocksource are
monotonically increasing, and helps avoid issues caused by hardware failures.

This commit makes CLOCKSOURCE_VALIDATE_LAST_CYCLE configurable on
the arm64 architecture, helps increase system stability and reliability.
Signed-off-by: NYu Liao <liaoyu15@huawei.com>

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6N4EP
CVE: NA

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

This reverts commit fc3bfef5.

This commit causes the interface to change.

Fixes: fc3bfef5 ("config: enable bcache for x86 by default")
Signed-off-by: NChao Zhu <tom_toworld@163.com>

Merge Pull Request from: @Tom_zc 
 
To fix issue about https://gitee.com/openeuler/kernel/issues/I6N4EP?from=project-issue
and test report is in here: https://gitee.com/Tom_zc/my_doc/blob/master/kernel%E7%A4%BE%E5%8C%BA/%E9%AA%8C%E8%AF%81openEuler%E7%BC%96%E8%AF%91%E6%94%AF%E6%8C%81bcache.md 
 
Link:https://gitee.com/openeuler/kernel/pulls/757 

Reviewed-by: Liu Chao <liuchao173@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

driver inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I6N4EP
CVE: NA

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

openEuler supports bcache by default on x86 platforms
Signed-off-by: NChao Zhu <tom_toworld@163.com>

Merge Pull Request from: @xiao_jiang_shui 
 
https://gitee.com/openeuler/kernel/issues/I6VW8E 
 
Link:https://gitee.com/openeuler/kernel/pulls/634 

Reviewed-by: Yang Shen <shenyang39@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @gesefudiao 
 
The higher version community DAMON features in rounds:

Removed the debugfs interface and enabled the sysfs interface.
Added the lru_sort module to achieve proactive adjustment of the system-level LRU list for physical address monitoring.
Support for online automation adjustment of DAMON strategies. 
 
Link:https://gitee.com/openeuler/kernel/pulls/763 

Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

stable inclusion
from stable-v5.10.151
commit ecad3312111798d84dac1ce6a853e0ac9de8d505
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64L0X

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

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

New pahole (version 1.24) generates by default new BTF_KIND_ENUM64 BTF tag,
which is not supported by stable kernel.

As a result the kernel with CONFIG_DEBUG_INFO_BTF option will fail to
compile with following error:

  BTFIDS  vmlinux
FAILED: load BTF from vmlinux: Invalid argument

New pahole provides --skip_encoding_btf_enum64 option to skip BTF_KIND_ENUM64
generation and produce BTF supported by stable kernel.

Adding this option to scripts/pahole-flags.sh.

This change does not have equivalent commit in linus tree, because linus tree
has support for BTF_KIND_ENUM64 tag, so it does not need to be disabled.
Signed-off-by: NMartin Rodriguez Reboredo <yakoyoku@gmail.com>
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.151
commit c5006abb80e276896ff7237300a6d447708c7924
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64L0X

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

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

commit 9741e07e upstream.

[skipped --btf_gen_floats option in pahole-flags.sh, skipped
Makefile.modfinal change, because there's no BTF kmod support,
squashing in 'exit 0' change from merge commit fc02cb2b]

Using new PAHOLE_FLAGS variable to pass extra arguments to
pahole for both vmlinux and modules BTF data generation.

Adding new scripts/pahole-flags.sh script that detect and
prints pahole options.

[ fixed issues found by kernel test robot ]
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
Acked-by: NAndrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211029125729.70002-1-jolsa@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.151
commit f5f413cb3e8af235c5d310bea9942424fb242c2c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64L0X

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

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

commit a0b8200d upstream.

[small context changes due to missing floats support in 5.10]

Commit "mm/page_alloc: convert per-cpu list protection to local_lock" will
introduce a zero-sized per-CPU variable, which causes pahole to generate
invalid BTF.  Only pahole versions 1.18 through 1.21 are impacted, as
before 1.18 pahole doesn't know anything about per-CPU variables, and 1.22
contains the proper fix for the issue.

Luckily, pahole 1.18 got --skip_encoding_btf_vars option disabling BTF
generation for per-CPU variables in anticipation of some unanticipated
problems.  So use this escape hatch to disable per-CPU var BTF info on
those problematic pahole versions.  Users relying on availability of
per-CPU var BTFs would need to upgrade to pahole 1.22+, but everyone won't
notice any regressions.

Link: https://lkml.kernel.org/r/20210530002536.3193829-1-andrii@kernel.orgSigned-off-by: NAndrii Nakryiko <andrii@kernel.org>
Acked-by: NMel Gorman <mgorman@techsingularity.net>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Hao Luo <haoluo@google.com>
Cc: Michal Suchanek <msuchanek@suse.de>
Cc: Jiri Olsa <jolsa@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.151
commit 06481cd9f7f692088bce03244f8cf132018f2fc6
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64L0X

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

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

commit ff2e6efd upstream.

[backported for dependency, skipped Makefile.modfinal change,
because module BTF is not supported in 5.10]

The ccache tool can be used to speed up cross-compilation, by calling the
compiler and binutils through ccache. For example, following should work:

    $ export ARCH=arm64 CROSS_COMPILE="ccache aarch64-linux-gnu-"

    $ make M=drivers/gpu/drm/rockchip/

but pahole fails to extract the BTF info from DWARF, breaking the build:

      CC [M]  drivers/gpu/drm/rockchip//rockchipdrm.mod.o
      LD [M]  drivers/gpu/drm/rockchip//rockchipdrm.ko
      BTF [M] drivers/gpu/drm/rockchip//rockchipdrm.ko
    aarch64-linux-gnu-objcopy: invalid option -- 'J'
    Usage: aarch64-linux-gnu-objcopy [option(s)] in-file [out-file]
     Copies a binary file, possibly transforming it in the process
    ...
    make[1]: *** [scripts/Makefile.modpost:156: __modpost] Error 2
    make: *** [Makefile:1866: modules] Error 2

this fails because OBJCOPY is set to "ccache aarch64-linux-gnu-copy" and
later pahole is executed with the following command line:

    LLVM_OBJCOPY=$(OBJCOPY) $(PAHOLE) -J --btf_base vmlinux $@

which gets expanded to:

    LLVM_OBJCOPY=ccache aarch64-linux-gnu-objcopy pahole -J ...

instead of:

    LLVM_OBJCOPY="ccache aarch64-linux-gnu-objcopy" pahole -J ...

Fixes: 5f9ae91f ("kbuild: Build kernel module BTFs if BTF is enabled and pahole supports it")
Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
Acked-by: NAndrii Nakryiko <andrii@kernel.org>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Link: https://lore.kernel.org/bpf/20210526215228.3729875-1-javierm@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.151
commit bbaea0f1cd33d702d053d5bdaf6d6dec3932894c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64L0X

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

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

commit db16c1fe  upstream.

[backported for dependency only extra_paholeopt variable setup and
usage, we don't want floats generated in 5.10]

pahole v1.21 supports the --btf_gen_floats flag, which makes it
generate the information about the floating-point types [1].

Adjust link-vmlinux.sh to pass this flag to pahole in case it's
supported, which is determined using a simple version check.

[1] https://lore.kernel.org/dwarves/YHRiXNX1JUF2Az0A@kernel.org/Signed-off-by: NIlya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
Acked-by: NAndrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210413190043.21918-1-iii@linux.ibm.comSigned-off-by: NJiri Olsa <jolsa@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

Merge Pull Request from: @jiayingbao 
 
intel_idle: add Emerald Rapids Xeon support
commit 74528edf upstream.
Emerald Rapids (EMR) is the next Intel Xeon processor after Sapphire
Rapids (SPR).

EMR C-states are the same as SPR C-states, and we expect that EMR
C-state characteristics (latency and target residency) will be the
same as in SPR. Therefore, add EMR support by using SPR C-states table.


no change from upstream patch.

driver can be initial successfully as SPR.

PR dependency: 
https://gitee.com/openeuler/kernel/pulls/469
 
 
Link:https://gitee.com/openeuler/kernel/pulls/749 

Reviewed-by: Aichun Shi <aichun.shi@intel.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @jiayingbao 
 
backport from upstream commit 9c252ecf
Make Intel uncore frequency driver support Emerald Rapids by adding its
CPU model to the match table.

Emerald Rapids uncore frequency control is the same as in Sapphire Rapids.

no change from upstream patch.

driver can be initial successfully as SPR.


PR dependency: 
https://gitee.com/openeuler/kernel/pulls/469 
 
Link:https://gitee.com/openeuler/kernel/pulls/748 

Reviewed-by: Jason Zeng <jason.zeng@intel.com> 
Reviewed-by: Aichun Shi <aichun.shi@intel.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @youquan_song 
 
[Description]​
SPR: EDAC driver enhance for driver decode and 2LM

Current i10nm_edac only supports firmware decoder (ACPI DSM methods) for Sapphire Rapids. So add the driver decoder(decoding DDR memory errors via extracting error information from the IMC MC error codes) for Sapphire Rapids for better decoding performance.
Enhance the SPR HBM EDAC driver to decode errors from the 1st level memory (the fast "near" memory as cache) of the 2-level memory system.

It will be valuable to avoid SMI triggered to call firware decoder, especially when CE (Correctable Error) triggered frequently on DDR memory.

6e8746cb EDAC/skx_common: Enable EDAC support for the "near" memory.
221aa03f EDAC/i10nm: Add driver decoder for Sapphire Rapids server.

[Testing]
download: https://git.kernel.org/pub/scm/linux/kernel/git/aegl/ras-tools.git
# echo 1 > /sys/module/i10nm_edac/parameters/decoding_via_mca
# modprobe einj
# cd /home/ras-tools/
# ./cmcistorm 1
0: vaddr = 0x117b490 paddr = 4884ef490
# dmesg and check the address was decoded.
 
 
Link:https://gitee.com/openeuler/kernel/pulls/742 

Reviewed-by: Jason Zeng <jason.zeng@intel.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @yunyingsun 
 
Title: Add PMU support for Intel Emerald Rapids
 
Content:
This PR adds Performance Monitoring Unit(PMU) support for next Intel Xeon platform Emerald Rapids.

Totally 6 commits, including 4 EMR PMU enabling patches from v6.2 and 2 dependent patches from v5.14/v5.18:
(v6.2-rc6) 5a8a05f1 perf/x86/intel/cstate: Add Emerald Rapids
	(v5.18-rc4) 528c9f1d perf/x86/cstate: Add SAPPHIRERAPIDS_X CPU support
	(v5.14-rc1) 87bf399f perf/x86/cstate: Add ICELAKE_X and ICELAKE_D support
(v6.2-rc6) 6795e558 perf/x86/intel: Add Emerald Rapids
(v6.2-rc4) 5268a284 perf/x86/intel/uncore: Add Emerald Rapids
(v6.2-rc4) 69ced416 perf/x86/msr: Add Emerald Rapids

The four 6.2 patches above use a macro "INTEL_FAM6_EMERALDRAPIDS_X", which is introduced by:
(v6.1-rc1) 7beade0d x86/cpu: Add several Intel server CPU model numbers
This patch is already included in another PR:
https://gitee.com/openeuler/kernel/pulls/469

Note: this PR for PMU must be merged AFTER PR-469, otherwise there will be kernel compiling error complaining for missing definition of macro "INTEL_FAM6_EMERALDRAPIDS_X".

Intel-kernel issue:
https://gitee.com/openeuler/intel-kernel/issues/I6YO4Z
 
Test:
1. platform dependent core PMU event works with perf, like "L1-dcache-loads".
2. platform dependent uncore PMU event works with perf, like "uncore_imc_0/event=0x1/".
3. offcore event works with perf.
3. PEBS works with perf.
4. topdown works with perf.
With this PR(along with the patch from PR469) applied to kernel OLK-5.10, all tests above PASS on EMR.

Known issue:
N/A
 
Default config change:
N/A


 
 
Link:https://gitee.com/openeuler/kernel/pulls/622 

Reviewed-by: Jason Zeng <jason.zeng@intel.com> 
Reviewed-by: Aichun Shi <aichun.shi@intel.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @yunyingsun 
 
Running Average Power Limit (RAPL) is an interface for reporting accumulated energy consumption of various system-on-chip (SoC) power domains. The RAPL energy reporting feature has been available for many generations on Intel SoC products.

To enable perf collecting RAPL events on future Intel Xeon platform Emerald Rapids, below upstream commit is needed:
(v6.2-rc3)  57512b57 perf/x86/rapl: Add support for Intel Emerald Rapids

This patch uses a macro "INTEL_FAM6_EMERALDRAPIDS_X" which is introduced with upstream commit:
(v6.1-rc1) 7beade0d x86/cpu: Add several Intel server CPU model numbers
which has been backported to OLK-5.10 earlier with this PR(under review, not merged yet):
https://gitee.com/openeuler/kernel/pulls/469
So here setting PR-469 as a dependency of this RAPL backport.

Note: this PR must be merged AFTER PR-469, otherwise there will be kernel compiling error complaining for missing definition of macro "INTEL_FAM6_EMERALDRAPIDS_X".

Intel-Kernel Issue:
https://gitee.com/openeuler/intel-kernel/issues/I6YGL6

Test:
With the patches in this PR included, running command below will list energy-psys events on EMR:
$ perf list power | grep energy-psys
Without the patches, no energy-psys event is available.
It's verified that test is PASS on Intel EMR pre-production platform.

Known Issue:
N/A

Default config change:
N/A 
 
Link:https://gitee.com/openeuler/kernel/pulls/615 

Reviewed-by: Jason Zeng <jason.zeng@intel.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

mainline inclusion
from mainline-v6.3-rc1
commit ced18fd1
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

1. Remove extra blank lines.
2. Remove extra spaces.
3. Use spaces instead of tabs around '=' and '\',
to ensure consistent coding styles.
4. Macros should be capital letters, change 'QM_SQC_VFT_NUM_MASK_v2'
to 'QM_SQC_VFT_NUM_MASK_V2'.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.3-rc1
commit 9b4eb8f8
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

The return values of some functions have been modified,
but the comments have not been modified together. The
comments must be updated to be consistent with the functions.

Also move comments over the codes instead of right place
to ensure consistent coding styles.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.3-rc1
commit ac80056f
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

The accelerator devices support multiple interrupts.
To better reflect purpose of each interrupt function,
change function name 'qm_irq' to 'qm_eq_irq' and 'do_qm_irq'
to 'do_qm_eq_irq'.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.3-rc1
commit f8de067c
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

'act_q_num = min_t(int, act_q_num, max_qp_num)', the type
of 'act_q_num' and 'max_qp_num' are both 'u32', so
use min() instead of min_t().
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.3-rc1
commit a292f253
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

1. Remove some macros define since it is not used.
2. Remove enum QM_HW_UNKNOWN since it is not used.
3. Remove unused member 'is_frozen' in 'hisi_qm' structure.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.3-rc1
commit aa85923a
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

To work around a Clang __builtin_object_size bug that shows up under
CONFIG_FORTIFY_SOURCE and UBSAN_BOUNDS, move the per-loop-iteration
mem_block wipe into a single wipe of the entire pool structure after
the loop.
Reported-by: NNathan Chancellor <nathan@kernel.org>
Link: https://github.com/ClangBuiltLinux/linux/issues/1780
Cc: Weili Qian <qianweili@huawei.com>
Cc: Zhou Wang <wangzhou1@hisilicon.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Signed-off-by: NKees Cook <keescook@chromium.org>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Link: https://lore.kernel.org/r/20230106041945.never.831-kees@kernel.orgSigned-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.3-rc1
commit cd0ac51c
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

Define the device isolation strategy by the device driver. The
user configures a hardware error threshold value by uacce interface.
If the number of hardware errors exceeds the value of setting error
threshold in one hour. The device will not be available in user space.
The VF device use the PF device isolation strategy. All the hardware
errors are processed by PF driver.
Signed-off-by: NKai Ye <yekai13@huawei.com>
Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
Link: https://lore.kernel.org/r/20221119074817.12063-4-yekai13@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.3-rc1
commit e3e289fb
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

UACCE adds the hardware error isolation feature. To improve service
reliability, some uacce devices that frequently encounter hardware
errors are isolated. Therefore, this feature is added.

Users can configure the hardware error threshold by 'isolate_strategy'
sysfs node. The user space can get the device isolated state by 'isolate'
sysfs node. If the number of device errors exceeds the configured error
threshold, the device will be isolated. It means the uacce device is
unavailable.
Signed-off-by: NKai Ye <yekai13@huawei.com>
Link: https://lore.kernel.org/r/20221119074817.12063-2-yekai13@huawei.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.3-rc1
commit 00bef64a
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

While reviewing dependencies in some Kconfig files, I noticed the redundant
dependency "depends on PCI && PCI_MSI". The config PCI_MSI has always,
since its introduction, been dependent on the config PCI. So, it is
sufficient to just depend on PCI_MSI, and know that the dependency on PCI
is implicitly implied.

Reduce the dependencies of configs CRYPTO_DEV_HISI_SEC2,
CRYPTO_DEV_HISI_QM, CRYPTO_DEV_HISI_ZIP and CRYPTO_DEV_HISI_HPRE.

No functional change and effective change of Kconfig dependendencies.
Signed-off-by: NLukas Bulwahn <lukas.bulwahn@gmail.com>
Acked-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 2ae6feb1
category: bugfix
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

Commit d2825fa9 ("crypto: sm3,sm4 - move into crypto directory") moves
the SM3 and SM4 stand-alone library and the algorithm implementation for
the Crypto API into the same directory, and the corresponding relationship
of Kconfig is modified, CONFIG_CRYPTO_SM3/4 corresponds to the stand-alone
library of SM3/4, and CONFIG_CRYPTO_SM3/4_GENERIC corresponds to the
algorithm implementation for the Crypto API. Therefore, it is necessary
for this module to depend on the correct algorithm.

Fixes: d2825fa9 ("crypto: sm3,sm4 - move into crypto directory")
Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Cc: stable@vger.kernel.org # v5.19+
Signed-off-by: NTianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 5f9c97a0
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

In function 'hisi_qm_resume', if the device fails to be started,
directly returning error code will cause the device to be unavailable.
However, the failure may be caused by device error, which will be
reported to the driver, and driver can reset and restart device.
Therefore, check device status instead of returning error code
directly. Returns 0 if device error has occurred, otherwise returns
error code.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 5ba78373
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

The value of reqsize must only be changed through the helper.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Reviewed-by: NLongfang Liu <liulongfang@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 56861cbd
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

The value of reqsize should only be changed through a helper.
To do so we need to first add a helper for this.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 39013556
category: bugfix
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

'QM_XEQ_DEPTH_CAP' mask value is GENMASK(31, 0) instead of GENMASK(15, 0).
If the mask value is incorrect, will cause abnormal events cannot be
handled. So fix it.

Fixes: 129a9f34 ("crypto: hisilicon/qm - get qp num and depth from hardware registers")
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 75df46b5
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

Fix that put two or more continuous blank lines inside function.
Signed-off-by: NWenkai Lin <linwenkai6@hisilicon.com>
Signed-off-by: NKai Ye <yekai13@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 2132d4ef
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

There are a couple of spelling mistakes in sec2. Fix them.
Signed-off-by: NKai Ye <yekai13@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 9c756098
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

Reduce the function complexity by use the function table in the
process of dumping queue. The function input parameters are
unified. And maintainability is enhanced.
Signed-off-by: NKai Ye <yekai13@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 94476b2b
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

Considering that the qm feature and debugfs feature are independent.
The code related to debugfs is getting larger and larger. It should be
separate as a debugfs file. So move some debugfs code to new file from
qm file. The qm code logic is not modified. And maintainability is
enhanced.
Signed-off-by: NKai Ye <yekai13@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit b40b62ed
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

The last register logic and different register logic are combined.
Use "u32" instead of 'int' in the regs function input parameter to
simplify some checks.
Signed-off-by: NKai Ye <yekai13@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>

mainline inclusion
from mainline-v6.2-rc1
commit 7bbbc9d8
category: feature
bugzilla: https://gitee/com/openeuler/kernel/issues/16VW8E
CVE: NA

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

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

There is no security data in the pointer. It is only a value transferred
as a structure. It makes no sense to zero a variable that is on the stack.
So not need to set the pointer to null.
Signed-off-by: NKai Ye <yekai13@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJangShui <yangjiangshui@h-partners.com>