Merge Pull Request from: @ci-robot 
 
PR sync from: Zhengchao Shao <shaozhengchao@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/BRJBIYKRMZVLU22DE46JGRSJRG6C7E66/ 
 
https://gitee.com/openeuler/kernel/issues/I7V613 
 
Link:https://gitee.com/openeuler/kernel/pulls/1843 

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

Merge Pull Request from: @ci-robot 
 
PR sync from: Jinjiang Tu <tujinjiang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/EP3I3LIWZJK6QHJPE6SA4KNXJO2ACWCI/ 
Support batched/deferred tlb shootdown during page reclamation/migration
for arm64.

Changelog:
v6:
 - move kabi fix code into a separate patch.

v5:
 - adjust tab num for macro DEFINE_TLB_UBC

v4
 - define macro DEFINE_TLB_UBC

v3:
 - fix kabi breakage for task_struct->tlb_ubc

v2:
 - fix kabi breakage for mm_struct->tlb_flush_batched

Anshuman Khandual (1):
  mm/tlbbatch: introduce arch_tlbbatch_should_defer()

Barry Song (2):
  mm/tlbbatch: rename and extend some functions
  arm64: support batched/deferred tlb shootdown during page
    reclamation/migration

Jinjiang Tu (1):
  mm/tlbbatch: fix kabi change

Yicong Yang (1):
  mm/tlbbatch: introduce arch_flush_tlb_batched_pending()


-- 
2.25.1
 
https://gitee.com/openeuler/kernel/issues/I7U78A 
 
Link:https://gitee.com/openeuler/kernel/pulls/1852 

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

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

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

fix kabi change for mm_struct->tlb_flush_batched
and task_struct->tlb_ubc.
Signed-off-by: NJinjiang Tu <tujinjiang@huawei.com>

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

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

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

On x86, batched and deferred tlb shootdown has lead to 90% performance
increase on tlb shootdown.  on arm64, HW can do tlb shootdown without
software IPI.  But sync tlbi is still quite expensive.

Even running a simplest program which requires swapout can
prove this is true,
 #include <sys/types.h>
 #include <unistd.h>
 #include <sys/mman.h>
 #include <string.h>

 int main()
 {
 #define SIZE (1 * 1024 * 1024)
         volatile unsigned char *p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
                                          MAP_SHARED | MAP_ANONYMOUS, -1, 0);

         memset(p, 0x88, SIZE);

         for (int k = 0; k < 10000; k++) {
                 /* swap in */
                 for (int i = 0; i < SIZE; i += 4096) {
                         (void)p[i];
                 }

                 /* swap out */
                 madvise(p, SIZE, MADV_PAGEOUT);
         }
 }

Perf result on snapdragon 888 with 8 cores by using zRAM
as the swap block device.

 ~ # perf record taskset -c 4 ./a.out
 [ perf record: Woken up 10 times to write data ]
 [ perf record: Captured and wrote 2.297 MB perf.data (60084 samples) ]
 ~ # perf report
 # To display the perf.data header info, please use --header/--header-only options.
 # To display the perf.data header info, please use --header/--header-only options.
 #
 #
 # Total Lost Samples: 0
 #
 # Samples: 60K of event 'cycles'
 # Event count (approx.): 35706225414
 #
 # Overhead  Command  Shared Object      Symbol
 # ........  .......  .................  ......
 #
    21.07%  a.out    [kernel.kallsyms]  [k] _raw_spin_unlock_irq
     8.23%  a.out    [kernel.kallsyms]  [k] _raw_spin_unlock_irqrestore
     6.67%  a.out    [kernel.kallsyms]  [k] filemap_map_pages
     6.16%  a.out    [kernel.kallsyms]  [k] __zram_bvec_write
     5.36%  a.out    [kernel.kallsyms]  [k] ptep_clear_flush
     3.71%  a.out    [kernel.kallsyms]  [k] _raw_spin_lock
     3.49%  a.out    [kernel.kallsyms]  [k] memset64
     1.63%  a.out    [kernel.kallsyms]  [k] clear_page
     1.42%  a.out    [kernel.kallsyms]  [k] _raw_spin_unlock
     1.26%  a.out    [kernel.kallsyms]  [k] mod_zone_state.llvm.8525150236079521930
     1.23%  a.out    [kernel.kallsyms]  [k] xas_load
     1.15%  a.out    [kernel.kallsyms]  [k] zram_slot_lock

ptep_clear_flush() takes 5.36% CPU in the micro-benchmark swapping in/out
a page mapped by only one process.  If the page is mapped by multiple
processes, typically, like more than 100 on a phone, the overhead would be
much higher as we have to run tlb flush 100 times for one single page.
Plus, tlb flush overhead will increase with the number of CPU cores due to
the bad scalability of tlb shootdown in HW, so those ARM64 servers should
expect much higher overhead.

Further perf annonate shows 95% cpu time of ptep_clear_flush is actually
used by the final dsb() to wait for the completion of tlb flush.  This
provides us a very good chance to leverage the existing batched tlb in
kernel.  The minimum modification is that we only send async tlbi in the
first stage and we send dsb while we have to sync in the second stage.

With the above simplest micro benchmark, collapsed time to finish the
program decreases around 5%.

Typical collapsed time w/o patch:
 ~ # time taskset -c 4 ./a.out
 0.21user 14.34system 0:14.69elapsed
w/ patch:
 ~ # time taskset -c 4 ./a.out
 0.22user 13.45system 0:13.80elapsed

Also tested with benchmark in the commit on Kunpeng920 arm64 server
and observed an improvement around 12.5% with command
`time ./swap_bench`.
        w/o             w/
