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

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

Refer to following function procedure, 'obj->mod' is got if not define
CONFIG_LIVEPATCH_FTRACE, but it is put if define
CONFIG_LIVEPATCH_STOP_MACHINE_CONSISTENCY. If enable state of these two
macros changed, reference count of 'obj->mod' would be wrong.

  klp_register_patch
      klp_init_patch
          klp_init_object
              klp_find_object_module
                  try_module_get    <-- !CONFIG_LIVEPATCH_FTRACE
              module_put  <-- CONFIG_LIVEPATCH_STOP_MACHINE_CONSISTENCY
      klp_free_patch_start
          klp_free_objects
              __klp_free_objects
                  module_put <-- CONFIG_LIVEPATCH_STOP_MACHINE_CONSISTENCY

So we use CONFIG_LIVEPATCH_STOP_MACHINE_CONSISTENCY uniformly.

Fixes: c33e4283 ("livepatch/core: Allow implementation without ftrace")
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Refer to following function procedure, klp_free_objects_mod_limited
seems redundant, so remove it:
  klp_register_patch
      klp_init_patch
          klp_init_object             <---
              klp_find_object_module      \
                  try_module_get           |<-- 1. If something wrong here
          jump_label_register         <----
          klp_free_objects_mod_limited    <-- 2. Check and put 'obj->mod'
              module_put
      klp_free_patch_start    <-- 3. Check and put 'obj->mod' again
          klp_free_objects
              __klp_free_objects
                  module_put
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Fix following reference count issues where get 'obj->mod' once but put
twice:
  1) klp_register_patch
      klp_init_patch
          klp_init_object
              klp_find_object_module
                  try_module_get    <-- 1. Get refcount once
              klp_init_object_loaded    <-- 2. If fail here!!!
              module_put    <-- 3. Put refcount first time
      klp_free_patch_start
          klp_free_objects
              __klp_free_objects
                  module_put    <-- 4. 'obj->mod' not null, put twice!!!

  2) klp_register_patch
    klp_init_patch
        klp_init_object
            klp_find_object_module
                try_module_get    <-- 1. Get refcount once
        kobject_add    <-- 2. If other objs fail here!!!
        klp_free_objects_mod_limited
            module_put    <-- 3. Put refcount first time
    klp_free_patch_start
        klp_free_objects
            __klp_free_objects
                module_put    <-- 4. 'obj->mod' not null, put twice!!!

Fixes: c33e4283 ("livepatch/core: Allow implementation without ftrace")
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

This makes step entry aligned with step_size*step_cnt but not step_size,
and check for alignment before traversing rmid_transform.

When modifying rmid with a value not aligned with step_size*step_cnt,
for_each_rmid_transform_point_step_from might miss next step point if
it has been occupied in case step_cnt or step_size not equals to 1,
which will cause the actual allocated rmid to be inconsistent with the
expected one.

Fixes: 8a2c07b5 ("arm64/mpam: rmid: refine allocation and release process")
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

arm64/mpam: refactor device tree structure to support multiple
devices

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

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

To support multiple mpam device nodes, all nodes should be organized
as child of the same parent nodes. This makes sure that the mpam
discovery start and complete procedure in the right execution order.
Add modification in the devicetree documentation to record this.
Signed-off-by: NXingang Wang <wangxingang5@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

The process of MPAM device tree initialization is like this:
arm_mpam_device_probe() 	// driver probe
  mpam_discovery_start()	// start discover mpam devices
    [...] 			// find and add mpam devices
  mpam_discovery_complete()   	// trigger mpam_enable

When there are multiple mpam device nodes, the driver probe procedure
will execute more than once. However, the mpam_discovery_start() and
mpam_discovery_complete() should only run once. Besides, the start
should run first, and the complete should run after all devices added.

So we reorganize the device tree structure, so that there will be only
one mpam device parent nodes, and the probe procedure will only run once.
We add the child node to represent the mpam devices, and traverse and
add all mpam devices in the middle procedure of driver probe.
Signed-off-by: NXingang Wang <wangxingang5@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4L735
CVE: NA

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

