Merge Pull Request from: @zhengzengkai 
 
```
[Description]​
The ROH module driver consists of the ROH Core and ROH DRV
modules, which work with hardware to implement communication
between nodes through HCCS packets.
ROH Core is a protocol stack of the ROH architecture. It provides
related services for upper layers by invoking operation interfaces
provided by the ROH DRV.
The ROH DRV implements the lower layer functions of the ROH
featureand provides a series of interfaces for operating hardware
for the ROH Core. 

This patch adds ROH device driver support, including:
1. ROH Core initialization
2. Provide roh device registration framework.
3. etc

[Testing]
kernel options:
CONFIG_ROH=m

Test passed with below step:
1. load the roh_core.ko
# insmod roh_core.ko
2. There is no error when roh_core.ko is loaded,
confirm that ko is loaded normally:
# lsmod | grep roh_core
roh_core 24576 0 - Live 0xffff800008f07000
3. View the sysfs file and confirm that the roh
directory has been generated:
# ls /sys/class/ | grep roh
roh
4.Uninstall roh_core.ko without any errors
```
 
 
Link:https://gitee.com/openeuler/kernel/pulls/191 
Reviewed-by: Ling Mingqiang <lingmingqiang@huawei.com> 
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com> 

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

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

Add ROH device driver support, include:
1. roh core initialization
2. provide a registration framework for roh device.
3. etc.
Signed-off-by: NKe Chen <chenke54@huawei.com>
Reviewed-by: NGang Zhang <gang.zhang@huawei.com>
Reviewed-by: NYefeng Yan <yanyefeng@huawei.com>
Reviewed-by: NJingchao Dai <daijingchao1@huawei.com>

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

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

Log return value of clear_hem() to help diagnose.
Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X0C3

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

The return value of set_hem has been fixed to ENODEV, which will
lead a diagnostic information missing.

Fixes: 9a443537 ("IB/hns: Add driver files for hns RoCE driver")
Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.15-rc1
commit 4ad81814
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X0C3
CVE: NA

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

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

Due to the discrete nature of the HIP08 timer unit, a requester might
finish the timeout period sooner, in elapsed real time, than its responder
does, even when both sides share the identical RNR timeout length included
in the RNR Nak packet and the responder indeed starts the timing prior to
the requester. Furthermore, if a 'providential' resend packet arrived
before the responder's timeout period expired, the responder is certainly
entitled to drop the packet silently in the light of IB protocol.

To address this problem, our team made good use of certain hardware facts:

1) The timing resolution regards the transmission arrangements is 1
   microsecond, e.g. if cq_period field is set to 3, it would be
   interpreted as 3 microsecond by hardware

2) A QPC field shall inform the hardware how many timing unit (ticks)
   constitutes a full microsecond, which, by default, is 1000

3) It takes 14ns for the processor to handle a packet in the buffer, so
   the RNR timeout length of 10ns would ensure our processing mechanism is
   disabled during the entire timeout period and the packet won't be
   dropped silently

To achieve (3), we permanently set the QPC field mentioned in (2) to zero
which nominally indicates every time tick is equivalent to a microsecond
in wall-clock time; now, a RNR timeout period at face value of 10 would
only last 10 ticks, which is 10ns in wall-clock time.

It's worth noting that we adapt the driver by magnifying certain
configuration parameters(cq_period, eq_period and ack_timeout)by 1000
given the user assumes the configuring timing unit to be microseconds.

Also, this particular improvisation is only deployed on HIP08 since other
hardware has already solved this issue.

Fixes: cfc85f3e ("RDMA/hns: Add profile support for hip08 driver")
Link: https://lore.kernel.org/r/20211209140655.49493-1-liangwenpeng@huawei.comSigned-off-by: NYangyang Li <liyangyang20@huawei.com>
Signed-off-by: NWenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.14-rc1
commit 7b0006db
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X0C3
CVE: NA

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

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

The base address table is allocated by dma allocator, and the size is
always aligned to PAGE_SIZE. If a fixed size is used to allocate the
table, the number of base address entries stored in the table will be
smaller than that can actually stored.

Link: https://lore.kernel.org/r/1621589395-2435-2-git-send-email-liweihang@huawei.comSigned-off-by: NXi Wang <wangxi11@huawei.com>
Signed-off-by: NWeihang Li <liweihang@huawei.com>
Signed-off-by: NJason Gunthorpe <jgg@nvidia.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X0C3

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