real    0m13.460s       0m11.771s
user    0m0.248s        0m0.279s
sys     0m12.039s       0m11.458s

Originally it's noticed a 16.99% overhead of ptep_clear_flush()
which has been eliminated by this patch:

[root@localhost yang]# perf record -- ./swap_bench && perf report
[...]
16.99%  swap_bench  [kernel.kallsyms]  [k] ptep_clear_flush

It is tested on 4,8,128 CPU platforms and shows to be beneficial on
large systems but may not have improvement on small systems like on
a 4 CPU platform.

Also this patch improve the performance of page migration. Using pmbench
and tries to migrate the pages of pmbench between node 0 and node 1 for
100 times for 1G memory, this patch decrease the time used around 20%
(prev 18.338318910 sec after 13.981866350 sec) and saved the time used
by ptep_clear_flush().

Link: https://lkml.kernel.org/r/20230717131004.12662-5-yangyicong@huawei.comTested-by: NYicong Yang <yangyicong@hisilicon.com>
Tested-by: NXin Hao <xhao@linux.alibaba.com>
Tested-by: NPunit Agrawal <punit.agrawal@bytedance.com>
Signed-off-by: NBarry Song <v-songbaohua@oppo.com>
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NXin Hao <xhao@linux.alibaba.com>
Reviewed-by: NAnshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Nadav Amit <namit@vmware.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Barry Song <baohua@kernel.org>
Cc: Darren Hart <darren@os.amperecomputing.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: lipeifeng <lipeifeng@oppo.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Steven Miao <realmz6@gmail.com>
Cc: Will Deacon <will@kernel.org>
Cc: Zeng Tao <prime.zeng@hisilicon.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJinjiang Tu <tujinjiang@huawei.com>

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

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4fd62a4892a3f576f424eb86e4eda510038934a9

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

Currently we'll flush the mm in flush_tlb_batched_pending() to avoid race
between reclaim unmaps pages by batched TLB flush and mprotect/munmap/etc.
Other architectures like arm64 may only need a synchronization
barrier(dsb) here rather than a full mm flush.  So add
arch_flush_tlb_batched_pending() to allow an arch-specific implementation
here.  This intends no functional changes on x86 since still a full mm
flush for x86.

Link: https://lkml.kernel.org/r/20230717131004.12662-4-yangyicong@huawei.comSigned-off-by: NYicong Yang <yangyicong@hisilicon.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Barry Song <baohua@kernel.org>
Cc: Barry Song <v-songbaohua@oppo.com>
Cc: Darren Hart <darren@os.amperecomputing.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: lipeifeng <lipeifeng@oppo.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Nadav Amit <namit@vmware.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Punit Agrawal <punit.agrawal@bytedance.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Steven Miao <realmz6@gmail.com>
Cc: Will Deacon <will@kernel.org>
Cc: Xin Hao <xhao@linux.alibaba.com>
Cc: Zeng Tao <prime.zeng@hisilicon.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

Conflicts:
	mm/rmap.c
	arch/x86/include/asm/tlbflush.h
Signed-off-by: NJinjiang Tu <tujinjiang@huawei.com>

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

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=653f88d06395a9b4b63e5835ca3ed74df802e786

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

This patch does some preparation works to extend batched TLB flush to
arm64. Including:
- Extend set_tlb_ubc_flush_pending() and arch_tlbbatch_add_mm()
  to accept an additional argument for address, architectures
  like arm64 may need this for tlbi.
- Rename arch_tlbbatch_add_mm() to arch_tlbbatch_add_pending()
  to match its current function since we don't need to handle
  mm on architectures like arm64 and add_mm is not proper,
  add_pending will make sense to both as on x86 we're pending the
  TLB flush operations while on arm64 we're pending the synchronize
  operations.

This intends no functional changes on x86.

Link: https://lkml.kernel.org/r/20230717131004.12662-3-yangyicong@huawei.comTested-by: NYicong Yang <yangyicong@hisilicon.com>
Tested-by: NXin Hao <xhao@linux.alibaba.com>
Tested-by: NPunit Agrawal <punit.agrawal@bytedance.com>
Signed-off-by: NBarry Song <v-songbaohua@oppo.com>
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NXin Hao <xhao@linux.alibaba.com>
Reviewed-by: NAnshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Nadav Amit <namit@vmware.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Barry Song <baohua@kernel.org>
Cc: Darren Hart <darren@os.amperecomputing.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: lipeifeng <lipeifeng@oppo.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Steven Miao <realmz6@gmail.com>
Cc: Will Deacon <will@kernel.org>
Cc: Zeng Tao <prime.zeng@hisilicon.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

Conflicts:
	mm/rmap.c
Signed-off-by: NJinjiang Tu <tujinjiang@huawei.com>

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

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=76b1e6fa09c2317547ed423a0870bc28299d6f55

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

Patch series "arm64: support batched/deferred tlb shootdown during page
reclamation/migration", v11.

Though ARM64 has the hardware to do tlb shootdown, the hardware
broadcasting is not free.  A simplest micro benchmark shows even on
snapdragon 888 with only 8 cores, the overhead for ptep_clear_flush is
huge even for paging out one page mapped by only one process: 5.36% a.out
[kernel.kallsyms] [k] ptep_clear_flush

While pages are mapped by multiple processes or HW has more CPUs, the cost
should become even higher due to the bad scalability of tlb shootdown.
The same benchmark can result in 16.99% CPU consumption on ARM64 server
with around 100 cores according to the test on patch 4/4.

This patchset leverages the existing BATCHED_UNMAP_TLB_FLUSH by
1. only send tlbi instructions in the first stage -
	arch_tlbbatch_add_mm()