Fix modpost Section mismatch error in __mpam_device_create() and others.
These warnings will occur in high version gcc, for example 10.1.0.

  [...]
  WARNING: vmlinux.o(.text+0x2ed88): Section mismatch in reference from the
  function __mpam_device_create() to the function .init.text:mpam_device_alloc()
  The function __mpam_device_create() references
  the function __init mpam_device_alloc().
  This is often because __mpam_device_create lacks a __init
  annotation or the annotation of mpam_device_alloc is wrong.

  WARNING: vmlinux.o(.text.unlikely+0xa5c): Section mismatch in reference from
  the function mpam_resctrl_init() to the function .init.text:mpam_init_padding()
  The function mpam_resctrl_init() references
  the function __init mpam_init_padding().
  This is often because mpam_resctrl_init lacks a __init
  annotation or the annotation of mpam_init_padding is wrong.

  WARNING: vmlinux.o(.text.unlikely+0x5a9c): Section mismatch in reference from
  the function resctrl_group_init() to the function .init.text:resctrl_group_setup_root()
  The function resctrl_group_init() references
  the function __init resctrl_group_setup_root().
  This is often because resctrl_group_init lacks a __init
  annotation or the annotation of resctrl_group_setup_root is wrong.
  [...]

Fixes: 682eefba ("arm64/mpam: remove __init macro to support driver probe")
Signed-off-by: NXingang Wang <wangxingang5@huawei.com>
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Our test report a UAF:

[ 2073.019181] ==================================================================
[ 2073.019188] BUG: KASAN: use-after-free in __bfq_put_async_bfqq+0xa0/0x168
[ 2073.019191] Write of size 8 at addr ffff8000ccf64128 by task rmmod/72584
[ 2073.019192]
[ 2073.019196] CPU: 0 PID: 72584 Comm: rmmod Kdump: loaded Not tainted 4.19.90-yk #5
[ 2073.019198] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 2073.019200] Call trace:
[ 2073.019203]  dump_backtrace+0x0/0x310
[ 2073.019206]  show_stack+0x28/0x38
[ 2073.019210]  dump_stack+0xec/0x15c
[ 2073.019216]  print_address_description+0x68/0x2d0
[ 2073.019220]  kasan_report+0x238/0x2f0
[ 2073.019224]  __asan_store8+0x88/0xb0
[ 2073.019229]  __bfq_put_async_bfqq+0xa0/0x168
[ 2073.019233]  bfq_put_async_queues+0xbc/0x208
[ 2073.019236]  bfq_pd_offline+0x178/0x238
[ 2073.019240]  blkcg_deactivate_policy+0x1f0/0x420
[ 2073.019244]  bfq_exit_queue+0x128/0x178
[ 2073.019249]  blk_mq_exit_sched+0x12c/0x160
[ 2073.019252]  elevator_exit+0xc8/0xd0
[ 2073.019256]  blk_exit_queue+0x50/0x88
[ 2073.019259]  blk_cleanup_queue+0x228/0x3d8
[ 2073.019267]  null_del_dev+0xfc/0x1e0 [null_blk]
[ 2073.019274]  null_exit+0x90/0x114 [null_blk]
[ 2073.019278]  __arm64_sys_delete_module+0x358/0x5a0
[ 2073.019282]  el0_svc_common+0xc8/0x320
[ 2073.019287]  el0_svc_handler+0xf8/0x160
[ 2073.019290]  el0_svc+0x10/0x218
[ 2073.019291]
[ 2073.019294] Allocated by task 14163:
[ 2073.019301]  kasan_kmalloc+0xe0/0x190
[ 2073.019305]  kmem_cache_alloc_node_trace+0x1cc/0x418
[ 2073.019308]  bfq_pd_alloc+0x54/0x118
[ 2073.019313]  blkcg_activate_policy+0x250/0x460
[ 2073.019317]  bfq_create_group_hierarchy+0x38/0x110
[ 2073.019321]  bfq_init_queue+0x6d0/0x948
[ 2073.019325]  blk_mq_init_sched+0x1d8/0x390
[ 2073.019330]  elevator_switch_mq+0x88/0x170
[ 2073.019334]  elevator_switch+0x140/0x270
[ 2073.019338]  elv_iosched_store+0x1a4/0x2a0
[ 2073.019342]  queue_attr_store+0x90/0xe0
[ 2073.019348]  sysfs_kf_write+0xa8/0xe8
[ 2073.019351]  kernfs_fop_write+0x1f8/0x378
[ 2073.019359]  __vfs_write+0xe0/0x360
[ 2073.019363]  vfs_write+0xf0/0x270
[ 2073.019367]  ksys_write+0xdc/0x1b8
[ 2073.019371]  __arm64_sys_write+0x50/0x60
[ 2073.019375]  el0_svc_common+0xc8/0x320
[ 2073.019380]  el0_svc_handler+0xf8/0x160
[ 2073.019383]  el0_svc+0x10/0x218
[ 2073.019385]
[ 2073.019387] Freed by task 72584:
[ 2073.019391]  __kasan_slab_free+0x120/0x228
[ 2073.019394]  kasan_slab_free+0x10/0x18
[ 2073.019397]  kfree+0x94/0x368
[ 2073.019400]  bfqg_put+0x64/0xb0
[ 2073.019404]  bfqg_and_blkg_put+0x90/0xb0
[ 2073.019408]  bfq_put_queue+0x220/0x228
[ 2073.019413]  __bfq_put_async_bfqq+0x98/0x168
[ 2073.019416]  bfq_put_async_queues+0xbc/0x208
[ 2073.019420]  bfq_pd_offline+0x178/0x238
[ 2073.019424]  blkcg_deactivate_policy+0x1f0/0x420
[ 2073.019429]  bfq_exit_queue+0x128/0x178
[ 2073.019433]  blk_mq_exit_sched+0x12c/0x160
[ 2073.019437]  elevator_exit+0xc8/0xd0
[ 2073.019440]  blk_exit_queue+0x50/0x88
[ 2073.019443]  blk_cleanup_queue+0x228/0x3d8
[ 2073.019451]  null_del_dev+0xfc/0x1e0 [null_blk]
[ 2073.019459]  null_exit+0x90/0x114 [null_blk]
[ 2073.019462]  __arm64_sys_delete_module+0x358/0x5a0
[ 2073.019467]  el0_svc_common+0xc8/0x320
[ 2073.019471]  el0_svc_handler+0xf8/0x160
[ 2073.019474]  el0_svc+0x10/0x218
[ 2073.019475]
[ 2073.019479] The buggy address belongs to the object at ffff8000ccf63f00
 which belongs to the cache kmalloc-1024 of size 1024