This reverts commit f9d4c848.

This patch is synchronized from the linux mainline, but some important
code is lost during synchronization. This results in a large code
difference between openEuler and the linux mainline.
It is a better option to revert the bad patch and resync a full patch
from the linux mainline. The resynchronized patch is the second patch
in this patchlist.
Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

The kernel space does not support the rq inline feature anymore,
so remove the code associated with rq inline.
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Enable the CQEIE field and configure the CQEIS field of QPC.
And add compatibility handling.
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

The rq inline makes some changes as follows, Firstly, it is only
used in user space. Secondly, it should notify hardware in QP RTR
status. Thirdly, Add compatibility processing between different
user space and kernel space. Change the HNS_ROCE_CAP_FLAG_RQ_INLINE
to a new bit to prevent old kernel spaces / spaced from enabling
rq inline.
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

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

Currently, the driver only uses max_send_sge to initialize sge num
when creating_qp. So, in the sq inline scenario, the driver may not
has enough sge to send data. For example, if max_send_sge is 16 and
max_inline_data is 1024, the driver needs 1024/16=64 sge to send data.
Therefore, the calculation method of sge num is modified to take the
maximum value of max_send_sge and max_inline_data/16 to solve this
problem.

Fixes:05201e01("RDMA/hns: Refactor process of setting extended sge")
Fixes:30b70788("RDMA/hns: Support inline data in extented sge space for RC")
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

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

This reverts commit 34542349.

Fixes: 34542349 ("RDMA/hns: Fix the problem of sge nums")
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

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

This reverts commit d0b40fc5.

Fixes: d0b40fc5 ("RDMA/hns: Remove enable rq inline in kernel and add compatibility handling")
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I5USIG

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

This reverts commit 5a18385d.

Fixes: 5a18385d ("RDMA/hns: Support cqe inline in user space")
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYueHaibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5XJ01

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

Add default algorithm processing.

Fixes: f91696f2 ("RDMA/hns: Support congestion control type selection according to the FW")
Signed-off-by: Nzhengfeng luo <luozhengfeng@h-partners.com>
Reviewed-by: NYangyang Li <liyangyang20@huawei.com>
Reviewed-by: NHaoyue Xu <xuhaoyue1@hisilicon.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 5e91e57e
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5WGEF
CVE: NA

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

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

Add support for using 'perf report --dump-raw-trace' to parse PTT packet.

Example usage:

Output will contain raw PTT data and its textual representation, such
as (8DW format):

0 0 0x5810 [0x30]: PERF_RECORD_AUXTRACE size: 0x400000  offset: 0
ref: 0xa5d50c725  idx: 0  tid: -1  cpu: 0
.
. ... HISI PTT data: size 4194304 bytes
.  00000000: 00 00 00 00                                 Prefix
.  00000004: 08 20 00 60                                 Header DW0
.  00000008: ff 02 00 01                                 Header DW1
.  0000000c: 20 08 00 00                                 Header DW2
.  00000010: 10 e7 44 ab                                 Header DW3
.  00000014: 2a a8 1e 01                                 Time
.  00000020: 00 00 00 00                                 Prefix
.  00000024: 01 00 00 60                                 Header DW0
.  00000028: 0f 1e 00 01                                 Header DW1
.  0000002c: 04 00 00 00                                 Header DW2
.  00000030: 40 00 81 02                                 Header DW3
.  00000034: ee 02 00 00                                 Time
....

This patch only add basic parsing support according to the definition of
the PTT packet described in Documentation/trace/hisi-ptt.rst. And the
fields of each packet can be further decoded following the PCIe Spec's
definition of TLP packet.
Signed-off-by: NQi Liu <liuqi115@huawei.com>
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@arm.com>
Cc: John Garry <john.garry@huawei.com>
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
Cc: Leo Yan <leo.yan@linaro.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Qi Liu <liuqi6124@gmail.com>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: Shaokun Zhang <zhangshaokun@hisilicon.com>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Zeng Prime <prime.zeng@huawei.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-pci@vger.kernel.org
Cc: linuxarm@huawei.com
Link: https://lore.kernel.org/r/20220927081400.14364-4-yangyicong@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NWangming Shao <shaowangming@h-partners.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Reviewed-by: NJay Fang <f.fangjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 057381a7
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5WGEF
CVE: NA

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

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

HiSilicon PCIe tune and trace device (PTT) could dynamically tune the
PCIe link's events, and trace the TLP headers).