2. wait for the completion of tlbi by dsb while doing tlbbatch
	sync in arch_tlbbatch_flush()

Testing on snapdragon shows the overhead of ptep_clear_flush is removed by
the patchset.  The micro benchmark becomes 5% faster even for one page
mapped by single process on snapdragon 888.

Since BATCHED_UNMAP_TLB_FLUSH is implemented only on x86, the patchset
does some renaming/extension for the current implementation first (Patch
1-3), then add the support on arm64 (Patch 4).

This patch (of 4):

The entire scheme of deferred TLB flush in reclaim path rests on the fact
that the cost to refill TLB entries is less than flushing out individual
entries by sending IPI to remote CPUs.  But architecture can have
different ways to evaluate that.  Hence apart from checking
TTU_BATCH_FLUSH in the TTU flags, rest of the decision should be
architecture specific.

[yangyicong@hisilicon.com: rebase and fix incorrect return value type]
Link: https://lkml.kernel.org/r/20230717131004.12662-1-yangyicong@huawei.com
Link: https://lkml.kernel.org/r/20230717131004.12662-2-yangyicong@huawei.comSigned-off-by: NAnshuman Khandual <khandual@linux.vnet.ibm.com>
[https://lore.kernel.org/linuxppc-dev/20171101101735.2318-2-khandual@linux.vnet.ibm.com/]
Signed-off-by: NYicong Yang <yangyicong@hisilicon.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NAnshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: NBarry Song <baohua@kernel.org>
Reviewed-by: NXin Hao <xhao@linux.alibaba.com>
Tested-by: NPunit Agrawal <punit.agrawal@bytedance.com>
Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Darren Hart <darren@os.amperecomputing.com>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: lipeifeng <lipeifeng@oppo.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Steven Miao <realmz6@gmail.com>
Cc: Will Deacon <will@kernel.org>
Cc: Zeng Tao <prime.zeng@hisilicon.com>
Cc: Barry Song <v-songbaohua@oppo.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Nadav Amit <namit@vmware.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NJinjiang Tu <tujinjiang@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Jinjiang Tu <tujinjiang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/UAQZCBQFUA5LYCLXXVHHJGAK2GNRA6LC/ 
Support multiple compression streams for zram.

Alexey Romanov (1):
  zram: add size class equals check into recompression

Andy Shevchenko (1):
  lib/cmdline: Export next_arg() for being used in modules

Ming Lei (1):
  zram: fix race between zram_reset_device() and disksize_store()

Sergey Senozhatsky (11):
  zram: preparation for multi-zcomp support
  zram: add recompression algorithm sysfs knob
  zram: factor out WB and non-WB zram read functions
  zram: introduce recompress sysfs knob
  zram: add recompress flag to read_block_state()
  zram: clarify writeback_store() comment
  zram: remove redundant checks from zram_recompress()
  zram: add algo parameter support to zram_recompress()
  documentation: add zram recompression documentation
  zram: add incompressible writeback
  zram: add incompressible flag to read_block_state()


-- 
2.25.1
 
https://gitee.com/openeuler/kernel/issues/I7TWVA 
 
Link:https://gitee.com/openeuler/kernel/pulls/1802 

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

Merge Pull Request from: @ci-robot 
 
PR sync from: Jinjiang Tu <tujinjiang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/SSNB2TJLFOGTWITPC5QTJ4DGB4WFMNJF/ 
 
https://gitee.com/openeuler/kernel/issues/I7TVRF 
 
Link:https://gitee.com/openeuler/kernel/pulls/1796 

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

Merge Pull Request from: @ci-robot 
 
PR sync from: Zhengchao Shao <shaozhengchao@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/GBQXYXZQPJDLMM27FLPPRC4UEJD35FWC/ 
 
https://gitee.com/openeuler/kernel/issues/I7UZT5 
 
Link:https://gitee.com/openeuler/kernel/pulls/1833 

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

Merge Pull Request from: @hitmoon 
 
issue: https://gitee.com/openeuler/kernel/issues/I7URR4


Conflicts(1):
556959327b19 mm: hugetlb: proc: check for hugetlb shared PMD in /proc/PID/smaps

Already merged(8):
9bd6074e1872 bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener
dd6991251a13 netrom: Fix use-after-free caused by accept on already connected socket
9758ffe1c07b scsi: iscsi_tcp: Fix UAF during login when accessing the shost ipaddress
55515d7d8743 vc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF
28d190882ba5 fbcon: Check font dimension limits
30187be29052 mm/swapfile: add cond_resched() in get_swap_pages()
c53f34ec3fbf rds: rds_rm_zerocopy_callback() use list_first_entry()
2b693fe3f760 cifs: Fix use-after-free in rdata->read_into_pages()

Total patches: 132 - 8  = 124 
 
Link:https://gitee.com/openeuler/kernel/pulls/1822 

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

Merge Pull Request from: @ci-robot 
 
PR sync from: Wang Yufen <wangyufen@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/VG6UAMVGXPOISDMNZNSTXWO36HWW4V6C/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7FUFX 
 
Link:https://gitee.com/openeuler/kernel/pulls/1835 

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

mainline inclusion
from mainline-v5.17-rc5
commit c832962a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7V613

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

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

Whenever bridge driver hits the max capacity of MDBs, it disables
the MC processing (by setting corresponding bridge option), but never
notifies switchdev about such change (the notifiers are called only upon
explicit setting of this option, through the registered netlink interface).

This could lead to situation when Software MDB processing gets disabled,
but this event never gets offloaded to the underlying Hardware.

Fix this by adding a notify message in such case.

Fixes: 147c1e9b ("switchdev: bridge: Offload multicast disabled")
Signed-off-by: NOleksandr Mazur <oleksandr.mazur@plvision.eu>
Acked-by: NNikolay Aleksandrov <nikolay@nvidia.com>
Link: https://lore.kernel.org/r/20220215165303.31908-1-oleksandr.mazur@plvision.euSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Conflicts:
	net/bridge/br_multicast.c
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Dong Chenchen <dongchenchen2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/BJRH2TZ7OXR5PPQTUVMHRC2VYBBK5WDI/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7SXVG 
 
Link:https://gitee.com/openeuler/kernel/pulls/1815 

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

Merge Pull Request from: @ci-robot 
 
PR sync from: Dong Chenchen <dongchenchen2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/MJIVQQT72SAC5DJW7GDQSSZ7RNT3AMPF/ 
The original patches fixing CVE-2023-1076 are incorrect.
The patches in this series are supposed to "re-fix" CVE-2023-1076
New CVE is CVE-2023-4194.

Laszlo Ersek (2):
  net: tun_chr_open(): set sk_uid from current_fsuid()
  net: tap_open(): set sk_uid from current_fsuid()


-- 
2.25.1
 
https://gitee.com/src-openeuler/kernel/issues/I7QXHX 
 
Link:https://gitee.com/openeuler/kernel/pulls/1784 

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

Merge Pull Request from: @ci-robot 
 
PR sync from: Yu Liao <liaoyu15@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/SEZNG2NDRWOJTRUITM5LU66N7IY4EQOM/ 
AMD Zen2 architecture Zenbleed remote execution vulnerability. The optimal
fix is through microcode but in the case the proper microcode revision has
not been applied, enable a fallback fix for openEuler.

Arnaldo Carvalho de Melo (1):
  [Backport] tools arch x86: Sync the msr-index.h copy with the kernel
    sources

Borislav Petkov (AMD) (2):
  [Backport] x86/cpu/amd: Move the errata checking functionality up
  [Backport] x86/cpu/amd: Add a Zenbleed fix

Cristian Ciocaltea (1):
  [Backport] x86/cpu/amd: Enable Zenbleed fix for AMD Custom APU 0405


-- 
2.25.1
 
https://gitee.com/src-openeuler/kernel/issues/I7NLYY 
 
Link:https://gitee.com/openeuler/kernel/pulls/1814 

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

stable inclusion
from stable-v5.10.190
commit d11b0df7ddf1831f3e170972f43186dad520bfcc
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7FUFX
CVE: CVE-2023-1206

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

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

[ Upstream commit d11b0df7ddf1831f3e170972f43186dad520bfcc ]

For both IPv4 and IPv6 incoming TCP connections are tracked in a hash
table with a hash over the source & destination addresses and ports.
However, the IPv6 hash is insufficient and can lead to a high rate of
collisions.

The IPv6 hash used an XOR to fit everything into the 96 bits for the
fast jenkins hash, meaning it is possible for an external entity to
ensure the hash collides, thus falling back to a linear search in the
bucket, which is slow.

We take the approach of hash the full length of IPv6 address in
__ipv6_addr_jhash() so that all users can benefit from a more secure
version.

While this may look like it adds overhead, the reality of modern CPUs
means that this is unmeasurable in real world scenarios.

In simulating with llvm-mca, the increase in cycles for the hashing
code was ~16 cycles on Skylake (from a base of ~155), and an extra ~9
on Nehalem (base of ~173).

In commit dd6d2910 ("netfilter: conntrack: switch to siphash")
netfilter switched from a jenkins hash to a siphash, but even the faster
hsiphash is a more significant overhead (~20-30%) in some preliminary
testing.  So, in this patch, we keep to the more conservative approach to
ensure we don't add much overhead per SYN.

In testing, this results in a consistently even spread across the
connection buckets.  In both testing and real-world scenarios, we have
not found any measurable performance impact.

Fixes: 08dcdbf6 ("ipv6: use a stronger hash for tcp")
Signed-off-by: NStewart Smith <trawets@amazon.com>
Signed-off-by: NSamuel Mendoza-Jonas <samjonas@amazon.com>
Suggested-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20230721222410.17914-1-kuniyu@amazon.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NWang Yufen <wangyufen@huawei.com>

mainline inclusion
from mainline-v5.16-rc8
commit 5bec7ca2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7UZT5

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

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

This commit initialises the xskb's free_list_node when the xskb is
allocated. This prevents a potential false negative returned from a call
to list_empty for that node, such as the one introduced in commit
199d983b ("xsk: Fix crash on double free in buffer pool")

In my environment this issue caused packets to not be received by
the xdpsock application if the traffic was running prior to application
launch. This happened when the first batch of packets failed the xskmap
lookup and XDP_PASS was returned from the bpf program. This action is
handled in the i40e zc driver (and others) by allocating an skbuff,
freeing the xdp_buff and adding the associated xskb to the
xsk_buff_pool's free_list if it hadn't been added already. Without this
fix, the xskb is not added to the free_list because the check to determine
if it was added already returns an invalid positive result. Later, this
caused allocation errors in the driver and the failure to receive packets.

Fixes: 199d983b ("xsk: Fix crash on double free in buffer pool")
Fixes: 2b43470a ("xsk: Introduce AF_XDP buffer allocation API")
Signed-off-by: NCiara Loftus <ciara.loftus@intel.com>
Acked-by: NMagnus Karlsson <magnus.karlsson@intel.com>
Link: https://lore.kernel.org/r/20211220155250.2746-1-ciara.loftus@intel.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Conflicts:
	net/xdp/xsk_buff_pool.c
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Long Li <leo.lilong@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/4S4SHAOWCO2WEWFW2EFRTQPJRF5RA2ZA/ 
Long Li (1):
  ksmbd: validate command request size

Namjae Jeon (1):
  ksmbd: validate command payload size


-- 
2.31.1
 
https://gitee.com/src-openeuler/kernel/issues/I7LU3O 
 
Link:https://gitee.com/openeuler/kernel/pulls/1813 

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

stable inclusion
from stable-v5.10.168
commit 0a626e27f984dfbe96bd8e4fd08f20a2ede3ea23
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

commit 462a8e08 upstream.

When we upgraded our kernel, we started seeing some page corruption like
the following consistently:

  BUG: Bad page state in process ganesha.nfsd  pfn:1304ca
  page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca
  flags: 0x17ffffc0000000()
  raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000
  raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000
  page dumped because: nonzero mapcount
  CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P    B      O      5.10.158-1.nutanix.20221209.el7.x86_64 #1
  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
  Call Trace:
   dump_stack+0x74/0x96
   bad_page.cold+0x63/0x94
   check_new_page_bad+0x6d/0x80
   rmqueue+0x46e/0x970
   get_page_from_freelist+0xcb/0x3f0
   ? _cond_resched+0x19/0x40
   __alloc_pages_nodemask+0x164/0x300
   alloc_pages_current+0x87/0xf0
   skb_page_frag_refill+0x84/0x110
   ...

Sometimes, it would also show up as corruption in the free list pointer
and cause crashes.

After bisecting the issue, we found the issue started from commit
e320d301 ("mm/page_alloc.c: fix freeing non-compound pages"):

	if (put_page_testzero(page))
		free_the_page(page, order);
	else if (!PageHead(page))
		while (order-- > 0)
			free_the_page(page + (1 << order), order);

So the problem is the check PageHead is racy because at this point we
already dropped our reference to the page.  So even if we came in with
compound page, the page can already be freed and PageHead can return
false and we will end up freeing all the tail pages causing double free.

Fixes: e320d301 ("mm/page_alloc.c: fix freeing non-compound pages")
Link: https://lore.kernel.org/lkml/BYAPR02MB448855960A9656EEA81141FC94D99@BYAPR02MB4488.namprd02.prod.outlook.com/
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: stable@vger.kernel.org
Signed-off-by: NChunwei Chen <david.chen@nutanix.com>
Reviewed-by: NVlastimil Babka <vbabka@suse.cz>
Reviewed-by: NMatthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 0ef2490a876b47c1e2db84ea3f4f69c8aca165f2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

commit d182bcf3 upstream.

The usage of edge-triggered interrupts lead to lost interrupts under load,
see [0]. This was confirmed to be fixed by using level-triggered
interrupts.
The report was about SDIO. However, as the host controller is the same
for SD and MMC, apply the change to all mmc controller instances.

[0] https://www.spinics.net/lists/linux-mmc/msg73991.html

Fixes: 221cf34b ("ARM64: dts: meson-axg: enable the eMMC controller")
Reported-by: NPeter Suti <peter.suti@streamunlimited.com>
Tested-by: NVyacheslav Bocharov <adeep@lexina.in>
Tested-by: NPeter Suti <peter.suti@streamunlimited.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Acked-by: NNeil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/c00655d3-02f8-6f5f-4239-ca2412420cad@gmail.comSigned-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 5bfc8f09619a9c31f812d85efe13091afede97bc
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

commit ac8db4cc upstream.

The usage of edge-triggered interrupts lead to lost interrupts under load,
see [0]. This was confirmed to be fixed by using level-triggered
interrupts.
The report was about SDIO. However, as the host controller is the same
for SD and MMC, apply the change to all mmc controller instances.

[0] https://www.spinics.net/lists/linux-mmc/msg73991.html

Fixes: 4759fd87 ("arm64: dts: meson: g12a: add mmc nodes")
Tested-by: NFUKAUMI Naoki <naoki@radxa.com>
Tested-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: NJerome Brunet <jbrunet@baylibre.com>
Cc: stable@vger.kernel.org
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Acked-by: NNeil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/27d89baa-b8fa-baca-541b-ef17a97cde3c@gmail.comSigned-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 809f4acb7f015e087c60ea74b935e24a16779b0a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

commit 66e45351 upstream.

The usage of edge-triggered interrupts lead to lost interrupts under load,
see [0]. This was confirmed to be fixed by using level-triggered
interrupts.
The report was about SDIO. However, as the host controller is the same
for SD and MMC, apply the change to all mmc controller instances.

[0] https://www.spinics.net/lists/linux-mmc/msg73991.html

Fixes: ef8d2ffe ("ARM64: dts: meson-gxbb: add MMC support")
Cc: stable@vger.kernel.org
Signed-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Acked-by: NNeil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/76e042e0-a610-5ed5-209f-c4d7f879df44@gmail.comSigned-off-by: NNeil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 8eee3521bca7104de4859b853d4358373291f681
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

commit 950b879b upstream.

In commit 588a513d ("arm64: Fix race condition on PG_dcache_clean
in __sync_icache_dcache()"), we found RISC-V has the same issue as the
previous arm64. The previous implementation didn't guarantee the correct
sequence of operations, which means flush_icache_all() hasn't been
called when the PG_dcache_clean was set. That would cause a risk of page
synchronization.

Fixes: 08f051ed ("RISC-V: Flush I$ when making a dirty page executable")
Signed-off-by: NGuo Ren <guoren@linux.alibaba.com>
Signed-off-by: NGuo Ren <guoren@kernel.org>
Reviewed-by: NAndrew Jones <ajones@ventanamicro.com>
Reviewed-by: NConor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230127035306.1819561-1-guoren@kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: NPalmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 6ff8b48253926147e441b9d0c833ca6494707d0b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

commit e7d84c6a upstream.

MDS expects the completed cap release prior to responding to the
session flush for cache drop.

Cc: stable@vger.kernel.org
Link: http://tracker.ceph.com/issues/38009Signed-off-by: NXiubo Li <xiubli@redhat.com>
Reviewed-by: NVenky Shankar <vshankar@redhat.com>
Reviewed-by: NJeff Layton <jlayton@kernel.org>
Signed-off-by: NIlya Dryomov <idryomov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 4f518a4a79bddfd1f87fe62a85bdece5ee809614
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

commit 54e5c00a upstream.

While checking Pin Assignments of the port and partner during probe, we
don't take into account whether the peripheral is a plug or receptacle.

This manifests itself in a mode entry failure on certain docks and
dongles with captive cables. For instance, the Startech.com Type-C to DP
dongle (Model #CDP2DP) advertises its DP VDO as 0x405. This would fail
the Pin Assignment compatibility check, despite it supporting
Pin Assignment C as a UFP.

Update the check to use the correct DP Pin Assign macros that
take the peripheral's receptacle bit into account.

Fixes: c1e5c2f0 ("usb: typec: altmodes/displayport: correct pin assignment for UFP receptacles")
Cc: stable@vger.kernel.org
Reported-by: NDiana Zigterman <dzigterman@chromium.org>
Signed-off-by: NPrashant Malani <pmalani@chromium.org>
Link: https://lore.kernel.org/r/20230208205318.131385-1-pmalani@chromium.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit f25fa93e52367d78ced6b33cfe97c8044b6724be
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

commit 303e724d upstream.

The Alcor Link AK9563 smartcard reader used on some Lenovo platforms
doesn't work. If LPM is enabled the reader will provide an invalid
usb config descriptor. Added quirk to disable LPM.

Verified fix on Lenovo P16 G1 and T14 G3
Tested-by: NMiroslav Zatko <mzatko@mirexoft.com>
Tested-by: NDennis Wassenberg <dennis.wassenberg@secunet.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDennis Wassenberg <dennis.wassenberg@secunet.com>
Signed-off-by: NMark Pearson <mpearson-lenovo@squebb.ca>
Link: https://lore.kernel.org/r/20230208181223.1092654-1-mpearson-lenovo@squebb.caSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit dd965ad39de494de5f4cbe02c3090401cb915791
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

commit 5f58d783 upstream.

We have this check to make sure we don't accidentally add older devices
that may have disappeared and re-appeared with an older generation from
being added to an fs_devices (such as a replace source device). This
makes sense, we don't want stale disks in our file system. However for
single disks this doesn't really make sense.

I've seen this in testing, but I was provided a reproducer from a
project that builds btrfs images on loopback devices. The loopback
device gets cached with the new generation, and then if it is re-used to
generate a new file system we'll fail to mount it because the new fs is
"older" than what we have in cache.

Fix this by freeing the cache when closing the device for a single device
filesystem. This will ensure that the mount command passed device path is
scanned successfully during the next mount.

CC: stable@vger.kernel.org # 5.10+
Reported-by: NDaan De Meyer <daandemeyer@fb.com>
Signed-off-by: NJosef Bacik <josef@toxicpanda.com>
Signed-off-by: NAnand Jain <anand.jain@oracle.com>
Reviewed-by: NDavid Sterba <dsterba@suse.com>
Signed-off-by: NDavid Sterba <dsterba@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 1be271c52bf3554edcb8d124d1f8c7f777ee5727
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

commit 811d5811 upstream.

The syzbot fuzzer detected a bug in the plusb network driver: A
zero-length control-OUT transfer was treated as a read instead of a
write.  In modern kernels this error provokes a WARNING:

usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0
WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411
usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
Modules linked in:
CPU: 1 PID: 4645 Comm: dhcpcd Not tainted
6.2.0-rc6-syzkaller-00050-g9f266cca #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/12/2023
RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
...
Call Trace:
 <TASK>
 usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
 usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
 usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153
 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010
 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068
 pl_vendor_req drivers/net/usb/plusb.c:60 [inline]
 pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]
 pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85
 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
 __dev_open+0x297/0x4d0 net/core/dev.c:1417
 __dev_change_flags+0x587/0x750 net/core/dev.c:8530
 dev_change_flags+0x97/0x170 net/core/dev.c:8602
 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147
 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979
 sock_do_ioctl+0xcc/0x230 net/socket.c:1169
 sock_ioctl+0x1f8/0x680 net/socket.c:1286
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and
remove the USB_DIR_IN flag.

Reported-and-tested-by: syzbot+2a0e7abd24f1eb90ce25@syzkaller.appspotmail.com
Signed-off-by: NAlan Stern <stern@rowland.harvard.edu>
Fixes: 090ffa9d ("[PATCH] USB: usbnet (9/9) module for pl2301/2302 cables")
CC: stable@vger.kernel.org
Link: https://lore.kernel.org/r/00000000000052099f05f3b3e298@google.com/Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit bbc850904457567e5e3bf431e38dd039742887aa
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit a8520be3 ]

If the firmware mangled the register contents too much,
check the saved value for the Direct IRQ mode. If it
matches, we will restore the pin state.
Reported-by: NJim Minter <jimminter@microsoft.com>
Fixes: 6989ea48 ("pinctrl: intel: Save and restore pins in "direct IRQ" mode")
Tested-by: NJim Minter <jimminter@microsoft.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Link: https://lore.kernel.org/r/20230206141558.20916-1-andriy.shevchenko@linux.intel.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 4863f46ddaf9ceca8acd0cb9d2f02a2c8e9c55ad
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit c63b8fd1 ]