[ 2073.019484] The buggy address is located 552 bytes inside of
 1024-byte region [ffff8000ccf63f00, ffff8000ccf64300)
[ 2073.019486] The buggy address belongs to the page:
[ 2073.019492] page:ffff7e000333d800 count:1 mapcount:0 mapping:ffff8000c0003a00 index:0x0 compound_mapcount: 0
[ 2073.020123] flags: 0x7ffff0000008100(slab|head)
[ 2073.020403] raw: 07ffff0000008100 ffff7e0003334c08 ffff7e00001f5a08 ffff8000c0003a00
[ 2073.020409] raw: 0000000000000000 00000000001c001c 00000001ffffffff 0000000000000000
[ 2073.020411] page dumped because: kasan: bad access detected
[ 2073.020412]
[ 2073.020414] Memory state around the buggy address:
[ 2073.020420]  ffff8000ccf64000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 2073.020424]  ffff8000ccf64080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 2073.020428] >ffff8000ccf64100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 2073.020430]                                   ^
[ 2073.020434]  ffff8000ccf64180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 2073.020438]  ffff8000ccf64200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 2073.020439] ==================================================================

After add some debug info, we found that the root cause is that the
oom_bfqq is moved to a non-root bfqg.

Thus fix the problem by don't move oom_bfqq.
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NJason Yan <yanaijie@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-5.16-rc6
commit e386dfc5
category: perf
bugzilla: https://gitee.com/openeuler/kernel/issues/I4S0SZ
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e386dfc56f837da66d00a078e5314bc8382fab83

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