This patch add support for PTT device in perf tool, so users could use
'perf record' to get TLP headers trace data.
Reviewed-by: NLeo Yan <leo.yan@linaro.org>
Signed-off-by: NQi Liu <liuqi115@huawei.com>
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Acked-by: NJohn Garry <john.garry@huawei.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@arm.com>
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Qi Liu <liuqi6124@gmail.com>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: Shaokun Zhang <zhangshaokun@hisilicon.com>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Zeng Prime <prime.zeng@huawei.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-pci@vger.kernel.org
Cc: linuxarm@huawei.com
Link: https://lore.kernel.org/r/20220927081400.14364-3-yangyicong@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NWangming Shao <shaowangming@h-partners.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Reviewed-by: NJay Fang <f.fangjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 45a3975f
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I5WGEF
CVE: NA

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

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

Add find_pmu_for_event() and use to simplify logic in
auxtrace_record_init(). find_pmu_for_event() will be reused in
subsequent patches.
Reviewed-by: NJohn Garry <john.garry@huawei.com>
Reviewed-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: NLeo Yan <leo.yan@linaro.org>
Signed-off-by: NQi Liu <liuqi115@huawei.com>
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Clark <james.clark@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Mike Leach <mike.leach@linaro.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Qi Liu <liuqi6124@gmail.com>
Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: Shaokun Zhang <zhangshaokun@hisilicon.com>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Zeng Prime <prime.zeng@huawei.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-pci@vger.kernel.org
Cc: linuxarm@huawei.com
Link: https://lore.kernel.org/r/20220927081400.14364-2-yangyicong@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NWangming Shao <shaowangming@h-partners.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Reviewed-by: NJay Fang <f.fangjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.18-rc1
commit cf5a501d
category: bugfix
bugzilla: 187198, https://gitee.com/openeuler/kernel/issues/I5Q9PS
CVE: NA

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

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

When a contiguous HugeTLB page is mapped, set_pte_at() will be called
CONT_PTES/CONT_PMDS times.  Therefore, __sync_icache_dcache() will
flush cache multiple times if the page is executable (to ensure
the I-D cache coherency).  However, the first flushing cache already
covers subsequent cache flush operations.  So only flusing cache
for the head page if it is a HugeTLB page to avoid redundant cache
flushing.  In the next patch, it is also depends on this change
since the tail vmemmap pages of HugeTLB is mapped with read-only
meanning only head page struct can be modified.
Signed-off-by: NMuchun Song <songmuchun@bytedance.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20220302084624.33340-1-songmuchun@bytedance.comSigned-off-by: NWill Deacon <will@kernel.org>
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

The readahead feature of the openEuler-22.03-LTS ebpf enhancement
involves interface changes and needs to be compatible with the ebpf
tool of openEuler-1.0-LTS. This patch changes the _ctl_mode to _mode of
fs_file_read_ctx structure.
Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5GNIE

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

