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

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

handle_read_error() will resumit r10_bio by raid10_read_request(), which
will call bio_start_io_acct() again, while bio_end_io_acct() will only
be called once.

Fix the problem by don't account io again from handle_read_error().

Fixes: 528bc2cf ("md/raid10: enable io accounting")
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.15.95
commit fdaf88531cfd17b2a710cceb3141ef6f9085ff40
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6H3MB
CVE: CVE-2023-0461

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

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

When we backport dadd0dcaa67d ("net/ulp: prevent ULP without clone op from
entering the LISTEN status"), we have accidentally backported a part of
7a7160ed ("net: Return errno in sk->sk_prot->get_port().") and removed
err = -EADDRINUSE in inet_csk_listen_start().

Thus, listen() no longer returns -EADDRINUSE even if ->get_port() failed
as reported in [0].

We set -EADDRINUSE to err just before ->get_port() to fix the regression.

[0]: https://lore.kernel.org/stable/EF8A45D0-768A-4CD5-9A8A-0FA6E610ABF7@winter.cafe/Reported-by: NWinter <winter@winter.cafe>
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc1
commit be9832c2
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6H3MB
CVE: CVE-2023-0461

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

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

Commit 2c02d41d ("net/ulp: prevent ULP without clone op from entering
the LISTEN status") guarantees that all ULP listeners have clone() op, so
we no longer need to test it in inet_clone_ulp().
Signed-off-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Link: https://lore.kernel.org/r/20230217200920.85306-1-kuniyu@amazon.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.165
commit f6c201b4382d1536f44b922b8f16dcb4772cc82c
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6H3MB
CVE: CVE-2023-0461

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

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

commit 8ccc9936 upstream.

The referenced commit changed the error code returned by the kernel
when preventing a non-established socket from attaching the ktls
ULP. Before to such a commit, the user-space got ENOTCONN instead
of EINVAL.

The existing self-tests depend on such error code, and the change
caused a failure:

  RUN           global.non_established ...
 tls.c:1673:non_established:Expected errno (22) == ENOTCONN (107)
 non_established: Test failed at step #3
          FAIL  global.non_established

In the unlikely event existing applications do the same, address
the issue by restoring the prior error code in the above scenario.

Note that the only other ULP performing similar checks at init
time - smc_ulp_ops - also fails with ENOTCONN when trying to attach
the ULP to a non-established socket.
Reported-by: NSabrina Dubroca <sd@queasysnail.net>
Fixes: 2c02d41d ("net/ulp: prevent ULP without clone op from entering the LISTEN status")
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
Reviewed-by: NSabrina Dubroca <sd@queasysnail.net>
Link: https://lore.kernel.org/r/7bb199e7a93317fb6f8bf8b9b2dc71c18f337cde.1674042685.git.pabeni@redhat.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.163
commit f8ed0a93b5d576bbaf01639ad816473bdfd1dcb0
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6H3MB
CVE: CVE-2023-0461

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

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

commit 2c02d41d upstream.

When an ULP-enabled socket enters the LISTEN status, the listener ULP data
pointer is copied inside the child/accepted sockets by sk_clone_lock().

The relevant ULP can take care of de-duplicating the context pointer via
the clone() operation, but only MPTCP and SMC implement such op.

Other ULPs may end-up with a double-free at socket disposal time.

We can't simply clear the ULP data at clone time, as TLS replaces the
socket ops with custom ones assuming a valid TLS ULP context is
available.

Instead completely prevent clone-less ULP sockets from entering the
LISTEN status.

Fixes: 734942cc ("tcp: ULP infrastructure")
Reported-by: Nslipper <slipper.alive@gmail.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>
Link: https://lore.kernel.org/r/4b80c3d1dbe3d0ab072f80450c202d9bc88b4b03.1672740602.git.pabeni@redhat.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.2-rc7
commit ffe2a225
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6I7U2
CVE: CVE-2023-1075

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

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

tls_is_tx_ready() checks that list_first_entry() does not return NULL.
This condition can never happen. For empty lists, list_first_entry()
returns the list_entry() of the head, which is a type confusion.
Use list_first_entry_or_null() which returns NULL in case of empty
lists.

Fixes: a42055e8 ("net/tls: Add support for async encryption of records for performance")
Signed-off-by: NPietro Borrello <borrello@diag.uniroma1.it>
Link: https://lore.kernel.org/r/20230128-list-entry-null-check-tls-v1-1-525bbfe6f0d0@diag.uniroma1.itSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Conflicts:
	net/tls/tls_sw.c
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.17-rc1
commit fa0ef938
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6IEH4
CVE: CVE-2023-22995

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

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

Add the missing platform_device_put() before return from
dwc3_qcom_acpi_register_core in the error handling case.
Signed-off-by: NMiaoqian Lin <linmq006@gmail.com>
Link: https://lore.kernel.org/r/20211231113641.31474-1-linmq006@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixes: 2bc02355 ("usb: dwc3: qcom: Add support for booting with ACPI")
[Fix conflict due to lack of 8dc6e6dd]
Conflict:
	drivers/usb/dwc3/dwc3-qcom.c
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.155
commit 6322dda483344abe47d17335809f7bbb730bd88b
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6HWOS
CVE: CVE-2023-26607

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=tags/v5.10.156&id=6322dda483344abe47d17335809f7bbb730bd88b

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

commit 36a4d82d upstream.

Kernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find().  To
ensure access on these ATTR_RECORDs are within bounds, kernel will do some
checking during iteration.

The problem is that during checking whether ATTR_RECORD's name is within
bounds, kernel will dereferences the ATTR_RECORD name_offset field, before
checking this ATTR_RECORD strcture is within bounds.  This problem may
result out-of-bounds read in ntfs_attr_find(), reported by Syzkaller:

==================================================================
BUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597
Read of size 2 at addr ffff88807e352009 by task syz-executor153/3607

[...]
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:317 [inline]
 print_report.cold+0x2ba/0x719 mm/kasan/report.c:433
 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495
 ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597
 ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193
 ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845
 ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854
 mount_bdev+0x34d/0x410 fs/super.c:1400
 legacy_get_tree+0x105/0x220 fs/fs_context.c:610
 vfs_get_tree+0x89/0x2f0 fs/super.c:1530
 do_new_mount fs/namespace.c:3040 [inline]
 path_mount+0x1326/0x1e20 fs/namespace.c:3370
 do_mount fs/namespace.c:3383 [inline]
 __do_sys_mount fs/namespace.c:3591 [inline]
 __se_sys_mount fs/namespace.c:3568 [inline]
 __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
 [...]
 </TASK>

The buggy address belongs to the physical page:
page:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350
head:ffffea0001f8d400 order:3 compound_mapcount:0 compound_pincount:0
flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 0000000000000000 dead000000000122 ffff888011842140
raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
 ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                      ^
 ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================

This patch solves it by moving the ATTR_RECORD strcture's bounds checking
earlier, then checking whether ATTR_RECORD's name is within bounds.
What's more, this patch also add some comments to improve its
maintainability.

Link: https://lkml.kernel.org/r/20220831160935.3409-3-yin31149@gmail.com
Link: https://lore.kernel.org/all/1636796c-c85e-7f47-e96f-e074fee3c7d3@huawei.com/
Link: https://groups.google.com/g/syzkaller-bugs/c/t_XdeKPGTR4/m/LECAuIGcBgAJSigned-off-by: Nchenxiaosong (A) <chenxiaosong2@huawei.com>
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NHawkins Jiawei <yin31149@gmail.com>
Reported-by: syzbot+5f8dcabe4a3b2c51c607@syzkaller.appspotmail.com
Tested-by: syzbot+5f8dcabe4a3b2c51c607@syzkaller.appspotmail.com
Cc: Anton Altaparmakov <anton@tuxera.com>
Cc: syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NLong Li <leo.lilong@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.12-rc1
commit 0f1d344f
category: bugfix
bugzilla: 188445,https://gitee.com/openeuler/kernel/issues/I6J5NZ

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

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

iter_file_splice_write() may spawn bvec segments with zero-length. In
preparation for prohibiting them, filter out by hand at splice level.
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
Reviewed-by: NMing Lei <ming.lei@redhat.com>
Signed-off-by: NJens Axboe <axboe@kernel.dk>
Signed-off-by: NBaokun Li <libaokun1@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.168
commit c53f34ec3fbf3e9f67574118a6bb35ae1146f7ca
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6I7UF
CVE: CVE-2023-1078

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

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

[ Upstream commit f753a689 ]

rds_rm_zerocopy_callback() uses list_entry() on the head of a list
causing a type confusion.
Use list_first_entry() to actually access the first element of the
rs_zcookie_queue list.

Fixes: 9426bbc6 ("rds: use list structure to track information for zerocopy completion notification")
Reviewed-by: NWillem de Bruijn <willemb@google.com>
Signed-off-by: NPietro Borrello <borrello@diag.uniroma1.it>
Link: https://lore.kernel.org/r/20230202-rds-zerocopy-v3-1-83b0df974f9a@diag.uniroma1.itSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc1
commit 66b2c338
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6I7UC
CVE: CVE-2023-1076

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

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

sock_init_data() assumes that the `struct socket` passed in input is
contained in a `struct socket_alloc` allocated with sock_alloc().
However, tap_open() passes a `struct socket` embedded in a `struct
tap_queue` allocated with sk_alloc().
This causes a type confusion when issuing a container_of() with
SOCK_INODE() in sock_init_data() which results in assigning a wrong
sk_uid to the `struct sock` in input.
On default configuration, the type confused field overlaps with
padding bytes between `int vnet_hdr_sz` and `struct tap_dev __rcu
*tap` in `struct tap_queue`, which makes the uid of all tap sockets 0,
i.e., the root one.
Fix the assignment by using sock_init_data_uid().

Fixes: 86741ec2 ("net: core: Add a UID field to struct sock.")
Signed-off-by: NPietro Borrello <borrello@diag.uniroma1.it>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NBaisong Zhong <zhongbaisong@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc1
commit a096ccca
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6I7UC
CVE: CVE-2023-1076

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

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

sock_init_data() assumes that the `struct socket` passed in input is
contained in a `struct socket_alloc` allocated with sock_alloc().
However, tun_chr_open() passes a `struct socket` embedded in a `struct
tun_file` allocated with sk_alloc().
This causes a type confusion when issuing a container_of() with
SOCK_INODE() in sock_init_data() which results in assigning a wrong
sk_uid to the `struct sock` in input.
On default configuration, the type confused field overlaps with the
high 4 bytes of `struct tun_struct __rcu *tun` of `struct tun_file`,
NULL at the time of call, which makes the uid of all tun sockets 0,
i.e., the root one.
Fix the assignment by using sock_init_data_uid().

Fixes: 86741ec2 ("net: core: Add a UID field to struct sock.")
Signed-off-by: NPietro Borrello <borrello@diag.uniroma1.it>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NBaisong Zhong <zhongbaisong@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc1
commit 584f3742
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6I7UC
CVE: CVE-2023-1076

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

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

Add sock_init_data_uid() to explicitly initialize the socket uid.
To initialise the socket uid, sock_init_data() assumes a the struct
socket* sock is always embedded in a struct socket_alloc, used to
access the corresponding inode uid. This may not be true.
Examples are sockets created in tun_chr_open() and tap_open().

Fixes: 86741ec2 ("net: core: Add a UID field to struct sock.")
Signed-off-by: NPietro Borrello <borrello@diag.uniroma1.it>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Conflicts:
	net/core/sock.c
Signed-off-by: NBaisong Zhong <zhongbaisong@huawei.com>
Reviewed-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc1
commit 8843e06f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6HWOV
CVE: NA

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

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

It seems a data race between ring_buffer writing and integrity check.
That is, RB_FLAG of head_page is been updating, while at same time
RB_FLAG was cleared when doing integrity check rb_check_pages():

  rb_check_pages()            rb_handle_head_page():
  --------                    --------
  rb_head_page_deactivate()
                              rb_head_page_set_normal()
  rb_head_page_activate()

We do intergrity test of the list to check if the list is corrupted and
it is still worth doing it. So, let's refactor rb_check_pages() such that
we no longer clear and set flag during the list sanity checking.

[1] and [2] are the test to reproduce and the crash report respectively.

1:
``` read_trace.sh
  while true;
  do
    # the "trace" file is closed after read
    head -1 /sys/kernel/tracing/trace > /dev/null
  done
```
``` repro.sh
  sysctl -w kernel.panic_on_warn=1
  # function tracer will writing enough data into ring_buffer
  echo function > /sys/kernel/tracing/current_tracer
  ./read_trace.sh &
  ./read_trace.sh &
  ./read_trace.sh &
  ./read_trace.sh &
  ./read_trace.sh &
  ./read_trace.sh &
  ./read_trace.sh &
  ./read_trace.sh &
```

2:
------------[ cut here ]------------
WARNING: CPU: 9 PID: 62 at kernel/trace/ring_buffer.c:2653
rb_move_tail+0x450/0x470
Modules linked in:
CPU: 9 PID: 62 Comm: ksoftirqd/9 Tainted: G        W          6.2.0-rc6+
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:rb_move_tail+0x450/0x470
Code: ff ff 4c 89 c8 f0 4d 0f b1 02 48 89 c2 48 83 e2 fc 49 39 d0 75 24
83 e0 03 83 f8 02 0f 84 e1 fb ff ff 48 8b 57 10 f0 ff 42 08 <0f> 0b 83
f8 02 0f 84 ce fb ff ff e9 db
RSP: 0018:ffffb5564089bd00 EFLAGS: 00000203
RAX: 0000000000000000 RBX: ffff9db385a2bf81 RCX: ffffb5564089bd18
RDX: ffff9db281110100 RSI: 0000000000000fe4 RDI: ffff9db380145400
RBP: ffff9db385a2bf80 R08: ffff9db385a2bfc0 R09: ffff9db385a2bfc2
R10: ffff9db385a6c000 R11: ffff9db385a2bf80 R12: 0000000000000000
R13: 00000000000003e8 R14: ffff9db281110100 R15: ffffffffbb006108
FS:  0000000000000000(0000) GS:ffff9db3bdcc0000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005602323024c8 CR3: 0000000022e0c000 CR4: 00000000000006e0
Call Trace:
 <TASK>
 ring_buffer_lock_reserve+0x136/0x360
 ? __do_softirq+0x287/0x2df
 ? __pfx_rcu_softirq_qs+0x10/0x10
 trace_function+0x21/0x110
 ? __pfx_rcu_softirq_qs+0x10/0x10
 ? __do_softirq+0x287/0x2df
 function_trace_call+0xf6/0x120
 0xffffffffc038f097
 ? rcu_softirq_qs+0x5/0x140
 rcu_softirq_qs+0x5/0x140
 __do_softirq+0x287/0x2df
 run_ksoftirqd+0x2a/0x30
 smpboot_thread_fn+0x188/0x220
 ? __pfx_smpboot_thread_fn+0x10/0x10
 kthread+0xe7/0x110
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2c/0x50
 </TASK>
---[ end trace 0000000000000000 ]---

[ crash report and test reproducer credit goes to Zheng Yejian]

Link: https://lore.kernel.org/linux-trace-kernel/1676376403-16462-1-git-send-email-quic_mojha@quicinc.com

Cc: <mhiramat@kernel.org>
Cc: stable@vger.kernel.org
Fixes: 1039221c ("ring-buffer: Do not disable recording when there is an iterator")
Reported-by: NZheng Yejian <zhengyejian1@huawei.com>
Signed-off-by: NMukesh Ojha <quic_mojha@quicinc.com>
Signed-off-by: NSteven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Reviewed-by: NYang Jihong <yangjihong1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.1-rc1
commit 8237c01f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6GI6F
CVE: NA

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

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

The hctx's run_work may be racing with the elevator switch when
reinitializing hardware queues. The queue is merely frozen in this
context, but that only prevents requests from allocating and doesn't
stop the hctx work from running. The work may get an elevator pointer
that's being torn down, and can result in use-after-free errors and
kernel panics (example below). Use the quiesced elevator switch instead,
and make the previous one static since it is now only used locally.

  nvme nvme0: resetting controller
  nvme nvme0: 32/0/0 default/read/poll queues
  BUG: kernel NULL pointer dereference, address: 0000000000000008
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0
  Oops: 0000 [#1] SMP PTI
  Workqueue: kblockd blk_mq_run_work_fn
  RIP: 0010:kyber_has_work+0x29/0x70

...

  Call Trace:
   __blk_mq_do_dispatch_sched+0x83/0x2b0
   __blk_mq_sched_dispatch_requests+0x12e/0x170
   blk_mq_sched_dispatch_requests+0x30/0x60
   __blk_mq_run_hw_queue+0x2b/0x50
   process_one_work+0x1ef/0x380
   worker_thread+0x2d/0x3e0
Signed-off-by: NKeith Busch <kbusch@kernel.org>
Reviewed-by: NMing Lei <ming.lei@redhat.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20220927155652.3260724-1-kbusch@fb.comSigned-off-by: NJens Axboe <axboe@kernel.dk>

Conflicts:
	block/blk-mq.c
	block/blk.h
Signed-off-by: NYu Kuai <yukuai3@huawei.com>
Reviewed-by: NHou Tao <houtao1@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.163
commit 740c537f52c1f54aff9094744483d1515c7c8b7b
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6GCCV

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

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

commit 672e4268 upstream.

ovl_dentry_revalidate_common() can be called in rcu-walk mode.  As document
said, "in rcu-walk mode, d_parent and d_inode should not be used without
care".

Check inode here to protect access under rcu-walk mode.

Fixes: bccece1e ("ovl: allow remote upper")
Reported-and-tested-by: syzbot+a4055c78774bbf3498bb@syzkaller.appspotmail.com
Signed-off-by: NChen Zhongjin <chenzhongjin@huawei.com>
Cc: <stable@vger.kernel.org> # v5.7
Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Reviewed-by: NZhang Yi <yi.zhang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

Merge Pull Request from: @zhang-zekun-zk 
 
OLK-5.10 backport sharepool and config isolation patches 
 
Link:https://gitee.com/openeuler/kernel/pulls/443 

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

Merge Pull Request from: @zhang-zekun-zk 
 
add drivers to support hbm memory and hbm cache 
 
Link:https://gitee.com/openeuler/kernel/pulls/451 

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

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

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

Add a driver for hbm cache, which support for power on/off the
hbm cache device. Hbm can be used as a cache, for which a normal
memory access can take advantage of the high band width of hbm.
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>

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

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

Provide additional memory device topology information in
hisi_hbmdev. This memory topology informaton can provide
useful information for userspace to select the closest
memory device to a certain cpu.
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>

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

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

Export the state of a hotplug memory device, and driviers
can use this information to manipulate the hotplug memory
device.
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>

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

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

Platform devices which supports power control are often required to be
power off/on together with the devices in the same power domain. However,
there isn't a generic driver that support the power control logic of
these devices.

ACPI container seems to be a good place to hold these control logic. Add
platform devices in the same power domain in a ACPI container, we can
easily get the locality information about these devices and can moniter
the power of these devices in the same power domain together.

This patch provide three userspace control interface to control the power
of devices together in the container:
- state: Echo online to state to power up the devices in the container and
  then online these devices which will be triggered by BIOS. Echo offline
  to the state to offline and eject the child devices in the container
  which are ejectable.
- pxms: show the pxms of devices which are present in the container.

In our scenario, we need to control the power of HBM memory devices which
can be power consuming and will only be used in some specialized scenarios,
such as HPC. HBM memory devices in a socket are in the same power domain,
and should be power off/on together. We have come up with an idea that put
these power control logic in a specialized driver, but ACPI container seems
to be a more generic place to hold these control logic.
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>

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

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

This patch export the symbol of acpi_hotplug_schedule, and
move the declaration of the acpi_hotplug_schedule in
drivers/acpi/internal.h to include/linux/acpi.h. Drivers
can use this function to online/offline the memory devices.
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>

mainline inclusion
from mainline-v6.0-rc1
commit f8128c39
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I67QNJ
CVE: NA

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

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

Some pieces of modular code can benefit from using
acpi_dev_for_each_child(), so export it to modules.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>

mainline inclusion
from mainline-v5.19-rc1
commit 10fa1b2c
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I67QNJ
CVE: NA

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

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

When walking the children of an ACPI device, take extra care to avoid
using to_acpi_device() on the ones that are not ACPI devices, because
that may lead to out-of-bounds access and memory corruption.

While at it, make the function passed to acpi_dev_for_each_child()
take a struct acpi_device pointer argument (instead of a struct device
one), so it is more straightforward to use.

Fixes: b7dd6298 ("ACPI: PM: Introduce acpi_dev_power_up_children_with_adr()")
Reported-by: Nkernel test robot <oliver.sang@intel.com>
BugLink: https://lore.kernel.org/lkml/20220420064725.GB16310@xsang-OptiPlex-9020/Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>

mainline inclusion
from mainline-v5.19-rc
commit cf6ba075
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I67QNJ
CVE: NA

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

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

Introduce a wrapper around device_for_each_child() to iterate over
the children of a given ACPI device object.

This function will be used in subsequent change sets.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>

hulk inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I6D0N5

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

Add static modifier to find_spg_node_by_spg(), for this function is
designed as an internal helper function, should only be used in
share_pool.c scope.
Also add static modifier to spa_overview_show and spg_overview_show.
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>

ascend inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6A3YT

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

Charge buddy hugepage to memcg when kmemcg is disabled. If kmemcg
is enabled, we can also use kmemcg to charge buddy hugepages.
Signed-off-by: NZhou Guanghui <zhouguanghui1@huawei.com>

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

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

delete_spg_node can be use to replace the code snippets as follows:
list_del(&node->proc_node);
spg->proc_num--;
Signed-off-by: NChen Jun <chenjun102@huawei.com>

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

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

Extract group_add_task from duplicate code.
Signed-off-by: NChen Jun <chenjun102@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

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

alloc_size can be obtained by adding alloc_nsize to alloc_hsize,
and size can be obtained by adding alloc_nsize to alloc_hsize and
k2u_size. Therefore, alloc_size and size are redundant
and can be deleted.
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

----------------------------------------------
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

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

Add meminfo_k2u_size and delete duplicate or similar code.
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

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

Add meminfo_alloc_sum_byKB and meminfo_alloc_sum, and
delete duplicate or similar code.
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

----------------------------------------------
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

----------------------------------------------
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

----------------------------------------------
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

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

comm is not memory usage information and
should not be stored in sp_proc_stat.
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

hulk inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I6ET9W

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

The tgid information is also stored in sp_group_master.
Signed-off-by: NXu Qiang <xuqiang36@huawei.com>

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

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

There is a double delete list problem in sp_group_exit
Unable to handle kernel paging request at virtual address
dead000000000108
Call trace:
 sp_group_exit+0x104/0x238
  do_exit+0x188/0xb88
  __arm64_sys_exit+0x24/0x28

Calls to sp_group_exit depends on the value of group_dead, which is
controlled by CLONE_THREAD. If process A clone B with CLONE_VM and
*NO* CLONE_THREAD. A and B will have group_dead = 1 and have the same
mm_struct on exit. So sp_group_exit processes an mm_struct more than
once.

To sovle the problem, we check the tgid in sp_group_exit and allow only
the parent process to continue.

Similar check should be added in mg_sp_group_add/del_task.
Signed-off-by: NWang Wensheng <wangwensheng4@huawei.com>