Commit 054aa8d4 ("fget: check that the fd still exists after getting
a ref to it") fixed a race with getting a reference to a file just as it
was being closed.  It was a fairly minimal patch, and I didn't think
re-checking the file pointer lookup would be a measurable overhead,
since it was all right there and cached.

But I was wrong, as pointed out by the kernel test robot.

The 'poll2' case of the will-it-scale.per_thread_ops benchmark regressed
quite noticeably.  Admittedly it seems to be a very artificial test:
doing "poll()" system calls on regular files in a very tight loop in
multiple threads.

That means that basically all the time is spent just looking up file
descriptors without ever doing anything useful with them (not that doing
'poll()' on a regular file is useful to begin with).  And as a result it
shows the extra "re-check fd" cost as a sore thumb.

Happily, the regression is fixable by just writing the code to loook up
the fd to be better and clearer.  There's still a cost to verify the
file pointer, but now it's basically in the noise even for that
benchmark that does nothing else - and the code is more understandable
and has better comments too.

[ Side note: this patch is also a classic case of one that looks very
  messy with the default greedy Myers diff - it's much more legible with
  either the patience of histogram diff algorithm ]

Link: https://lore.kernel.org/lkml/20211210053743.GA36420@xsang-OptiPlex-9020/
Link: https://lore.kernel.org/lkml/20211213083154.GA20853@linux.intel.com/Reported-by: Nkernel test robot <oliver.sang@intel.com>
Tested-by: NCarel Si <beibei.si@intel.com>
Cc: Jann Horn <jannh@google.com>
Cc: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Conflicts:
	fs/file.c
Signed-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4KAP1?from=project-issue
CVE: NA

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

We reserve some fields beforehand for thread_info prone to change.
Signed-off-by: NGuan Jing <guanjing6@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Reserve several syscall entries for kabi compatibility.
For arch arm32,ppc32,riscv64,ppc64,arm64,x86_64 currently.
Signed-off-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.11-rc1
commit c5ef5294
category: bugfix
bugzilla: 186175, https://gitee.com/openeuler/kernel/issues/I4S77Z
CVE: NA

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

This silences the following tools/perf/ build warning:

  Warning: Kernel ABI header at 'tools/perf/arch/powerpc/entry/syscalls/syscall.tbl' differs from latest version at 'arch/powerpc/kernel/syscalls/syscall.tbl'

Just make them same:

  cp arch/powerpc/kernel/syscalls/syscall.tbl tools/perf/arch/powerpc/entry/syscalls/syscall.tbl
Signed-off-by: NTiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Xuefeng Li <lixuefeng@loongson.cn>
Link: http://lore.kernel.org/lkml/1608278364-6733-4-git-send-email-yangtiezhu@loongson.cn
[ There were updates after Tiezhu's post, so I just updated the copy ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
[liwei391@huawei.com: remove 441]
Signed-off-by: NWei Li <liwei391@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

Reference: https://patchwork.kernel.org/project/linux-arm-kernel/cover/20211210184133.320748-1-broonie@kernel.org/

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

Reserve space for arm64 SME in thread_struct.

According to the implementation of SME, we need to reserve space for the
following fields like this:

        +enum vec_type {
        +       ARM64_VEC_SVE = 0,
        +       ARM64_VEC_SME,
        +       ARM64_VEC_MAX,
        +};
        +
         struct thread_struct {
                struct cpu_context      cpu_context;    /* cpu context */

        @@ -149,8 +155,6 @@ struct thread_struct {

                unsigned int            fpsimd_cpu;
                void                    *sve_state;     /* SVE registers, if any */
        -       unsigned int            sve_vl;         /* SVE vector length */
        -       unsigned int            sve_vl_onexec;  /* SVE vl after next exec */
                unsigned long           fault_address;  /* fault info */
                unsigned long           fault_code;     /* ESR_EL1 value */
                struct debug_info       debug;          /* debugging */
        @@ -162,6 +166,11 @@ struct thread_struct {
                u64                     sctlr_tcf0;
                u64                     gcr_user_incl;
         #endif
        +       void *za_state; /* ZA register, if any */
        +       unsigned int vl[ARM64_VEC_MAX]; /* vector length */
        +       unsigned int vl_onexec[ARM64_VEC_MAX]; /* vl after next exec */
        +       u64 svcr;
        +       u64 tpidr2_el0;
         };

This requires at least five 64bit spaces, other three for expansion.
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: NCheng Jian <cj.chengjian@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

KABI reservation for IMA namespace

reference: https://gitee.com/openeuler/kernel/issues/I49KW1Signed-off-by: NGuo Zihua <guozihua@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Reviewed-by: Nweiyang wang <wangweiyang2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

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

Reserve space for struct acpi_device_power
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

euleros inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4PF3R?from=project-issue

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

Reserve space for future fuse kabi expansion
Signed-off-by: NWenchao Hao <haowenchao@huawei.com>
Reviewed-by: NWu Bo <wubo40@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4HE7P?from=project-issue
CVE: NA

--------

Reserve some fields beforehand for some net subsystems framework related structures prone
to change.

---------
Signed-off-by: NWang Hai <wanghai38@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

--------

Reserving some fields in struct input_dev for future development.
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

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

--------

Reserving some fields in struct i2c_bus_recovery_info, i2c_adapter,
i2c_board_info and i2c_algorithm for future development.
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
Reviewed-by: NLiao Chang <liaochang1@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I4KAP1?from=project-issue
CVE: NA

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

We reserve some fields beforehand for sched structures prone to change,
therefore, we can hot add/change features of sched with this enhancement.
After reserving, normally cache does not matter as the reserved fields
are not accessed at all.
Signed-off-by: NGuan Jing <guanjing6@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.16-rc1
commit bcf9033e
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Q94A
CVE: NA

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

THREAD_INFO_IN_TASK moved the CPU field out of thread_info, but this
causes some issues on architectures that define raw_smp_processor_id()
in terms of this field, due to the fact that #include'ing linux/sched.h
to get at struct task_struct is problematic in terms of circular
dependencies.

Given that thread_info and task_struct are the same data structure
anyway when THREAD_INFO_IN_TASK=y, let's move it back so that having
access to the type definition of struct thread_info is sufficient to
reference the CPU number of the current task.

Note that this requires THREAD_INFO_IN_TASK's definition of the
task_thread_info() helper to be updated, as task_cpu() takes a
pointer-to-const, whereas task_thread_info() (which is used to generate
lvalues as well), needs a non-const pointer. So make it a macro instead.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: NGuan Jing <guanjing6@huawei.com>

Conflicts:
	arch/arm64/kernel/head.S
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.16-rc1
commit 227d735d
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Q94A
CVE: NA

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

The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to powerpc's definition
of struct thread_info.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: NGuan Jing <guanjing6@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.16-rc1
commit bd2e2632
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Q94A
CVE: NA

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

The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to s390's definition of
struct thread_info.

Note that s390 always has CONFIG_SMP=y so there is no point in guarding
the CPU field with an #ifdef.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NHeiko Carstens <hca@linux.ibm.com>
Signed-off-by: NGuan Jing <guanjing6@huawei.com>

Conflicts:
	arch/s390/include/asm/thread_info.h
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.16-rc1
commit 5443f98f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Q94A
CVE: NA

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

The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to x86's definition of
struct thread_info.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Acked-by: NBorislav Petkov <bp@suse.de>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NGuan Jing <guanjing6@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.16-rc1
commit 001430c1
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Q94A
CVE: NA

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

The CPU field will be moved back into thread_info even when
THREAD_INFO_IN_TASK is enabled, so add it back to arm64's definition of
struct thread_info.

Note that arm64 always has CONFIG_SMP=y so there is no point in guarding
the CPU field with an #ifdef.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NGuan Jing <guanjing6@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.16-rc1
commit 336868af
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Q94A
CVE: NA

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

Instead of relying on awful hacks to obtain the offset of the cpu field
in struct task_struct, move it back into struct thread_info, which does
not create the same level of circular dependency hell when trying to
include the header file that defines it.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: NGuan Jing <guanjing6@huawei.com>

Conflicts:
	arch/powerpc/Makefile
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

mainline inclusion
from mainline-v5.16-rc1
commit 8aa0fb0f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I4Q94A
CVE: NA

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

Now that the core code switched back to using thread_info::cpu to keep
a task's CPU number, we no longer need to keep it in sync explicitly. So
just drop the code that does this.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
Acked-by: NPalmer Dabbelt <palmerdabbelt@google.com>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Signed-off-by: NGuan Jing <guanjing6@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit 674071c9eb26ae75a63dd7d6a49857a00c903754
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

commit cf73ed89 upstream.

Since irq request is the last thing in the driver probe, it happens
later than the input device registration. This means that there is a
small time window where if the open method is called the driver will
attempt to enable not yet available irq.

Fix that by moving the irq request before the input device registration.
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Fixes: 26822652 ("Input: add zinitix touchscreen driver")
Signed-off-by: NNikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20220106072840.36851-2-nikita@trvn.ruSigned-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit ef81f7d406c2f77fa0942db732adb8de1f4dca11
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit c8013355 ]

Since [1], added in 5.7, the absence of a gpio-ranges property has
prevented GPIOs from being restored to inputs when released.
Add those properties for BCM283x and BCM2711 devices.

[1] commit 2ab73c6d ("gpio: Support GPIO controllers without
    pin-ranges")

Link: https://lore.kernel.org/r/20220104170247.956760-1-linus.walleij@linaro.org
Fixes: 2ab73c6d ("gpio: Support GPIO controllers without pin-ranges")
Fixes: 266423e6 ("pinctrl: bcm2835: Change init order for gpio hogs")
Reported-by: NStefan Wahren <stefan.wahren@i2se.com>
Reported-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reported-by: NJan Kiszka <jan.kiszka@web.de>
Signed-off-by: NPhil Elwell <phil@raspberrypi.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20211206092237.4105895-3-phil@raspberrypi.comSigned-off-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit f63fa1a0d4df66448c045676f2b1e722d07697a4
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit fb7bc920 ]

Add a check that the user-provided option is at least as long as the
number of bytes we intend to read. Before this patch we would blindly
read sizeof(int) bytes even in cases where the user passed
optlen<sizeof(int), which would potentially read garbage or fault.

Discovered by new tests in https://github.com/google/gvisor/pull/6957 .

The original get_user call predates history in the git repo.
Signed-off-by: NTamir Duberstein <tamird@gmail.com>
Signed-off-by: NWillem de Bruijn <willemb@google.com>
Link: https://lore.kernel.org/r/20211229200947.2862255-1-willemdebruijn.kernel@gmail.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit cf07884e6becbc654bc0b4932415faa0ba3db6cf
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit d97e631a ]

[Why]
The change of setting a timer callback on boot for 10 seconds is still
working, just lacked power down for DCN10.

[How]
Added power down for DCN10.
Tested-by: NDaniel Wheeler <daniel.wheeler@amd.com>
Reviewed-by: NAnthony Koo <Anthony.Koo@amd.com>
Acked-by: NRodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Signed-off-by: NDerek Lai <Derek.Lai@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit 10b9ccd0674df02992a7e02b877fbd2eed4b1e14
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit 8b5fdfc5 ]

As we build for mips, we meet following error. l1_init error with
multiple definition. Some architecture devices usually marked with
l1, l2, lxx as the start-up phase. so we change the mISDN function
names, align with Isdnl2_xxx.

mips-linux-gnu-ld: drivers/isdn/mISDN/layer1.o: in function `l1_init':
(.text+0x890): multiple definition of `l1_init'; \
arch/mips/kernel/bmips_5xxx_init.o:(.text+0xf0): first defined here
make[1]: *** [home/mips/kernel-build/linux/Makefile:1161: vmlinux] Error 1
Signed-off-by: Nwolfgang huang <huangjinhui@kylinos.cn>
Reported-by: Nk2ci <kernel-bot@kylinos.cn>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit dd8a09cfbb999154039468d371f8cc23ae05eaf4
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit 5f501532 ]