Since commit 4615fbc3 ("genirq/irqdomain: Don't try to free an
interrupt that has no mapping"), we have found failures when
re-inserting some specific drivers:

[root@localhost ~]# rmmod hisi_sas_v3_hw
[root@localhost ~]# modprobe hisi_sas_v3_hw
[ 1295.622525] hisi_sas_v3_hw: probe of 0000:30:04.0 failed with error -2

A relevant discussion can be found at:
https://lore.kernel.org/lkml/3d3d0155e66429968cb4f6b4feeae4b3@kernel.org/

This is because IRQs from a low-level domain are not freed together,
leaving some leaked. Thus, the next driver insertion fails to allocate
the same number of IRQs.

Free a contiguous group of IRQs in one go to fix this issue.

Fixes: 4615fbc3 ("genirq/irqdomain: Don't try to free an interrupt
that has no mapping")
Signed-off-by: NJie Zhan <zhanjie9@hisilicon.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

File '/proc/livepatch/state' should be removed before removing
'/proc/livepatch', otherwise following log will appear:
  remove_proc_entry: removing non-empty directory '/proc/livepatch',
  leaking at least 'state'

Fixes: c33e4283 ("livepatch/core: Allow implementation without ftrace")
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.0-rc1
commit 18178e03
category: bugfix
bugzilla: 187764, https://gitee.com/openeuler/kernel/issues/I5XJD7
CVE: N/A

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.0&id=18178e03b124b0c6be17abbbca914157642f5d7a

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

Driver should call pci_disable_device() if it returns from
cafe_nand_probe() with error.

Meanwhile, the driver calls pci_enable_device() in
cafe_nand_probe(), but never calls pci_disable_device()
during removal.
Signed-off-by: NPeng Wu <wupeng58@huawei.com>
Signed-off-by: NMiquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20220520084425.116686-1-wupeng58@huawei.comSigned-off-by: NGONG, Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: Nguozihua <guozihua@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.148
commit 21ee3cffed8fbabb669435facfd576ba18ac8652
category: bugfix
bugzilla:187877,https://gitee.com/src-openeuler/kernel/issues/I5X3MX
CVE: CVE-2022-3649

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

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

commit d325dc6e upstream.

If the beginning of the inode bitmap area is corrupted on disk, an inode
with the same inode number as the root inode can be allocated and fail
soon after.  In this case, the subsequent call to nilfs_clear_inode() on
that bogus root inode will wrongly decrement the reference counter of
struct nilfs_root, and this will erroneously free struct nilfs_root,
causing kernel oopses.

This fixes the problem by changing nilfs_new_inode() to skip reserved
inode numbers while repairing the inode bitmap.

Link: https://lkml.kernel.org/r/20221003150519.39789-1-konishi.ryusuke@gmail.comSigned-off-by: NRyusuke Konishi <konishi.ryusuke@gmail.com>
Reported-by: syzbot+b8c672b0e22615c80fe0@syzkaller.appspotmail.com
Reported-by: NKhalid Masum <khalid.masum.92@gmail.com>
Tested-by: NRyusuke Konishi <konishi.ryusuke@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NBaokun Li <libaokun1@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>

stable inclusion
from stable-v5.10.138
commit a220ff343396bae8d3b6abee72ab51f1f34b3027
category: bugfix
bugzilla: 187869, https://gitee.com/src-openeuler/kernel/issues/I5X3MU
CVE: CVE-2022-3633

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

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

commit 8c21c54a upstream.

We need to drop skb references taken in j1939_session_skb_queue() when
destroying a session in j1939_session_destroy(). Otherwise those skbs
would be lost.

Link to Syzkaller info and repro: https://forge.ispras.ru/issues/11743.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

V1: https://lore.kernel.org/all/20220708175949.539064-1-pchelkin@ispras.ru

Fixes: 9d71dd0c ("can: add support of SAE J1939 protocol")
Suggested-by: NOleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: NFedor Pchelkin <pchelkin@ispras.ru>
Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: NOleksij Rempel <o.rempel@pengutronix.de>
Link: https://lore.kernel.org/all/20220805150216.66313-1-pchelkin@ispras.ruSigned-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NDong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 93e2be34
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5WFKR
CVE: CVE-2022-3594

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93e2be344a7db169b7119de21ac1bf253b8c6907

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

My system shows almost 10 million of these messages over a 24-hour
period which pollutes my logs.
Signed-off-by: NAndrew Gaul <gaul@google.com>
Link: https://lore.kernel.org/r/20221002034128.2026653-1-gaul@google.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.0-rc1
commit 02e1a114
category: bugfix
bugzilla: 187867, https://gitee.com/src-openeuler/kernel/issues/I5W7B5
CVE: CVE-2022-3545

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next.git/commit/?id=02e1a114fdb71e59ee6770294166c30d437bf86a

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

area_cache_get() is used to distribute cache->area and set cache->id,
 and if cache->id is not 0 and cache->area->kref refcount is 0, it will
 release the cache->area by nfp_cpp_area_release(). area_cache_get()
 set cache->id before cpp->op->area_init() and nfp_cpp_area_acquire().

But if area_init() or nfp_cpp_area_acquire() fails, the cache->id is
 is already set but the refcount is not increased as expected. At this
 time, calling the nfp_cpp_area_release() will cause use-after-free.

To avoid the use-after-free, set cache->id after area_init() and
 nfp_cpp_area_acquire() complete successfully.

Note: This vulnerability is triggerable by providing emulated device
 equipped with specified configuration.

 BUG: KASAN: use-after-free in nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760)
  Write of size 4 at addr ffff888005b7f4a0 by task swapper/0/1

 Call Trace:
  <TASK>
 nfp6000_area_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:760)
 area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:884)

 Allocated by task 1:
 nfp_cpp_area_alloc_with_name (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:303)
 nfp_cpp_area_cache_add (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:802)
 nfp6000_init (drivers/net/ethernet/netronome/nfp/nfpcore/nfp6000_pcie.c:1230)
 nfp_cpp_from_operations (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:1215)
 nfp_pci_probe (drivers/net/ethernet/netronome/nfp/nfp_main.c:744)

 Freed by task 1:
 kfree (mm/slub.c:4562)
 area_cache_get.constprop.8 (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:873)
 nfp_cpp_read (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:924 drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cppcore.c:973)
 nfp_cpp_readl (drivers/net/ethernet/netronome/nfp/nfpcore/nfp_cpplib.c:48)