Due to using the u16 type in the min_t() macros the SPI transfer length
will be cast to word before participating in the conditional statement
implied by the macro. Thus if the transfer length is greater than 64KB the
Tx/Rx FIFO threshold level value will be determined by the leftover of the
truncated after the type-case length. In the worst case it will cause the
dramatical performance drop due to the "Tx FIFO Empty" or "Rx FIFO Full"
interrupts triggered on each xfer word sent/received to/from the bus.

The problem can be easily fixed by specifying the unsigned int type in the
min_t() macros thus preventing the possible data loss.

Fixes: ea11370f ("spi: dw: get TX level without an additional variable")
Reported-by: NSergey Nazarov <Sergey.Nazarov@baikalelectronics.ru>
Signed-off-by: NSerge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230113185942.2516-1-Sergey.Semin@baikalelectronics.ruSigned-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 6e2a0521e4e84a2698f2da3950fb5c5496a4d208
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit d2d73e6d ]

Added checking of pointer "function" in pcs_set_mux().
pinmux_generic_get_function() can return NULL and the pointer
"function" was dereferenced without checking against NULL.

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

Fixes: 571aec4d ("pinctrl: single: Use generic pinmux helpers for managing functions")
Signed-off-by: NMaxim Korotkov <korotkov.maxim.s@gmail.com>
Reviewed-by: NTony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20221118104332.943-1-korotkov.maxim.s@gmail.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 61f8a493c0760883f73565d7a23af5a18f2077b2
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit 287a344a ]