The function obtain the next buffer without boundary check.
We should return with I/O error code.

The bug is found by fuzzing and the crash report is attached.
It is an OOB bug although reported as use-after-free.

[    4.804724] BUG: KASAN: use-after-free in aq_ring_rx_clean+0x1e88/0x2730 [atlantic]
[    4.805661] Read of size 4 at addr ffff888034fe93a8 by task ksoftirqd/0/9
[    4.806505]
[    4.806703] CPU: 0 PID: 9 Comm: ksoftirqd/0 Tainted: G        W         5.6.0 #34
[    4.809030] Call Trace:
[    4.809343]  dump_stack+0x76/0xa0
[    4.809755]  print_address_description.constprop.0+0x16/0x200
[    4.810455]  ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic]
[    4.811234]  ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic]
[    4.813183]  __kasan_report.cold+0x37/0x7c
[    4.813715]  ? aq_ring_rx_clean+0x1e88/0x2730 [atlantic]
[    4.814393]  kasan_report+0xe/0x20
[    4.814837]  aq_ring_rx_clean+0x1e88/0x2730 [atlantic]
[    4.815499]  ? hw_atl_b0_hw_ring_rx_receive+0x9a5/0xb90 [atlantic]
[    4.816290]  aq_vec_poll+0x179/0x5d0 [atlantic]
[    4.816870]  ? _GLOBAL__sub_I_65535_1_aq_pci_func_init+0x20/0x20 [atlantic]
[    4.817746]  ? __next_timer_interrupt+0xba/0xf0
[    4.818322]  net_rx_action+0x363/0xbd0
[    4.818803]  ? call_timer_fn+0x240/0x240
[    4.819302]  ? __switch_to_asm+0x40/0x70
[    4.819809]  ? napi_busy_loop+0x520/0x520
[    4.820324]  __do_softirq+0x18c/0x634
[    4.820797]  ? takeover_tasklets+0x5f0/0x5f0
[    4.821343]  run_ksoftirqd+0x15/0x20
[    4.821804]  smpboot_thread_fn+0x2f1/0x6b0
[    4.822331]  ? smpboot_unregister_percpu_thread+0x160/0x160
[    4.823041]  ? __kthread_parkme+0x80/0x100
[    4.823571]  ? smpboot_unregister_percpu_thread+0x160/0x160
[    4.824301]  kthread+0x2b5/0x3b0
[    4.824723]  ? kthread_create_on_node+0xd0/0xd0
[    4.825304]  ret_from_fork+0x35/0x40
Signed-off-by: NZekun Shen <bruceshenzk@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit c2f4bb251eb4dedb045ee1c7787db6467c4c6a8b
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit 6c25449e ]