Signed-off-by: NJialiang Wang <wangjialiang0806@163.com>
Reviewed-by: NYinjun Zhang <yinjun.zhang@corigine.com>
Acked-by: NSimon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20220810073057.4032-1-wangjialiang0806@163.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NYuyao Lin <linyuyao1@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

maillist inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7XW
CVE: CVE-2022-3564

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=89f9f3cb86b1c63badaf392a83dd661d56cc50b1

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

Fix the race condition between the following two flows that run in
parallel:

1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->
   __sock_queue_rcv_skb.

2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.

An SKB can be queued by the first flow and immediately dequeued and
freed by the second flow, therefore the callers of l2cap_reassemble_sdu
can't use the SKB after that function returns. However, some places
continue accessing struct l2cap_ctrl that resides in the SKB's CB for a
short time after l2cap_reassemble_sdu returns, leading to a
use-after-free condition (the stack trace is below, line numbers for
kernel 5.19.8).

Fix it by keeping a local copy of struct l2cap_ctrl.

BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169

Workqueue: hci0 hci_rx_work [bluetooth]
Call Trace:
 <TASK>
 dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))
 print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)
 ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
 kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)
 ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
 l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth
 l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth
 ret_from_fork (arch/x86/entry/entry_64.S:306)
 </TASK>

Allocated by task 43169:
 kasan_save_stack (mm/kasan/common.c:39)
 __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)
 kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)
 __alloc_skb (net/core/skbuff.c:414)
 l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth
 l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth
 hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth
 process_one_work (kernel/workqueue.c:2289)
 worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)
 kthread (kernel/kthread.c:376)
 ret_from_fork (arch/x86/entry/entry_64.S:306)

Freed by task 27920:
 kasan_save_stack (mm/kasan/common.c:39)
 kasan_set_track (mm/kasan/common.c:45)
 kasan_set_free_info (mm/kasan/generic.c:372)
 ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)
 slab_free_freelist_hook (mm/slub.c:1780)
 kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)
 skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)
 bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth
 l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth
 sock_read_iter (net/socket.c:1087)
 new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)
 vfs_read (fs/read_write.c:482)
 ksys_read (fs/read_write.c:620)
 do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
 entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)

Link: https://lore.kernel.org/linux-bluetooth/CAKErNvoqga1WcmoR3-0875esY6TVWFQDandbVZncSiuGPBQXLA@mail.gmail.com/T/#u
Fixes: d2a7ac5d ("Bluetooth: Add the ERTM receive state machine")
Fixes: 4b51dae9 ("Bluetooth: Add streaming mode receive and incoming packet classifier")
Signed-off-by: NMaxim Mikityanskiy <maxtram95@gmail.com>
Signed-off-by: NLuiz Augusto von Dentz <luiz.von.dentz@intel.com>

conflicts：
	net/bluetooth/l2cap_core.c
Signed-off-by: NXia Longlong <xialonglong1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 945a9a8e
category: bugfix
bugzilla: 187857, https://gitee.com/src-openeuler/kernel/issues/I5X9DT
CVE: CVE-2022-3577

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

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

The error handling code in pvr2_hdw_create forgets to unregister the
v4l2 device. When pvr2_hdw_create returns back to pvr2_context_create,
it calls pvr2_context_destroy to destroy context, but mp->hdw is NULL,
which leads to that pvr2_hdw_destroy directly returns.

Fix this by adding v4l2_device_unregister to decrease the refcount of
usb interface.

Reported-by: syzbot+77b432d57c4791183ed4@syzkaller.appspotmail.com
Signed-off-by: NDongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 9d64d240
category: bugfix
bugzilla: 187857, https://gitee.com/src-openeuler/kernel/issues/I5X9DT
CVE: CVE-2022-3577

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

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

So far we relied on
.put_super = binderfs_put_super()
to destroy info we stashed in sb->s_fs_info. This gave us the required ordering
between ->evict_inode() and sb->s_fs_info destruction.