The function signature is int, but we return a bool. Instead return a
negative errno as the kerneldoc suggests.

Fixes: 4d3d0e42 ("pinctrl: Add core support for Aspeed SoCs")
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20230119231856.52014-1-joel@jms.id.auSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit ef3edede7b732395db145735bf4feaa960573995
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit 5dac9f8d ]

This loop accidentally reuses the "i" iterator for both the inside and
the outside loop.  The value of MAX_STREAM_BUFFER is 5.  I believe that
chip->rmh.stat_len is in the 2-12 range.  If the value of .stat_len is
4 or more then it will loop exactly one time, but if it's less then it
is a forever loop.

It looks like it was supposed to combined into one loop where
conditions are checked.

Fixes: 8e632006 ("ALSA: lx_core: Remove useless #if 0 .. #endif")
Signed-off-by: NDan Carpenter <error27@gmail.com>
Link: https://lore.kernel.org/r/Y9jnJTis/mRFJAQp@kiliSigned-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 3914b71dad5a5527819f82f1d085f0087583bdeb
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit 3a082086 ]

When set/restore sysctl value, we should quote the value as some keys
may have multi values, e.g. net.ipv4.ping_group_range

Fixes: f5ae5778 ("selftests: forwarding: lib: Add sysctl_set(), sysctl_restore()")
Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
Reviewed-by: NPetr Machata <petrm@nvidia.com>
Link: https://lore.kernel.org/r/20230208032110.879205-1-liuhangbin@gmail.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 3eb04ef27811e334987cbf3de3dbad97cfe3a74d
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit 184e1e44 ]