$ cat /pro/net/udp

before:

  sl  local_address rem_address   st tx_queue rx_queue tr tm->when
26050: 0100007F:0035 00000000:0000 07 00000000:00000000 00:00000000
26320: 0100007F:0143 00000000:0000 07 00000000:00000000 00:00000000
27135: 00000000:8472 00000000:0000 07 00000000:00000000 00:00000000

after:

   sl  local_address rem_address   st tx_queue rx_queue tr tm->when
26050: 0100007F:0035 00000000:0000 07 00000000:00000000 00:00000000
26320: 0100007F:0143 00000000:0000 07 00000000:00000000 00:00000000
27135: 00000000:8472 00000000:0000 07 00000000:00000000 00:00000000
Signed-off-by: Nyangxingwu <xingwu.yang@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit f82b48d1d86b50daaf379a68cbc7f2a2216eff8e
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit c1833c39 ]

The "__ip6_tnl_parm" struct was left uninitialized causing an invalid
load of random data when the "__ip6_tnl_parm" struct was used elsewhere.
As an example, in the function "ip6_tnl_xmit_ctl()", it tries to access
the "collect_md" member. With "__ip6_tnl_parm" being uninitialized and
containing random data, the UBSAN detected that "collect_md" held a
non-boolean value.

The UBSAN issue is as follows:
===============================================================
UBSAN: invalid-load in net/ipv6/ip6_tunnel.c:1025:14
load of value 30 is not a valid value for type '_Bool'
CPU: 1 PID: 228 Comm: kworker/1:3 Not tainted 5.16.0-rc4+ #8
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
<TASK>
dump_stack_lvl+0x44/0x57
ubsan_epilogue+0x5/0x40
__ubsan_handle_load_invalid_value+0x66/0x70
? __cpuhp_setup_state+0x1d3/0x210
ip6_tnl_xmit_ctl.cold.52+0x2c/0x6f [ip6_tunnel]
vti6_tnl_xmit+0x79c/0x1e96 [ip6_vti]
? lock_is_held_type+0xd9/0x130
? vti6_rcv+0x100/0x100 [ip6_vti]
? lock_is_held_type+0xd9/0x130
? rcu_read_lock_bh_held+0xc0/0xc0
? lock_acquired+0x262/0xb10
dev_hard_start_xmit+0x1e6/0x820
__dev_queue_xmit+0x2079/0x3340
? mark_lock.part.52+0xf7/0x1050
? netdev_core_pick_tx+0x290/0x290
? kvm_clock_read+0x14/0x30
? kvm_sched_clock_read+0x5/0x10
? sched_clock_cpu+0x15/0x200
? find_held_lock+0x3a/0x1c0
? lock_release+0x42f/0xc90
? lock_downgrade+0x6b0/0x6b0
? mark_held_locks+0xb7/0x120
? neigh_connected_output+0x31f/0x470
? lockdep_hardirqs_on+0x79/0x100
? neigh_connected_output+0x31f/0x470
? ip6_finish_output2+0x9b0/0x1d90
? rcu_read_lock_bh_held+0x62/0xc0
? ip6_finish_output2+0x9b0/0x1d90
ip6_finish_output2+0x9b0/0x1d90
? ip6_append_data+0x330/0x330
? ip6_mtu+0x166/0x370
? __ip6_finish_output+0x1ad/0xfb0
? nf_hook_slow+0xa6/0x170
ip6_output+0x1fb/0x710
? nf_hook.constprop.32+0x317/0x430
? ip6_finish_output+0x180/0x180
? __ip6_finish_output+0xfb0/0xfb0
? lock_is_held_type+0xd9/0x130
ndisc_send_skb+0xb33/0x1590
? __sk_mem_raise_allocated+0x11cf/0x1560
? dst_output+0x4a0/0x4a0
? ndisc_send_rs+0x432/0x610
addrconf_dad_completed+0x30c/0xbb0
? addrconf_rs_timer+0x650/0x650
? addrconf_dad_work+0x73c/0x10e0
addrconf_dad_work+0x73c/0x10e0
? addrconf_dad_completed+0xbb0/0xbb0
? rcu_read_lock_sched_held+0xaf/0xe0
? rcu_read_lock_bh_held+0xc0/0xc0
process_one_work+0x97b/0x1740
? pwq_dec_nr_in_flight+0x270/0x270
worker_thread+0x87/0xbf0
? process_one_work+0x1740/0x1740
kthread+0x3ac/0x490
? set_kthread_struct+0x100/0x100
ret_from_fork+0x22/0x30
</TASK>
===============================================================

