maillist inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I76PUJ

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

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

For hns, the specification of an entry like resource (E.g. WQE/CQE/EQE)
depends on BT page size, buf page size and hopnum. For user mode, the buf
page size depends on UMEM. Therefore, the actual specification is
controlled by BT page size and hopnum.

The current BT page size and hopnum are obtained from firmware. This makes
the driver inflexible and introduces unnecessary constraints.  Resource
allocation failures occur in many scenarios.

This patch will calculate whether the BT page size set by firmware is
sufficient before allocating BT, and increase the BT page size if it is
insufficient.

Fixes: 11334014 ("RDMA/hns: Optimize base address table config flow for qp buffer")
Link: https://lore.kernel.org/r/20230512092245.344442-3-huangjunxian6@hisilicon.comSigned-off-by: NChengchang Tang <tangchengchang@huawei.com>
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Signed-off-by: NZhou Juan <nnuzj07170227@163.com>

maillist inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I76PRT

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?id=58caa2a51ad4

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

On HIP08, the queried timeout attr is different from the timeout attr
configured by the user.

It is found by rdma-core testcase test_rdmacm_async_traffic:

======================================================================
FAIL: test_rdmacm_async_traffic (tests.test_rdmacm.CMTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./tests/test_rdmacm.py", line 33, in test_rdmacm_async_traffic
    self.two_nodes_rdmacm_traffic(CMAsyncConnection, self.rdmacm_traffic,
  File "./tests/base.py", line 382, in two_nodes_rdmacm_traffic
    raise(res)
AssertionError

Fixes: 926a01dc ("RDMA/hns: Add QP operations support for hip08 SoC")
Link: https://lore.kernel.org/r/20230512092245.344442-2-huangjunxian6@hisilicon.comSigned-off-by: NChengchang Tang <tangchengchang@huawei.com>
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Signed-off-by: NZhou Juan <nnuzj07170227@163.com>

Merge Pull Request from: @remimin 
 
https://gitee.com/openeuler/kernel/issues/I6XQ34 
 
Link:https://gitee.com/openeuler/kernel/pulls/601 

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

Merge Pull Request from: @remimin 
 
https://gitee.com/openeuler/kernel/issues/I72190 
 
Link:https://gitee.com/openeuler/kernel/pulls/739 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> 
Reviewed-by: sanglipeng <sanglipeng1@jd.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @lyyue233 
 
issue:
[#I72XT8](https://gitee.com/openeuler/kernel/issues/I72XT8)
Uninitialized variables can cause various errors in a program, such as unexpected behavior, segmentation faults, or even security vulnerabilities.

To avoid these errors, we should always initialize variables before using them.Initialize variable “ err ” to address potential issues. 
 
Link:https://gitee.com/openeuler/kernel/pulls/767 

Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Acked-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @guzitao 
 
These patches generally cover the following tasks:

1.optimize kernel cores, remove unused codes, fix compile errors
2.fixes for perf, iommu, kvm, cpufreq, efi, struct pt_regs
3.add support, add support for restartable sequences, trace user task unalignment, add libbfd support in perf
4.optimize DIV and MOD instructions for bpf 
 
Link:https://gitee.com/openeuler/kernel/pulls/777 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 
Acked-by: Xie XiuQi <xiexiuqi@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from:  Jialin Zhang <zhangjialin11@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/MYPG5M6GX66MEDMYSKLAETDPV37U7LWQ/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/824 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

3snic inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I77U9U
CVE: NA

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

Net: ethernet: 3snic 3s9xx network Kconfig add "select NET_DEVLINK"
Signed-off-by: NSteven Song <steven.song@3snic.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

Merge Pull Request from: @zhangjialin11 
 
This reverts commit 932afc18.

Fix build error in riscv64:
build failed: riscv, allmodconfig

arch/riscv/kernel/smpboot.o: In function `smp_callin':
(.text+0x160): undefined reference to `store_cpu_topology'
arch/riscv/kernel/smpboot.o: In function `smp_prepare_cpus':
(.init.text+0x212): undefined reference to `store_cpu_topology'
make: *** [vmlinux] Error 1 
 
Link:https://gitee.com/openeuler/kernel/pulls/821 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

Merge Pull Request from: @nebula_matrix 
 
M1600 dirver depend on CONFIG_HWMON, let's add the dependency.

Bugfix：https://gitee.com/openeuler/kernel/issues/I77UIM?from=project-issue 
 
Link:https://gitee.com/openeuler/kernel/pulls/820 

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

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I73HJ0

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

This reverts commit 932afc18.

Fix build error in riscv64:
build failed: riscv, allmodconfig

arch/riscv/kernel/smpboot.o: In function `smp_callin':
(.text+0x160): undefined reference to `store_cpu_topology'
arch/riscv/kernel/smpboot.o: In function `smp_prepare_cpus':
(.init.text+0x212): undefined reference to `store_cpu_topology'
make: *** [vmlinux] Error 1
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

    m1600-dirver inclusion
    category: bugfix
    bugzilla: https://gitee.com/openeuler/kernel/issues/I77UIM
    CVE: NA

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

    M1600 dirver depend on CONFIG_HWMON, let's add the dependency.
Signed-off-by: NYi Chen <open@nebula-matrix.com>

Merge Pull Request from: @Hongchen_Zhang 
 
a double free problem in stmmac driver was triggered when doing mugen test,
After apply this patch the double free problem disappear. 
 
Link:https://gitee.com/openeuler/kernel/pulls/761 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> 
Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

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

Conflicts:

Already merged(3):
935a8b620210 mm/memory: add non-anonymous page check in the copy_present_page()
568e3812b177 mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages
  (Already merged mainline commit 12df140f mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pages)
d523384766fd scsi: sd: Revert "scsi: sd: Remove a local variable"
  (Already merged commit 7d7fe3e4 scsi: sd: Revert "scsi: sd: Remove a local variable") 

Context confilict(1):  
3b250824b6d3 xhci: Add quirk to reset host back to default state at shutdown
        
Rejected(4):
ce605b68db53 net: hinic: fix incorrect assignment issue in hinic_set_interrupt_cfg()
  (The involved file drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c is already deleted
    by the commit f1168d29 net/hinic: Update Hardware Abstract Layer)
bb01910763f9 net: hinic: fix memory leak when reading function table
  (The involved file drivers/net/ethernet/huawei/hinic/hinic_debugfs.c is already deleted
    by the commit f1168d29 net/hinic: Update Hardware Abstract Layer)
6603843c80b1 net: hinic: fix the issue of CMDQ memory leaks
  (The involved file drivers/net/ethernet/huawei/hinic/hinic_hw_cmdq.c is already deleted
    by the commit f1168d29 net/hinic: Update Hardware Abstract Layer))
0ce1ef335300 net: hinic: fix the issue of double release MBOX callback of VF
   (The involved function hinic_vf_func_init() is moved to other file.)

Total patches: 91 - 3 - 4 = 84 
 
Link:https://gitee.com/openeuler/kernel/pulls/807 

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

Merge Pull Request from: @hejunhao3 
 
1. Compared with the PAv2 PMU, the PAv3 PMU has different event
IDs and definitions. The version number in the version register
is used to distinguish the event IDs and definitions in the driver.
2. The H60PA PMU and PA are two different devices. The H60PA PMU
supports higher bandwidth, and the PA PMU delay is relatively low.
Different HIDs are used to distinguish the delay.
3. Each cluster is integrated with a unified cache (UC) PMU, which
provides consistency between NUMA and UMA domains. It sits between
L2 and the memory system. 
 
Link:https://gitee.com/openeuler/kernel/pulls/805 

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

Merge Pull Request from: @leoliu-oc 
 
On all recent Centaur platforms, ARB_DISABLE is handled by PMU automatically while entering C3 type state. No need for OS to issue the ARB_DISABLE, so set bm_control to zero to indicate that.

### Issue
https://gitee.com/openeuler/kernel/issues/I6SKA2

### Test
N/A

### Knowe Issue
N/A

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

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

Merge Pull Request from: @Linwang_68f8 
 
 **Content:** 
This PR involves x86/FPU and dynamitic feature (AMX) related bug fixes since kernel V5.18.

There are 15 patches in total in this patch set:
1. x86/fpu: Cure supervisor mode (ENQCMD) fallout
The (re)enabling of ENQCMD or the enabling of any supervisor only state results in a possible inconsistency of the host and guest FPU XSTATE layout on systems which support that feature.
d6d6d50f x86/fpu/xstate: Consolidate size calculations
781c64bf x86/fpu/xstate: Handle supervisor states in XSTATE permissions
7aa5128b x86/fpu/xsave: Handle compacted offsets correctly with supervisor states
6afbb58c x86/fpu: Cache xfeature flags from CPUID
35a77d45 x86/fpu/xsave: Initialize offset/size cache early
d47f71f6 x86/fpu: Remove unused supervisor only offsets
a9f84fb7 x86/fpu: Remove redundant XCOMP_BV initialization

2. x86/fpu: Improve the init_fpstate setup code
Background:
The init_fpstate is an XSAVE image that records init states during the boot time. It is presumed to cover all the supported and enabled features. The setup code has been recently optimized to capture legacy states only as all of the other init states are all zeros.
Problem with AMX state:
When AMX is enabled, this buffer is too small to include AMX TILE_DATA (8KB) as it is statically allocated with about a page. But, the buffer is formatted to have them all although using the compacted format.
471f0aa7 x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly
a401f45e x86/fpu: Exclude dynamic states from init_fpstate
d3e021ad x86/fpu: Fix the init_fpstate size check with the actual size
c32d7cab x86/fpu: Configure init_fpstate attributes orderly

3. x86/fpu/xstate: Follow up on the init_fpstate fallout again
When copying the non-initialized dynamic state from the task xstate, the code unconditionally retrieves the address in init_fpstate which is needless. Consequently, this triggers a false-positive warning which meaninglessly confuses users.
62faca1c selftests/x86/amx: Add a ptrace test
b1588884 x86/fpu/xstate: Prevent false-positive warning in __copy_xstate_uabi_buf()
2ba8a7ab selftests/x86/amx: Use provided __cpuid_count() macro
a23039c7 selftests: Provide local define of __cpuid_count()

 **Intel-kernel issue:** 
#I73H0T: https://gitee.com/openeuler/intel-kernel/issues/I73H0T

 **Test environment:** 
openEuler 22.03 SP1 + backporting kernel

 **Test cases:** 
dmesg checking to make sure no fpu corruption found.
kernel self-test.
TMUL functional testing.
Context switch testing.
oneDNN/BenchDNN.


 **Known issue:** 
N/A

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

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

Merge Pull Request from: @allen-shi 
 
Intel In Field Scan (IFS) is a hardware feature to run circuit level tests on a CPU core to detect problems that are not caught by parity or ECC checks.

IFS Scan At Field(SAF) multi-blob images supported in [PR471](https://gitee.com/openeuler/kernel/pulls/471) and [PR580](https://gitee.com/openeuler/kernel/pulls/580)

IFS Array BIST performs tests on some portions of the core logic such as caches and register files. These are different portions of the silicon compared to the parts tested by the first test type i.e Scan at Field (SAF). Emerald Rapids (EMR) is the first CPU to support Array BIST.

This PR is to support In Field Scan(IFS) Array BIST and includes 9 commits totally.
It is upstreamed in v6.4-rc1.
https://lore.kernel.org/lkml/20230322003359.213046-1-jithu.joseph@intel.com/

 
 **Intel-Kernel Issue** 
[#I73EG8](https://gitee.com/openeuler/intel-kernel/issues/I73EG8)

 **Test** 
Built and run the kernel successfully on openEuler 22.03 LTS SP1.
Test is PASS on EMR platform.

 **Known Issue** 
N/A

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

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

Merge Pull Request from: @etzhao 
 
Hi,

Bus lock detection EMR CPU support for OpenEuler backporting was tested Okay, help to review and merge

Title: bus lock detection and ratelimit feature for OpenEuler.

Passed test cases
No function change.
#dmesg 
 see
 [    0.000000] x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks
#cat /proc/cpuinfo |grep split 
 split_lock_detect
 
Known issue:
No

Default config change:
No

Thanks,
Ethan 
 
Link:https://gitee.com/openeuler/kernel/pulls/781 

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

Merge Pull Request from: @Hongchen_Zhang 
 
The virtual machine will cause the physical machine to die when using the huge page because kvm does not enable the huge page feature,
In order to fix this problem,kvm need to enable the huge page feature when the physical machine enable the huge page feature at the same time.

Test passed with below step:
1.Allocate huge page resources to virtual machines
echo 68 > /sys/kernel/mm/hugepages/hugepages-32768kB/nr_hugepages
mount -t hugetlbfs -o pagesize=32768K none /mnt/kvm_hugepage

2.Start a virtual machine with huge page
MALLOC_PERTURB_=1  /usr/libexec/qemu-kvm
    -name 'avocado-vt-vm1'
    -machine loongson7a,memory-backend=mem-machine_mem
    -device pcie-root-port,id=pcie-root-port-0,multifunction=on,bus=pcie.0,addr=0x1,chassis=1
    -device pcie-pci-bridge,id=pcie-pci-bridge-0,addr=0x0,bus=pcie-root-port-0 
    -nodefaults
    -device qxl-vga,bus=pcie.0,addr=0x2
    -m 2048
    -object memory-backend-file,size=2048M,mem-path=/mnt/kvm_hugepage,id=mem-machine_mem 
    -smp 2,maxcpus=2,cores=2,threads=1,sockets=1 
    -cpu 'Loongson-3A5000'
    -device pcie-root-port,id=pcie-root-port-1,port=0x1,addr=0x1.0x1,bus=pcie.0,chassis=2
    -device qemu-xhci,id=usb1,bus=pcie-root-port-1,addr=0x0
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1
    -device pcie-root-port,id=pcie-root-port-2,port=0x2,addr=0x1.0x2,bus=pcie.0,chassis=3
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pcie-root-port-2,addr=0x0
    -blockdev node-name=file_image1,driver=file,filename=/root/avocado/data/avocado-vt/images/openEuler-22.03-loongarch64.qcow2
    -blockdev node-name=drive_image1,driver=qcow2,file=file_image1
    -device scsi-hd,id=image1,drive=drive_image1
    -device pcie-root-port,id=pcie-root-port-3,port=0x3,addr=0x1.0x3,bus=pcie.0,chassis=4
    -device virtio-net-pci,mac=9a:ab:6e:88:2f:5b,id=idk4GfF4,netdev=idwjd54m,bus=pcie-root-port-3,addr=0x0 
    -netdev tap,id=idwjd54m 
    -vnc :0 
    -rtc base=utc,clock=host 
    -boot menu=off,order=cdn,once=c,strict=off
    -bios /usr/share/qemu/loongarch_bios.bin
    -enable-kvm
    -monitor telnet:localhost:4444,server,nowait
    -serial stdio 
 
Link:https://gitee.com/openeuler/kernel/pulls/760 

Reviewed-by: Guo Dongtai <guodongtai@kylinos.cn> 
Reviewed-by: Kevin Zhu <zhukeqian1@huawei.com> 
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

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

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

On HiSilicon Hip09 platform, there is a UC (unified cache) module
on each chip SCCL (Super CPU Cluster). UC is a cache that provides
coherence between NUMA and UMA domains. It is located between L2
and Memory System. While PA uncore PMU model is the same as other
Hip09 PMU modules and many PMU events are supported. Let's support
the PMU driver using the HiSilicon uncore PMU framework.

* rd_req_en : rd_req_en is the abbreviation of read request tracetag enable
and allows user to count only read operations.
details are listed in the hisi-pmu document.

* srcid_en & srcid: allows user to filter statistics that come from
specific CPU/ICL by configuration source ID.

* uring_channel: Allows users to filter statistical information based on
the specified tx request uring channel.
uring_channel only supported events: [0x47 ~ 0x59].
Signed-off-by: NJunhao He <hejunhao3@huawei.com>

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

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

Compared to the original PA device, H60PA offers higher bandwidth.
The PA H60 is a new device and we use HID to differentiate them.

The events supported by PAv3 and PAv2 are different. They use the
same HID. The PMU version register is used in the driver to
distinguish different versions.

For each H60PA PMU, except for the overflow interrupt register, other
functions of the H60PA PMU are the same as the original PA PMU module.
It has 8-programable counters and each counter is free-running.
Interrupt is supported to handle counter (64-bits) overflow.
Signed-off-by: NJunhao He <hejunhao3@huawei.com>

mainline inclusion
from mainline-v6.4-rc1
commit 257aedb7
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6
CVE: NA

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

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

When allocations fails that can be NULL now.

If the name provided is NULL, then the initialization process of the PMU
type and dev will be skipped in function perf_pmu_register().
Consequently, the PMU will not be able to register into the kernel.
Moreover, in the case of unregister the PMU, the function device_del()
will need to handle NULL pointers, which potentially can cause issues.

So move this allocation above the cpuhp_state_add_instance() and directly
return if it does fail.
Signed-off-by: NJunhao He <hejunhao3@huawei.com>

mainline inclusion
from mainline-v6.4-rc1
commit 25d8c250
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6
CVE: NA

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

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

"pmu->name" is initialized by perf_pmu_register() function, so remove
the redundant initialized in hisi_pmu_init().
Signed-off-by: NJunhao He <hejunhao3@huawei.com>

mainline inclusion
from mainline-v6.3-rc1
commit e126f6f4
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I77IH6
CVE: NA

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

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

Use hisi_pmu_init() function to simplify initialization of "cpa_pmu->pmu".
Signed-off-by: NJunhao He <hejunhao3@huawei.com>
Link: https://lore.kernel.org/r/20230119100307.3660-4-hejunhao3@huawei.comSigned-off-by: NWill Deacon <will@kernel.org>

stable inclusion
from stable-v5.10.153
commit 26a2b9c468de495902fb914c050b4e8611764b2a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

commit 7c7f9bc9 upstream.

When a UART port is newly registered, uart_configure_port() seeks to
deassert RS485 Transmit Enable by setting the RTS bit in port->mctrl.
However a number of UART drivers interpret a set RTS bit as *assertion*
instead of deassertion:  Affected drivers include those using
serial8250_em485_config() (except 8250_bcm2835aux.c) and some using
mctrl_gpio (e.g. imx.c).

Since the interpretation of the RTS bit is driver-specific, it is not
suitable as a means to centrally deassert Transmit Enable in the serial
core.  Instead, the serial core must call on drivers to deassert it in
their driver-specific way.  One way to achieve that is to call
->rs485_config().  It implicitly deasserts Transmit Enable.

So amend uart_configure_port() and uart_resume_port() to invoke
uart_rs485_config().  That allows removing calls to uart_rs485_config()
from drivers' ->probe() hooks and declaring the function static.

Skip any invocation of ->set_mctrl() if RS485 is enabled.  RS485 has no
hardware flow control, so the modem control lines are irrelevant and
need not be touched.  When leaving RS485 mode, reset the modem control
lines to the state stored in port->mctrl.  That way, UARTs which are
muxed between RS485 and RS232 transceivers drive the lines correctly
when switched to RS232.  (serial8250_do_startup() historically raises
the OUT1 modem signal because otherwise interrupts are not signaled on
ancient PC UARTs, but I believe that no longer applies to modern,
RS485-capable UARTs and is thus safe to be skipped.)

imx.c modifies port->mctrl whenever Transmit Enable is asserted and
deasserted.  Stop it from doing that so port->mctrl reflects the RS232
line state.

8250_omap.c deasserts Transmit Enable on ->runtime_resume() by calling
->set_mctrl().  Because that is now a no-op in RS485 mode, amend the
function to call serial8250_em485_stop_tx().

fsl_lpuart.c retrieves and applies the RS485 device tree properties
after registering the UART port.  Because applying now happens on
registration in uart_configure_port(), move retrieval of the properties
ahead of uart_add_one_port().

Link: https://lore.kernel.org/all/20220329085050.311408-1-matthias.schiffer@ew.tq-group.com/
Link: https://lore.kernel.org/all/8f538a8903795f22f9acc94a9a31b03c9c4ccacb.camel@ginzinger.com/
Fixes: d3b3404d ("serial: Fix incorrect rs485 polarity on uart open")
Cc: stable@vger.kernel.org # v4.14+
Reported-by: NMatthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reported-by: NRoosen Henri <Henri.Roosen@ginzinger.com>
Tested-by: NMatthias Schiffer <matthias.schiffer@ew.tq-group.com>
Reviewed-by: NIlpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Link: https://lore.kernel.org/r/2de36eba3fbe11278d5002e4e501afe0ceaca039.1663863805.git.lukas@wunner.deSigned-off-by: NDaisuke Mizobuchi <mizo@atmark-techno.com>
Signed-off-by: NDominique Martinet <dominique.martinet@atmark-techno.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit 4a230f65d6a80c6658860c899f14f1d0bd0ca65b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

commit 0ed12afa upstream.

Several drivers that support setting the RS485 configuration via userspace
implement one or more of the following tasks:

- in case of an invalid RTS configuration (both RTS after send and RTS on
  send set or both unset) fall back to enable RTS on send and disable RTS
  after send

- nullify the padding field of the returned serial_rs485 struct

- copy the configuration into the uart port struct

- limit RTS delays to 100 ms

Move these tasks into the serial core to make them generic and to provide
a consistent behaviour among all drivers.
Signed-off-by: NLino Sanfilippo <LinoSanfilippo@gmx.de>
Link: https://lore.kernel.org/r/20220410104642.32195-2-LinoSanfilippo@gmx.deSigned-off-by: NDaisuke Mizobuchi <mizo@atmark-techno.com>
Signed-off-by: NDominique Martinet <dominique.martinet@atmark-techno.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit eb69c07eca22ffd8621d9de9378e4b3ce7965190
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

commit 702de2c2 upstream.

We are seeing an IRQ storm on the global receive IRQ line under heavy
CAN bus load conditions with both CAN channels enabled.

Conditions:

The global receive IRQ line is shared between can0 and can1, either of
the channels can trigger interrupt while the other channel's IRQ line
is disabled (RFIE).

When global a receive IRQ interrupt occurs, we mask the interrupt in
the IRQ handler. Clearing and unmasking of the interrupt is happening
in rx_poll(). There is a race condition where rx_poll() unmasks the
interrupt, but the next IRQ handler does not mask the IRQ due to
NAPIF_STATE_MISSED flag (e.g.: can0 RX FIFO interrupt is disabled and
can1 is triggering RX interrupt, the delay in rx_poll() processing
results in setting NAPIF_STATE_MISSED flag) leading to an IRQ storm.

This patch fixes the issue by checking IRQ active and enabled before
handling the IRQ on a particular channel.

Fixes: dd3bd23e ("can: rcar_canfd: Add Renesas R-Car CAN FD driver")
Suggested-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NBiju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/all/20221025155657.1426948-2-biju.das.jz@bp.renesas.com
Cc: stable@vger.kernel.org
[mkl: adjust commit message]
Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
[biju: removed gpriv from RCANFD_RFCC_RFIE macro]
Signed-off-by: NBiju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit d5924531dd8ad012ad13eb4d6a5e120c3dadfc05
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

commit 79d82cbc upstream.

The commit 26f55386 ("arm64/mm: Fix __enable_mmu() for new TGRAN range
values") had already switched into testing ID_AA64MMFR0_TGRAN range values.
This just changes system_supports_[4|16|64]kb_granule() helpers to perform
similar range tests as well. While here, it standardizes page size specific
supported min and max TGRAN values.

Cc: Will Deacon <will@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NAnshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/1626237975-1909-1-git-send-email-anshuman.khandual@arm.comSigned-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NZenghui Yu <yuzenghui@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit c911f03f8d444e623724fddd82b07a7e1af42338
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

commit 26f55386 upstream.

As per ARM ARM DDI 0487G.a, when FEAT_LPA2 is implemented, ID_AA64MMFR0_EL1
might contain a range of values to describe supported translation granules
(4K and 16K pages sizes in particular) instead of just enabled or disabled
values. This changes __enable_mmu() function to handle complete acceptable
range of values (depending on whether the field is signed or unsigned) now
represented with ID_AA64MMFR0_TGRAN_SUPPORTED_[MIN..MAX] pair. While here,
also fix similar situations in EFI stub and KVM as well.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: kvmarm@lists.cs.columbia.edu
Cc: linux-efi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Acked-by: NMarc Zyngier <maz@kernel.org>
Signed-off-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NAnshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/1615355590-21102-1-git-send-email-anshuman.khandual@arm.comSigned-off-by: NWill Deacon <will@kernel.org>
Signed-off-by: NZenghui Yu <yuzenghui@huawei.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit 52a43b82006dc88f996bd06da5a3fcfef85220c8
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

[ Upstream commit 0e5d5ae8 ]

Per AmpereOne erratum AC03_CPU_12, "Branch history may allow control of
speculative execution across software contexts," the AMPERE1 core needs the
bhb clearing loop to mitigate Spectre-BHB, with a loop iteration count of
11.
Signed-off-by: ND Scott Phillips <scott@os.amperecomputing.com>
Link: https://lore.kernel.org/r/20221011022140.432370-1-scott@os.amperecomputing.comReviewed-by: NJames Morse <james.morse@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit 9889ca7efa128916b52538110cf1bbb62055855a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

[ Upstream commit 84ce1ca3 ]

Under memory pressure, enetc_refill_rx_ring() may fail, and when called
during the enetc_open() -> enetc_setup_rxbdr() procedure, this is not
checked for.

An extreme case of memory pressure will result in exactly zero buffers
being allocated for the RX ring, and in such a case it is expected that
hardware drops all RX packets due to lack of buffers.

This does not happen, because the reset-default value of the consumer
and produces index is 0, and this makes the ENETC think that all buffers
have been initialized and that it owns them (when in reality none were).

The hardware guide explains this best:

| Configure the receive ring producer index register RBaPIR with a value
| of 0. The producer index is initially configured by software but owned
| by hardware after the ring has been enabled. Hardware increments the
| index when a frame is received which may consume one or more BDs.
| Hardware is not allowed to increment the producer index to match the
| consumer index since it is used to indicate an empty condition. The ring
| can hold at most RBLENR[LENGTH]-1 received BDs.
|
| Configure the receive ring consumer index register RBaCIR. The
| consumer index is owned by software and updated during operation of the
| of the BD ring by software, to indicate that any receive data occupied
| in the BD has been processed and it has been prepared for new data.
| - If consumer index and producer index are initialized to the same
|   value, it indicates that all BDs in the ring have been prepared and
|   hardware owns all of the entries.
| - If consumer index is initialized to producer index plus N, it would
|   indicate N BDs have been prepared. Note that hardware cannot start if
|   only a single buffer is prepared due to the restrictions described in
|   (2).
| - Software may write consumer index to match producer index anytime
|   while the ring is operational to indicate all received BDs prior have
|   been processed and new BDs prepared for hardware.

Normally, the value of rx_ring->rcir (consumer index) is brought in sync
with the rx_ring->next_to_use software index, but this only happens if
page allocation ever succeeded.

When PI==CI==0, the hardware appears to receive frames and write them to
DMA address 0x0 (?!), then set the READY bit in the BD.

The enetc_clean_rx_ring() function (and its XDP derivative) is naturally
not prepared to handle such a condition. It will attempt to process
those frames using the rx_swbd structure associated with index i of the
RX ring, but that structure is not fully initialized (enetc_new_page()
does all of that). So what happens next is undefined behavior.

To operate using no buffer, we must initialize the CI to PI + 1, which
will block the hardware from advancing the CI any further, and drop
everything.

The issue was seen while adding support for zero-copy AF_XDP sockets,
where buffer memory comes from user space, which can even decide to
supply no buffers at all (example: "xdpsock --txonly"). However, the bug
is present also with the network stack code, even though it would take a
very determined person to trigger a page allocation failure at the
perfect time (a series of ifup/ifdown under memory pressure should
eventually reproduce it given enough retries).

Fixes: d4fd0404 ("enetc: Introduce basic PF and VF ENETC ethernet drivers")
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: NClaudiu Manoil <claudiu.manoil@nxp.com>
Link: https://lore.kernel.org/r/20221027182925.3256653-1-vladimir.oltean@nxp.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit fdba224ab02873a2998acf9d11ae5ac9a1e35717
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

[ Upstream commit aefb62a9 ]

When setting Bluefield to DPU NIC mode using mlxconfig tool +  sync
firmware reset flow, we run into scenario where the host was not
eswitch manager at the time of mlx5 driver load but becomes eswitch manager
after the sync firmware reset flow. This results in null pointer
access of mpfs structure during mac filter add. This change prevents null
pointer access but mpfs table entries will not be added.

Fixes: 5ec69744 ("net/mlx5: Add support for devlink reload action fw activate")
Signed-off-by: NSuresh Devarakonda <ramad@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Reviewed-by: NBodong Wang <bodong@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Link: https://lore.kernel.org/r/20221026135153.154807-12-saeed@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit bbcc06933f35651294ea1e963757502312c2171f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

[ Upstream commit bacd22df ]

mlx5_cmd_cleanup_async_ctx should return only after all its callback
handlers were completed. Before this patch, the below race between
mlx5_cmd_cleanup_async_ctx and mlx5_cmd_exec_cb_handler was possible and
lead to a use-after-free:

1. mlx5_cmd_cleanup_async_ctx is called while num_inflight is 2 (i.e.
   elevated by 1, a single inflight callback).
2. mlx5_cmd_cleanup_async_ctx decreases num_inflight to 1.
3. mlx5_cmd_exec_cb_handler is called, decreases num_inflight to 0 and
   is about to call wake_up().
4. mlx5_cmd_cleanup_async_ctx calls wait_event, which returns
   immediately as the condition (num_inflight == 0) holds.
5. mlx5_cmd_cleanup_async_ctx returns.
6. The caller of mlx5_cmd_cleanup_async_ctx frees the mlx5_async_ctx
   object.
7. mlx5_cmd_exec_cb_handler goes on and calls wake_up() on the freed
   object.

Fix it by syncing using a completion object. Mark it completed when
num_inflight reaches 0.

Trace:

BUG: KASAN: use-after-free in do_raw_spin_lock+0x23d/0x270
Read of size 4 at addr ffff888139cd12f4 by task swapper/5/0

CPU: 5 PID: 0 Comm: swapper/5 Not tainted 6.0.0-rc3_for_upstream_debug_2022_08_30_13_10 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
 <IRQ>
 dump_stack_lvl+0x57/0x7d
 print_report.cold+0x2d5/0x684
 ? do_raw_spin_lock+0x23d/0x270
 kasan_report+0xb1/0x1a0
 ? do_raw_spin_lock+0x23d/0x270
 do_raw_spin_lock+0x23d/0x270
 ? rwlock_bug.part.0+0x90/0x90
 ? __delete_object+0xb8/0x100
 ? lock_downgrade+0x6e0/0x6e0
 _raw_spin_lock_irqsave+0x43/0x60
 ? __wake_up_common_lock+0xb9/0x140
 __wake_up_common_lock+0xb9/0x140
 ? __wake_up_common+0x650/0x650
 ? destroy_tis_callback+0x53/0x70 [mlx5_core]
 ? kasan_set_track+0x21/0x30
 ? destroy_tis_callback+0x53/0x70 [mlx5_core]
 ? kfree+0x1ba/0x520
 ? do_raw_spin_unlock+0x54/0x220
 mlx5_cmd_exec_cb_handler+0x136/0x1a0 [mlx5_core]
 ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core]
 ? mlx5_cmd_cleanup_async_ctx+0x220/0x220 [mlx5_core]
 mlx5_cmd_comp_handler+0x65a/0x12b0 [mlx5_core]
 ? dump_command+0xcc0/0xcc0 [mlx5_core]
 ? lockdep_hardirqs_on_prepare+0x400/0x400
 ? cmd_comp_notifier+0x7e/0xb0 [mlx5_core]
 cmd_comp_notifier+0x7e/0xb0 [mlx5_core]
 atomic_notifier_call_chain+0xd7/0x1d0
 mlx5_eq_async_int+0x3ce/0xa20 [mlx5_core]
 atomic_notifier_call_chain+0xd7/0x1d0
 ? irq_release+0x140/0x140 [mlx5_core]
 irq_int_handler+0x19/0x30 [mlx5_core]
 __handle_irq_event_percpu+0x1f2/0x620
 handle_irq_event+0xb2/0x1d0
 handle_edge_irq+0x21e/0xb00
 __common_interrupt+0x79/0x1a0
 common_interrupt+0x78/0xa0
 </IRQ>
 <TASK>
 asm_common_interrupt+0x22/0x40
RIP: 0010:default_idle+0x42/0x60
Code: c1 83 e0 07 48 c1 e9 03 83 c0 03 0f b6 14 11 38 d0 7c 04 84 d2 75 14 8b 05 eb 47 22 02 85 c0 7e 07 0f 00 2d e0 9f 48 00 fb f4 <c3> 48 c7 c7 80 08 7f 85 e8 d1 d3 3e fe eb de 66 66 2e 0f 1f 84 00
RSP: 0018:ffff888100dbfdf0 EFLAGS: 00000242
RAX: 0000000000000001 RBX: ffffffff84ecbd48 RCX: 1ffffffff0afe110
RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffffffff835cc9bc
RBP: 0000000000000005 R08: 0000000000000001 R09: ffff88881dec4ac3
R10: ffffed1103bd8958 R11: 0000017d0ca571c9 R12: 0000000000000005
R13: ffffffff84f024e0 R14: 0000000000000000 R15: dffffc0000000000
 ? default_idle_call+0xcc/0x450
 default_idle_call+0xec/0x450
 do_idle+0x394/0x450
 ? arch_cpu_idle_exit+0x40/0x40
 ? do_idle+0x17/0x450
 cpu_startup_entry+0x19/0x20
 start_secondary+0x221/0x2b0
 ? set_cpu_sibling_map+0x2070/0x2070
 secondary_startup_64_no_verify+0xcd/0xdb
 </TASK>

Allocated by task 49502:
 kasan_save_stack+0x1e/0x40
 __kasan_kmalloc+0x81/0xa0
 kvmalloc_node+0x48/0xe0
 mlx5e_bulk_async_init+0x35/0x110 [mlx5_core]
 mlx5e_tls_priv_tx_list_cleanup+0x84/0x3e0 [mlx5_core]
 mlx5e_ktls_cleanup_tx+0x38f/0x760 [mlx5_core]
 mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core]
 mlx5e_detach_netdev+0x1ca/0x2b0 [mlx5_core]
 mlx5e_suspend+0xdb/0x140 [mlx5_core]
 mlx5e_remove+0x89/0x190 [mlx5_core]
 auxiliary_bus_remove+0x52/0x70
 device_release_driver_internal+0x40f/0x650
 driver_detach+0xc1/0x180
 bus_remove_driver+0x125/0x2f0
 auxiliary_driver_unregister+0x16/0x50
 mlx5e_cleanup+0x26/0x30 [mlx5_core]
 cleanup+0xc/0x4e [mlx5_core]
 __x64_sys_delete_module+0x2b5/0x450
 do_syscall_64+0x3d/0x90
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Freed by task 49502:
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x21/0x30
 kasan_set_free_info+0x20/0x30
 ____kasan_slab_free+0x11d/0x1b0
 kfree+0x1ba/0x520
 mlx5e_tls_priv_tx_list_cleanup+0x2e7/0x3e0 [mlx5_core]
 mlx5e_ktls_cleanup_tx+0x38f/0x760 [mlx5_core]
 mlx5e_cleanup_nic_tx+0xa7/0x100 [mlx5_core]
 mlx5e_detach_netdev+0x1ca/0x2b0 [mlx5_core]
 mlx5e_suspend+0xdb/0x140 [mlx5_core]
 mlx5e_remove+0x89/0x190 [mlx5_core]
 auxiliary_bus_remove+0x52/0x70
 device_release_driver_internal+0x40f/0x650
 driver_detach+0xc1/0x180
 bus_remove_driver+0x125/0x2f0
 auxiliary_driver_unregister+0x16/0x50
 mlx5e_cleanup+0x26/0x30 [mlx5_core]
 cleanup+0xc/0x4e [mlx5_core]
 __x64_sys_delete_module+0x2b5/0x450
 do_syscall_64+0x3d/0x90
 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Fixes: e355477e ("net/mlx5: Make mlx5_cmd_exec_cb() a safe API")
Signed-off-by: NTariq Toukan <tariqt@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Link: https://lore.kernel.org/r/20221026135153.154807-8-saeed@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit 16376ba5cfd7ee4a1d250ab42dd8418250b0cd97
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

[ Upstream commit 888be6b2 ]

An offloaded SA stops receiving after about 2^32 + replay_window
packets. For example, when SA reaches <seq-hi 0x1, seq 0x2c>, all
subsequent packets get dropped with SA-icv-failure (integrity_failed).

To reproduce the bug:
- ConnectX-6 Dx with crypto enabled (FW 22.30.1004)
- ipsec.conf:
  nic-offload = yes
  replay-window = 32
  esn = yes
  salifetime=24h
- Run netperf for a long time to send more than 2^32 packets
  netperf -H <device-under-test> -t TCP_STREAM -l 20000

When 2^32 + replay_window packets are received, the replay window
moves from the 2nd half of subspace (overlap=1) to the 1st half
(overlap=0). The driver then updates the 'esn' value in NIC
(i.e. seq_hi) as follows.

 seq_hi = xfrm_replay_seqhi(seq_bottom)
 new esn in NIC = seq_hi + 1

The +1 increment is wrong, as seq_hi already contains the correct
seq_hi. For example, when seq_hi=1, the driver actually tells NIC to
use seq_hi=2 (esn). This incorrect esn value causes all subsequent
packets to fail integrity checks (SA-icv-failure). So, do not
increment.

Fixes: cb010083 ("net/mlx5: IPSec, Add support for ESN")
Signed-off-by: NHyong Youb Kim <hyonkim@cisco.com>
Acked-by: NLeon Romanovsky <leonro@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Link: https://lore.kernel.org/r/20221026135153.154807-2-saeed@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit 0d88359092ddc5c2ef51f11a8b8a0b07467f9f3c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

[ Upstream commit bac0f937 ]

As explained by Julian, fib_nh_scope is related to fib_nh_gw4, but
fib_info_update_nhc_saddr() needs the scope of the route, which is
the scope "before" fib_nh_scope, ie fib_nh_scope - 1.

This patch fixes the problem described in commit 747c1430 ("ip: fix
dflt addr selection for connected nexthop").

Fixes: 597cfe4f ("nexthop: Add support for IPv4 nexthops")
Link: https://lore.kernel.org/netdev/6c8a44ba-c2d5-cdf-c5c7-5baf97cba38@ssi.bg/Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Reviewed-by: NJulian Anastasov <ja@ssi.bg>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit 3519b5ddac2109892c93a6ada7a3ec82e40d2273
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

[ Upstream commit 0e7ce23a ]

If of_device_register() returns error, the of node and the
name allocated in dev_set_name() is leaked, call put_device()
to give up the reference that was set in device_initialize(),
so that of node is put in logical_port_release() and the name
is freed in kobject_cleanup().

Fixes: 1acf2318 ("ehea: dynamic add / remove port")
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221025130011.1071357-1-yangyingliang@huawei.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit 79631daa5a5166c6aa4e25f447e8c08ee030637a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

[ Upstream commit fd954cc1 ]

As noted by Paolo Abeni, pr_warn doesn't generate any splat and can still
preserve the warning to the user that feature downgrade occurred.  We
likely cannot introduce other kinds of checks / enforcement here because
syzbot can generate different genl versions to the datapath.

Reported-by: syzbot+31cde0bef4bbf8ba2d86@syzkaller.appspotmail.com
Fixes: 44da5ae5 ("openvswitch: Drop user features if old user space attempted to create datapath")
Cc: Thomas Graf <tgraf@suug.ch>
Signed-off-by: NAaron Conole <aconole@redhat.com>
Acked-by: NIlya Maximets <i.maximets@ovn.org>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit 00d6f33f6782e72c8753f30dea126317d6f97c8e
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

[ Upstream commit f1fae475 ]

i2sbus_add_dev() is supposed to return the number of probed devices,
i.e. either 1 or 0.  However, i2sbus_add_dev() has one error handling
that returns -ENODEV; this will screw up the accumulation number
counted in the caller, i2sbus_probe().

Fix the return value to 0 and add the comment for better understanding
for readers.

Fixes: f3d9478b ("[ALSA] snd-aoa: add snd-aoa")
Link: https://lore.kernel.org/r/20221027065233.13292-1-tiwai@suse.deSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>

stable inclusion
from stable-v5.10.153
commit ce6fd1c382a38b75557db85a2fe99d285540a03d
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I64YCA

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

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

[ Upstream commit 4a4c8482 ]

dev_set_name() in soundbus_add_one() allocates memory for name, it need be
freed when of_device_register() fails, call soundbus_dev_put() to give up
the reference that hold in device_initialize(), so that it can be freed in
kobject_cleanup() when the refcount hit to 0. And other resources are also
freed in i2sbus_release_dev(), so it can return 0 directly.

Fixes: f3d9478b ("[ALSA] snd-aoa: add snd-aoa")
Signed-off-by: NYang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221027013438.991920-1-yangyingliang@huawei.comSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLipeng Sang <sanglipeng1@jd.com>