When tracer is reloaded, the device will log the traces at the
beginning of the log buffer. Also, driver is reading the log buffer in
chunks in accordance to the consumer index.
Hence, zero consumer index when reloading the tracer.

Fixes: 4383cfcc ("net/mlx5: Add devlink reload")
Signed-off-by: NShay Drory <shayd@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit fac1fb80088ab9f6cae5a0480236d1d03fcfe002
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit db561fed ]

Whenever the driver is reading the string DBs into buffers, the driver
is setting the load bit, but the driver never clears this bit.
As a result, in case load bit is on and the driver query the device for
new string DBs, the driver won't read again the string DBs.
Fix it by clearing the load bit when query the device for new string
DBs.

Fixes: 2d693567 ("net/mlx5: Add support for fw live patch event")
Signed-off-by: NShay Drory <shayd@nvidia.com>
Reviewed-by: NMoshe Shemesh <moshe@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 703c3efa4b0b50a9c6a3726026c0f528857db812
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit 8aa5f171 ]

ethtool is returning an error for unknown speeds for the IPoIB interface:

$ ethtool ib0
netlink error: failed to retrieve link settings
netlink error: Invalid argument
netlink error: failed to retrieve link settings
netlink error: Invalid argument
Settings for ib0:
Link detected: no

After this change, ethtool will return success and show "unknown speed":