The solution is to initialize "__ip6_tnl_parm" struct to zeros in the
"vti6_siocdevprivate()" function.
Signed-off-by: NWilliam Zhao <wizhao@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit 8c87a83ef891aff7f8d620abac841dadbf780035
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit 1b8d0300 ]

|- iscsi_if_destroy_conn            |-dev_attr_show
 |-iscsi_conn_teardown
  |-spin_lock_bh                     |-iscsi_sw_tcp_conn_get_param

  |-kfree(conn->persistent_address)   |-iscsi_conn_get_param
  |-kfree(conn->local_ipaddr)
                                       ==>|-read persistent_address
                                       ==>|-read local_ipaddr
  |-spin_unlock_bh

When iscsi_conn_teardown() and iscsi_conn_get_param() happen in parallel, a
UAF may be triggered.

Link: https://lore.kernel.org/r/046ec8a0-ce95-d3fc-3235-666a7c65b224@huawei.comReported-by: NLu Tixiong <lutianxiong@huawei.com>
Reviewed-by: NMike Christie <michael.christie@oracle.com>
Reviewed-by: NLee Duncan <lduncan@suse.com>
Signed-off-by: NLixiaokeng <lixiaokeng@huawei.com>
Signed-off-by: NLinfeilong <linfeilong@huawei.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit b798b677f94d0bfc5e79c6f6fd87d90a8abc742c
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit e3d4621c ]