But the current implementation of binderfs_fill_super() has a memory leak in
the rare circumstance that d_make_root() fails because ->put_super() is only
called when sb->s_root is initialized. Fix this by removing ->put_super() and
simply do all that work in binderfs_kill_super().
Reported-by: NDongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NChristian Brauner (Microsoft) <brauner@kernel.org>
Link: https://lore.kernel.org/r/20220823095339.853371-1-brauner@kernel.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLi Huafei <lihuafei1@huawei.com>
Reviewed-by: NKuohai Xu <xukuohai@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

maillist inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7AT
CVE: CVE-2022-3534

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=93c660ca40b5d2f7c1b1626e955a8e9fa30e0749

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

ASAN reports an use-after-free in btf_dump_name_dups:

ERROR: AddressSanitizer: heap-use-after-free on address 0xffff927006db at pc 0xaaaab5dfb618 bp 0xffffdd89b890 sp 0xffffdd89b928
READ of size 2 at 0xffff927006db thread T0
    #0 0xaaaab5dfb614 in __interceptor_strcmp.part.0 (test_progs+0x21b614)
    #1 0xaaaab635f144 in str_equal_fn tools/lib/bpf/btf_dump.c:127
    #2 0xaaaab635e3e0 in hashmap_find_entry tools/lib/bpf/hashmap.c:143
    #3 0xaaaab635e72c in hashmap__find tools/lib/bpf/hashmap.c:212
    #4 0xaaaab6362258 in btf_dump_name_dups tools/lib/bpf/btf_dump.c:1525
    #5 0xaaaab636240c in btf_dump_resolve_name tools/lib/bpf/btf_dump.c:1552
    #6 0xaaaab6362598 in btf_dump_type_name tools/lib/bpf/btf_dump.c:1567
    #7 0xaaaab6360b48 in btf_dump_emit_struct_def tools/lib/bpf/btf_dump.c:912
    #8 0xaaaab6360630 in btf_dump_emit_type tools/lib/bpf/btf_dump.c:798
    #9 0xaaaab635f720 in btf_dump__dump_type tools/lib/bpf/btf_dump.c:282
    #10 0xaaaab608523c in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:236
    #11 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875
    #12 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062
    #13 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697
    #14 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308
    #15 0xaaaab5d65990  (test_progs+0x185990)

0xffff927006db is located 11 bytes inside of 16-byte region [0xffff927006d0,0xffff927006e0)
freed by thread T0 here:
    #0 0xaaaab5e2c7c4 in realloc (test_progs+0x24c7c4)
    #1 0xaaaab634f4a0 in libbpf_reallocarray tools/lib/bpf/libbpf_internal.h:191
    #2 0xaaaab634f840 in libbpf_add_mem tools/lib/bpf/btf.c:163
    #3 0xaaaab636643c in strset_add_str_mem tools/lib/bpf/strset.c:106
    #4 0xaaaab6366560 in strset__add_str tools/lib/bpf/strset.c:157
    #5 0xaaaab6352d70 in btf__add_str tools/lib/bpf/btf.c:1519
    #6 0xaaaab6353e10 in btf__add_field tools/lib/bpf/btf.c:2032
    #7 0xaaaab6084fcc in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:232
    #8 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875
    #9 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062
    #10 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697
    #11 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308
    #12 0xaaaab5d65990  (test_progs+0x185990)

previously allocated by thread T0 here:
    #0 0xaaaab5e2c7c4 in realloc (test_progs+0x24c7c4)
    #1 0xaaaab634f4a0 in libbpf_reallocarray tools/lib/bpf/libbpf_internal.h:191
    #2 0xaaaab634f840 in libbpf_add_mem tools/lib/bpf/btf.c:163
    #3 0xaaaab636643c in strset_add_str_mem tools/lib/bpf/strset.c:106
    #4 0xaaaab6366560 in strset__add_str tools/lib/bpf/strset.c:157
    #5 0xaaaab6352d70 in btf__add_str tools/lib/bpf/btf.c:1519
    #6 0xaaaab6353ff0 in btf_add_enum_common tools/lib/bpf/btf.c:2070
    #7 0xaaaab6354080 in btf__add_enum tools/lib/bpf/btf.c:2102
    #8 0xaaaab6082f50 in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:162
    #9 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875
    #10 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062
    #11 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697
    #12 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308
    #13 0xaaaab5d65990  (test_progs+0x185990)