$ ethtool ib0
Settings for ib0:
Supported ports: [  ]
Supported link modes:   Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes:  Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Full
Auto-negotiation: off
Port: Other
PHYAD: 0
Transceiver: internal
Link detected: no

Fixes: eb234ee9 ("net/mlx5e: IPoIB, Add support for get_link_ksettings in ethtool")
Signed-off-by: NDragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: NGal Pressman <gal@nvidia.com>
Reviewed-by: NTariq Toukan <tariqt@nvidia.com>
Signed-off-by: NSaeed Mahameed <saeedm@nvidia.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 896bd85688b40e7242562b68b0fd13e4d29048b8
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit f964f839 ]

Alternative short title: don't instruct the hardware to match on
EtherType with "protocol 802.1Q" flower filters. It doesn't work for the
reasons detailed below.

With a command such as the following:

tc filter add dev $swp1 ingress chain $(IS1 2) pref 3 \
	protocol 802.1Q flower skip_sw vlan_id 200 src_mac $h1_mac \
	action vlan modify id 300 \
	action goto chain $(IS2 0 0)

the created filter is set by ocelot_flower_parse_key() to be of type
OCELOT_VCAP_KEY_ETYPE, and etype is set to {value=0x8100, mask=0xffff}.
This gets propagated all the way to is1_entry_set() which commits it to
hardware (the VCAP_IS1_HK_ETYPE field of the key). Compare this to the
case where src_mac isn't specified - the key type is OCELOT_VCAP_KEY_ANY,
and is1_entry_set() doesn't populate VCAP_IS1_HK_ETYPE.