Use the Interval value from isoc/intr endpoint descriptor, no need
minus one. The original code doesn't cause transfer error for
normal cases, but it may have side effect with respond time of ERDY
or tPingTimeout.
Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
Link: https://lore.kernel.org/r/20211218095749.6250-1-chunfeng.yun@mediatek.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit 498d77fc5e38880599853cf74139cea74dac8f08
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit 95bdba23 ]

As Nicolas noted, if gateway validation fails walking the multipath
attribute the code should jump to the cleanup to free previously
allocated memory.

Fixes: 1ff15a71 ("ipv6: Check attribute length for RTA_GATEWAY when deleting multipath route")
Signed-off-by: NDavid Ahern <dsahern@kernel.org>
Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Link: https://lore.kernel.org/r/20220103170555.94638-1-dsahern@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit 72b0d14a0a882262d1c38a12be5f9042f53aa10e
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

[ Upstream commit e30a845b ]

ip6_route_multipath_del loop continues processing the multipath
attribute even if delete of a nexthop path fails. For consistency,
do the same if the gateway attribute is invalid.

Fixes: 1ff15a71 ("ipv6: Check attribute length for RTA_GATEWAY when deleting multipath route")
Signed-off-by: NDavid Ahern <dsahern@kernel.org>
Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
Link: https://lore.kernel.org/r/20220103171911.94739-1-dsahern@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>

stable inclusion
from stable-v5.10.91
commit 5a7d650bb181c658719dcabb25702d502530092f
bugzilla: 186187 https://gitee.com/openeuler/kernel/issues/I4SI2C

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

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

commit 80211be1 upstream.

Instead of one shot run of ADC at beginning of charging, run continuous
conversion to ensure that all charging-related values are monitored
properly (input voltage, input current, themperature etc.).
Signed-off-by: NYauhen Kharuzhy <jekhor@gmail.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NChen Jun <chenjun102@huawei.com>
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>