The reason is that the key stored in hash table name_map is a string
address, and the string memory is allocated by realloc() function, when
the memory is resized by realloc() later, the old memory may be freed,
so the address stored in name_map references to a freed memory, causing
use-after-free.

Fix it by storing duplicated string address in name_map.

Fixes: 919d2b1d ("libbpf: Allow modification of BTF and add btf__add_str API")
Signed-off-by: NXu Kuohai <xukuohai@huawei.com>
Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
Acked-by: NMartin KaFai Lau <martin.lau@kernel.org>
Link: https://lore.kernel.org/bpf/20221011120108.782373-2-xukuohai@huaweicloud.comReviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.143
commit 2ead78fbe6b523e6232ad286e3c13d2a410de22a
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5WF14
CVE: CVE-2022-3586

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=2ead78fbe6b523e6232ad286e3c13d2a410de22a

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

[ Upstream commit 2f09707d ]

Cong Wang noticed that the previous fix for sch_sfb accessing the queued
skb after enqueueing it to a child qdisc was incomplete: the SFB enqueue
function was also calling qdisc_qstats_backlog_inc() after enqueue, which
reads the pkt len from the skb cb field. Fix this by also storing the skb
len, and using the stored value to increment the backlog after enqueueing.

Fixes: 9efd2329 ("sch_sfb: Don't assume the skb is still around after enqueueing to child")
Signed-off-by: NToke Høiland-Jørgensen <toke@toke.dk>
Acked-by: NCong Wang <cong.wang@bytedance.com>
Link: https://lore.kernel.org/r/20220905192137.965549-1-toke@toke.dkSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: Nchenweilong <chenweilong@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.143
commit 2ee85ac1b29dbd2ebd2d8e5ac1dd5793235d516b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5WF14
CVE: CVE-2022-3586

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=2ee85ac1b29dbd2ebd2d8e5ac1dd5793235d516b

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

[ Upstream commit 9efd2329 ]

The sch_sfb enqueue() routine assumes the skb is still alive after it has
been enqueued into a child qdisc, using the data in the skb cb field in the
increment_qlen() routine after enqueue. However, the skb may in fact have
been freed, causing a use-after-free in this case. In particular, this
happens if sch_cake is used as a child of sfb, and the GSO splitting mode
of CAKE is enabled (in which case the skb will be split into segments and
the original skb freed).

Fix this by copying the sfb cb data to the stack before enqueueing the skb,
and using this stack copy in increment_qlen() instead of the skb pointer
itself.

Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-18231
Fixes: e13e02a3 ("net_sched: SFB flow scheduler")
Signed-off-by: NToke Høiland-Jørgensen <toke@toke.dk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: Nchenweilong <chenweilong@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.134
commit bb1990a3005e3655e84f9a57b3f30ce96d597dee
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X57Q
CVE: CVE-2022-1882

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

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

commit 44e29e64 upstream.

Sedat Dilek noticed that I had an extraneous semicolon at the end of a
line in the previous patch.

It's harmless, but unintentional, and while compilers just treat it as
an extra empty statement, for all I know some other tooling might warn
about it. So clean it up before other people notice too ;)

Fixes: 353f7988 ("watchqueue: make sure to serialize 'wqueue->defunct' properly")
Reported-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Reported-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.134
commit 0adf21eec59040b31af113e626efd85eb153c728
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5X57Q
CVE: CVE-2022-1882

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

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

commit 353f7988 upstream.

When the pipe is closed, we mark the associated watchqueue defunct by
calling watch_queue_clear().  However, while that is protected by the
watchqueue lock, new watchqueue entries aren't actually added under that
lock at all: they use the pipe->rd_wait.lock instead, and looking up
that pipe happens without any locking.

The watchqueue code uses the RCU read-side section to make sure that the
wqueue entry itself hasn't disappeared, but that does not protect the
pipe_info in any way.

So make sure to actually hold the wqueue lock when posting watch events,
properly serializing against the pipe being torn down.
Reported-by: NNoam Rathaus <noamr@ssd-disclosure.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NWang Hai <wanghai38@huawei.com>
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5WFKI
CVE: CVE-2022-2602

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

In order to fix CVE-2022-2602, member 'scm_io_uring' is imported into
sk_buff, fix broken kabi in sk_buff.
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 0091bfc8
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5WFKI
CVE: CVE-2022-2602

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?h=v6.1-rc1&id=0091bfc81741b8d3aeb3b7ab8636f911b2de6e80

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