The problem is that for VLAN-tagged frames, the hardware interprets the
ETYPE field as holding the encapsulated VLAN protocol. So the above
filter will only match those packets which have an encapsulated protocol
of 0x8100, rather than all packets with VLAN ID 200 and the given src_mac.

The reason why this is allowed to occur is because, although we have a
block of code in ocelot_flower_parse_key() which sets "match_protocol"
to false when VLAN keys are present, that code executes too late.
There is another block of code, which executes for Ethernet addresses,
and has a "goto finished_key_parsing" and skips the VLAN header parsing.
By skipping it, "match_protocol" remains with the value it was
initialized with, i.e. "true", and "proto" is set to f->common.protocol,
or 0x8100.

The concept of ignoring some keys rather than erroring out when they are
present but can't be offloaded is dubious in itself, but is present
since the initial commit fe3490e6 ("net: mscc: ocelot: Hardware
ofload for tc flower filter"), and it's outside of the scope of this
patch to change that.

The problem was introduced when the driver started to interpret the
flower filter's protocol, and populate the VCAP filter's ETYPE field
based on it.

To fix this, it is sufficient to move the code that parses the VLAN keys
earlier than the "goto finished_key_parsing" instruction. This will
ensure that if we have a flower filter with both VLAN and Ethernet
address keys, it won't match on ETYPE 0x8100, because the VLAN key
parsing sets "match_protocol = false".

Fixes: 86b956de ("net: mscc: ocelot: support matching on EtherType")
Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: NSimon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230205192409.1796428-1-vladimir.oltean@nxp.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>

stable inclusion
from stable-v5.10.168
commit 1ad4112c9fcf0bc08222b2b1614fba52ffd12255
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7URR4

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

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

[ Upstream commit 4d159f78 ]

When both ice and the irdma driver are loaded, a warning in
check_flush_dependency is being triggered. This is due to ice driver
workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one
is not.

According to kernel documentation, this flag should be set if the
workqueue will be involved in the kernel's memory reclamation flow.
Since it is not, there is no need for the ice driver's WQ to have this
flag set so remove it.

Example trace:

[  +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0
[  +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
[  +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha
in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel
_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1
0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_
core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs
ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter
acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba
ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
[  +0.000161]  [last unloaded: bonding]
[  +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S                 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1
[  +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
[  +0.000003] Workqueue: ice ice_service_task [ice]
[  +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0
[  +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08
9f e8 bb d3 07 01 <0f> 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06
[  +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282
[  +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000
[  +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80
[  +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112
[  +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000
[  +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400
[  +0.000004] FS:  0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000
[  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0
[  +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  +0.000002] PKRU: 55555554
[  +0.000003] Call Trace:
[  +0.000002]  <TASK>
[  +0.000003]  __flush_workqueue+0x203/0x840
[  +0.000006]  ? mutex_unlock+0x84/0xd0
[  +0.000008]  ? __pfx_mutex_unlock+0x10/0x10
[  +0.000004]  ? __pfx___flush_workqueue+0x10/0x10
[  +0.000006]  ? mutex_lock+0xa3/0xf0
[  +0.000005]  ib_cache_cleanup_one+0x39/0x190 [ib_core]
[  +0.000174]  __ib_unregister_device+0x84/0xf0 [ib_core]
[  +0.000094]  ib_unregister_device+0x25/0x30 [ib_core]
[  +0.000093]  irdma_ib_unregister_device+0x97/0xc0 [irdma]
[  +0.000064]  ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]
[  +0.000059]  ? up_write+0x5c/0x90
[  +0.000005]  irdma_remove+0x36/0x90 [irdma]
[  +0.000062]  auxiliary_bus_remove+0x32/0x50
[  +0.000007]  device_release_driver_internal+0xfa/0x1c0
[  +0.000005]  bus_remove_device+0x18a/0x260
[  +0.000007]  device_del+0x2e5/0x650
[  +0.000005]  ? __pfx_device_del+0x10/0x10
[  +0.000003]  ? mutex_unlock+0x84/0xd0
[  +0.000004]  ? __pfx_mutex_unlock+0x10/0x10
[  +0.000004]  ? _raw_spin_unlock+0x18/0x40
[  +0.000005]  ice_unplug_aux_dev+0x52/0x70 [ice]
[  +0.000160]  ice_service_task+0x1309/0x14f0 [ice]
[  +0.000134]  ? __pfx___schedule+0x10/0x10
[  +0.000006]  process_one_work+0x3b1/0x6c0
[  +0.000008]  worker_thread+0x69/0x670
[  +0.000005]  ? __kthread_parkme+0xec/0x110
[  +0.000007]  ? __pfx_worker_thread+0x10/0x10
[  +0.000005]  kthread+0x17f/0x1b0
[  +0.000005]  ? __pfx_kthread+0x10/0x10
[  +0.000004]  ret_from_fork+0x29/0x50
[  +0.000009]  </TASK>

Fixes: 940b61af ("ice: Initialize PF and setup miscellaneous interrupt")
Signed-off-by: NAnirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Signed-off-by: NMarcin Szycik <marcin.szycik@linux.intel.com>
Tested-by: NJakub Andrysiak <jakub.andrysiak@intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: Nzhaoxiaoqiang11 <zhaoxiaoqiang11@jd.com>