Instead of putting io_uring's registered files in unix_gc() we want it
to be done by io_uring itself. The trick here is to consider io_uring
registered files for cycle detection but not actually putting them down.
Because io_uring can't register other ring instances, this will remove
all refs to the ring file triggering the ->release path and clean up
with io_ring_ctx_free().

Cc: stable@vger.kernel.org
Fixes: 6b06314c ("io_uring: add file set registration")
Reported-and-tested-by: NDavid Bouman <dbouman03@gmail.com>
Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com>
[axboe: add kerneldoc comment to skb, fold in skb leak fix]
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Conflicts:
	fs/io_uring.c
	include/linux/skbuff.h
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: Nzhongbaisong <zhongbaisong@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v6.1-rc1
commit 2568a7e0
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I5W7YH
CVE: CVE-2022-3565

Reference: https://nvd.nist.gov/vuln/detail/CVE-2022-3565
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2568a7e0832ee30b0a351016d03062ab4e0e0a3f

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

The l1oip_cleanup() traverses the l1oip_ilist and calls
release_card() to cleanup module and stack. However,
release_card() calls del_timer() to delete the timers
such as keep_tl and timeout_tl. If the timer handler is
running, the del_timer() will not stop it and result in
UAF bugs. One of the processes is shown below:

    (cleanup routine)          |        (timer handler)
release_card()                 | l1oip_timeout()
 ...                           |
 del_timer()                   | ...
 ...                           |
 kfree(hc) //FREE              |
                               | hc->timeout_on = 0 //USE

Fix by calling del_timer_sync() in release_card(), which
makes sure the timer handlers have finished before the
resources, such as l1oip and so on, have been deallocated.

What's more, the hc->workq and hc->socket_thread can kick
those timers right back in. We add a bool flag to show
if card is released. Then, check this flag in hc->workq
and hc->socket_thread.

Fixes: 3712b42d ("Add layer1 over IP support")
Signed-off-by: NDuoming Zhou <duoming@zju.edu.cn>
Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGUO Zihua <guozihua@huawei.com>
Reviewed-by: NGONG Ruiqi <gongruiqi1@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

This patch add 'enable_fm' as 5th module init parameters to control
fastmap  enable or not. When the value is 0, fastmap will not create
and existed fastmap will destroyed for the given ubi device. Default
value is 0.

To enable or disable fastmap during module loading, fm_autoconvert
must be set to non-zero.

+-----------------+---------------+---------------------------+
|        \        |  enable_fm=0  |  enable_fm=1              |
+-----------------+---------------+---------------------------+
|fm_autoconvert=Y |  disable fm   |  enable fm                |
+---------------------------------+---------------------------+
|fm_autoconvert=N |  disable fm   | Enable fastmap. If fastmap|
|                 |               | exists in the old image,  |
+------------------------------------------------------------ +

Example:
  # - Attach mtd1 to ubi1, disable fastmap, mtd2 to ubi2, enable
      fastmap.
  # modprobe ubi mtd=1,0,0,1,0 mtd=2,0,0,2,1 fm_autoconvert=1

  # - If 5th parameter is not specified, the value is 0, fastmap is
      disable
  # modprobe ubi mtd=1 fm_autoconvert=1
Signed-off-by: NZhaoLong Wang <wangzhaolong1@huawei.com>
Reviewed-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 669d2044
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I5WQRM
CVE: NA

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

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

[1] suggests that fastmap is suitable for large flash devices. Module
parameter 'fm_autoconvert' is a coarse grained switch to enable all
ubi devices to generate fastmap, which may turn on fastmap even for
small flash devices.

This patch imports a new field 'disable_fm' in struct 'ubi_attach_req'
to support following situations by ioctl 'UBI_IOCATT'.
 [old functions]
 A. Disable 'fm_autoconvert': Disbable fastmap for all ubi devices
 B. Enable 'fm_autoconvert': Enable fastmap for all ubi devices
 [new function]
 C. Enable 'fm_autoconvert', set 'disable_fm' for given device: Don't
    create new fastmap and do full scan (existed fastmap will be
    destroyed) for the given ubi device.

A simple test case in [2].

[1] http://www.linux-mtd.infradead.org/doc/ubi.html#L_fastmap
[2] https://bugzilla.kernel.org/show_bug.cgi?id=216278Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: NRichard Weinberger <richard@nod.at>
Reviewed-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>