the sockops call

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I71USM

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

Currently, a permission status code is required to identify
that the access to the sockops is from the delayed link establishment
scenario. Therefore, "BPF_SOCK_OPS_TCP_DEFFER_CONNECT_CB"
Signed-off-by: Nbitcoffee <liuxin350@huawei.com>

 sockets during setopt

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I71USM

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

Currently, the ebpf program can distinguish sockets according to
the address accessed by the client, and use the ULP framework to
modify the matched sockets to delay link establishment.
Signed-off-by: Nbitcoffee <liuxin350@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I71USM

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

The bpf_defer_connect bit is added for inet_sock to indicate
whether the current socket is changed to the bpf program to
delay link establishment.
Signed-off-by: Nbitcoffee <liuxin350@huawei.com>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I71USM

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

A trace point is added to the connection process. Theebpf program
can be mounted to modify the return value of the function. This is
mandatory for delaying the establishment of an ebpf link. After
the connection is complete, a message is returned immediately and
no unnecessary operation is performed.
Signed-off-by: Nbitcoffee <liuxin350@huawei.com>

Merge Pull Request from: @Hongchen_Zhang 
 
1. Add swiotlb backups buffer
2. Add ARCH_HAS_SETUP_DMA_OPS and DMA_OPS
3. pci: irq: Add early_param pci_irq_limit to limit pci irq numbers 
 
Link:https://gitee.com/openeuler/kernel/pulls/897 

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

Merge Pull Request from: @Hongchen_Zhang 
 
1) Referring to other architectures to enable a large number of
configurations.
2) change CONFIG_NR_CPUS to 256
3) change ipmi driver related configs to y
4) change CONFIG_FRAME_WARN to 4096
 
 
Link:https://gitee.com/openeuler/kernel/pulls/869 

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

Merge Pull Request from: @ci-robot 
 
PR sync from:  Zhihao Cheng <chengzhihao1@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/LVVMWDDI7DASB3DYASLNKKPERIERFPSU/ 
Zhang Yi (2):
  jbd2: recheck chechpointing non-dirty buffer
  jbd2: remove t_checkpoint_io_list


-- 
2.31.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/922 

Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

Merge Pull Request from: @xiao_jiang_shui 
 
* crypto: hisilicon/qm - remove unnecessary aer.h include
* crypto: hisilicon/qm - prevent soft lockup in qm_poll_req_cb()'s loop
* crypto: hisilicon/hpre - ensure private key less than n
* crypto: hisilicon/qm - stop function and write data to memory

issue: https://gitee.com/openeuler/kernel/issues/I7AUVE 
 
Link:https://gitee.com/openeuler/kernel/pulls/918 

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

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

Reference: https://lore.kernel.org/linux-ext4/20230531115100.2779605-1-yi.zhang@huaweicloud.com/T/#t

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

Since t_checkpoint_io_list was stop using in jbd2_log_do_checkpoint()
now, it's time to remove the whole t_checkpoint_io_list logic.
Signed-off-by: NZhang Yi <yi.zhang@huawei.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Conflits:
	include/linux/jbd2.h
	[ Don't remove t_checkpoint_io_list for KABI broken. ]
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>

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

Reference: https://lore.kernel.org/linux-ext4/20230531115100.2779605-1-yi.zhang@huaweicloud.com/T/#t

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

There is a long-standing metadata corruption issue that happens from
time to time, but it's very difficult to reproduce and analyse, benefit
from the JBD2_CYCLE_RECORD option, we found out that the problem is the
checkpointing process miss to write out some buffers which are raced by
another do_get_write_access(). Looks below for detail.

jbd2_log_do_checkpoint() //transaction X
 //buffer A is dirty and not belones to any transaction
 __buffer_relink_io() //move it to the IO list
 __flush_batch()
  write_dirty_buffer()
                             do_get_write_access()
                             clear_buffer_dirty
                             __jbd2_journal_file_buffer()
                             //add buffer A to a new transaction Y
   lock_buffer(bh)
   //doesn't write out
 __jbd2_journal_remove_checkpoint()
 //finish checkpoint except buffer A
 //filesystem corrupt if the new transaction Y isn't fully write out.

Due to the t_checkpoint_list walking loop in jbd2_log_do_checkpoint()
have already handles waiting for buffers under IO and re-added new
transaction to complete commit, and it also removing cleaned buffers,
this makes sure the list will eventually get empty. So it's fine to
leave buffers on the t_checkpoint_list while flushing out and completely
stop using the t_checkpoint_io_list.

Cc: stable@vger.kernel.org
Suggested-by: NJan Kara <jack@suse.cz>
Signed-off-by: NZhang Yi <yi.zhang@huawei.com>
Tested-by: NZhihao Cheng <chengzhihao1@huawei.com>
Reviewed-by: NJan Kara <jack@suse.cz>
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from:  Baokun Li <libaokun1@huawei.com>
 https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/TMNW5KJPDRL5VBVVST3Y343U5DVD4WWG/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/919 

Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> 
Reviewed-by: Jialin Zhang <zhangjialin11@huawei.com> 
Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> 

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7AUVE
CVE: NA

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

<linux/aer.h> is unused, so remove it.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: Weili Qian <qianweili@huawei.com>
Cc: Zhou Wang <wangzhou1@hisilicon.com>
Acked-by: NLongfang Liu <liulongfang@huawei.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7AUVE
CVE: NA

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

Before the system is shutdown, the accelerator driver
needs to stop the device and write data to the memory.
This prevents the accelerator from accessing addresses
and writing data to the memory after the memory is reclaimed
by the system, causing device exceptions and generating NFE errors.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7AUVE
CVE: NA

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

The private key of the curve key size generated by stdrng, which may not be
less than n. So the private key with the curve key size minus 1 is
generated to ensure that the private key is less than n.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>

driver inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7AUVE
CVE: NA

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

The function qm_poll_req_cb() may take a while due to complex req_cb,
so soft lockup may occur in kernel with preemption disabled.
Add a cond_resched() to prevent that.
Signed-off-by: NWeili Qian <qianweili@huawei.com>
Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>

hulk inclusion
category: perf
bugzilla: 188836, https://gitee.com/openeuler/kernel/issues/I7AYNZ

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

This reverts commit 5193a88e.
This commit may cause performance degradation, so it is being reverted
temporarily.
Signed-off-by: NBaokun Li <libaokun1@huawei.com>

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I79V61

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

1) Referring to other architectures to enable a large number of
   configurations.
2) change CONFIG_NR_CPUS to 256
3) change ipmi driver related configs to y
4) change CONFIG_FRAME_WARN to 4096
Signed-off-by: NYingkun Meng <mengyingkun@loongson.cn>
Signed-off-by: NJuxin Gao <gaojuxin@loongson.cn>
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>

Merge Pull Request from: @Hongchen_Zhang 
 
kdump function test failed on 3C5000+7A2000 dual-bridge machine,
we fix it as following:
reserve high memory for the capture kernel to avoid kdump operation
failure on 3C5000 machines with old firmware.

after apply this patch,the following test case passed:
1) add crashkernel=512M in commandline 
2) systemctl start kdump
3) echo c >/proc/sysrq-trigger
4) after reboot, vmcore file created in /var/crash directory
 
 
Link:https://gitee.com/openeuler/kernel/pulls/880 

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

Merge Pull Request from: @Hongchen_Zhang 
 
after commit 0cba0556 ("cpumask: introduce for_each_cpu_or")
LoongArch code can not compile,the reason is __ffs is not found,
change the bitops.h include order to make it fine. 
 
Link:https://gitee.com/openeuler/kernel/pulls/868 

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

Merge Pull Request from: @Hongchen_Zhang 
 
Add ls2k500 bmc support:
- add ls2k500sfb driver for ls2k500 bmc
- add ls2k500 bmc ipmi support
- enable CONFIG_FB_LS2K500 by default 
 
Link:https://gitee.com/openeuler/kernel/pulls/792 

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

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I7AHL9

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

Change-Id: I1b627be7ca7bd3690a175b3334c088e445278504
Signed-off-by: NJuxin Gao <gaojuxin@loongson.cn>
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>

Merge Pull Request from: @ci-robot 
 
PR sync from: Lu Wei luwei32@huawei.com https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/P2VNBKLIL5YGSGNPIHF44HRLVST76J4E/ 
 
Link:https://gitee.com/openeuler/kernel/pulls/906 

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

Merge Pull Request from: @ci-robot 
 
PR sync from: Liu Jian liujian56@huawei.com https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/BSVWS6P3YEQUKJMVM2L3BMIPHWVKODOD/ 
 
Link:https://gitee.com/openeuler/kernel/pulls/907 

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

Merge Pull Request from: @svishen 
 
This pull Requests fix pointer cast for wol and fix getting GE port lanes error and set cpu affinity

issue:
https://gitee.com/openeuler/kernel/issues/I7A712 
 
Link:https://gitee.com/openeuler/kernel/pulls/874 

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

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

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

Commit 07f4c900 ("tcp/dccp: try to not exhaust ip_local_port_range
in connect()") allocates even ports for connect() first while leaving
odd ports for bind() and this works well in busy servers.

But this strategy causes severe performance degradation in busy clients.
when a client has used more than half of the local ports setted in
proc/sys/net/ipv4/ip_local_port_range, if this client trys to connect
to a server again, the connect time increases rapidly since it will
traverse all the even ports though they are exhausted.

So this path provides another strategy by introducing a system option:
local_port_allocation. If it is a busy client, users should set it to 1
to use sequential allocation while it should be set to 0 in other
situations. Its default value is 0.
Signed-off-by: NLu Wei <luwei32@huawei.com>
Signed-off-by: NLiu Jian <liujian56@huawei.com>

stable inclusion
from stable-v5.10.173
commit da26369377f0b671c14692e2d65ceb38131053e1
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6GT9T

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

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

[ Upstream commit 4cc59f38 ]

In function rt6_nlmsg_size(), the length of nexthop is calculated
by multipling the nexthop length of fib6_info and the number of
siblings. However if the fib6_info has no lwtunnel but the siblings
have lwtunnels, the nexthop length is less than it should be, and
it will trigger a warning in inet6_rt_notify() as follows:

WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130
......
Call Trace:
 <TASK>
 fib6_add_rt2node+0x685/0xa30
 fib6_add+0x96/0x1b0
 ip6_route_add+0x50/0xd0
 inet6_rtm_newroute+0x97/0xa0
 rtnetlink_rcv_msg+0x156/0x3d0
 netlink_rcv_skb+0x5a/0x110
 netlink_unicast+0x246/0x350
 netlink_sendmsg+0x250/0x4c0
 sock_sendmsg+0x66/0x70
 ___sys_sendmsg+0x7c/0xd0
 __sys_sendmsg+0x5d/0xb0
 do_syscall_64+0x3f/0x90
 entry_SYSCALL_64_after_hwframe+0x72/0xdc

This bug can be reproduced by script:

ip -6 addr add 2002::2/64 dev ens2
ip -6 route add 100::/64 via 2002::1 dev ens2 metric 100

for i in 10 20 30 40 50 60 70;
do
	ip link add link ens2 name ipv_$i type ipvlan
	ip -6 addr add 2002::$i/64 dev ipv_$i
	ifconfig ipv_$i up
done

for i in 10 20 30 40 50 60;
do
	ip -6 route append 100::/64 encap ip6 dst 2002::$i via 2002::1
dev ipv_$i metric 100
done

ip -6 route append 100::/64 via 2002::1 dev ipv_70 metric 100

This patch fixes it by adding nexthop_len of every siblings using
rt6_nh_nlmsg_size().

Fixes: beb1afac ("net: ipv6: Add support to dump multipath routes via RTA_MULTIPATH attribute")
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NDavid Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20230222083629.335683-2-luwei32@huawei.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLu Wei <luwei32@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/thread/RD4XA3AJYG55M6DKC5CSK5O2Z4JJWDPF/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/890 

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

Merge Pull Request from: @ci-robot 
 
PR sync from: Liu Jian liujian56@huawei.com https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/thread/H22NWZPMQBGSVUV22ISL3FTVOXQH676J/ 
 
Link:https://gitee.com/openeuler/kernel/pulls/895 

Reviewed-by: Liu Chao <liuchao173@huawei.com> 
Signed-off-by: Liu Chao <liuchao173@huawei.com> 

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I76XQZ

--------------------------------
Signed-off-by: NChong Qiao <qiaochong@loongson.cn>
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>

Merge Pull Request from: @xiao_jiang_shui 
 
1、The accelerator queue parameter configuration is incorrect.
2、uacce: use filep->f_mapping to replace inode->i_mapping

issue: https://gitee.com/openeuler/kernel/issues/I79JRM
 
 
Link:https://gitee.com/openeuler/kernel/pulls/894 

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

LoongArch inclusion
category: feature
buzilla: https://gitee.com/openeuler/kernel/issues/I7AHL9

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

Change-Id: I261edb4bda7b9f472cd5dbfae17015de362cfcba
Signed-off-by: NJuxin Gao <gaojuxin@loongson.cn>
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>

LoongArch inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I7AHL9

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

Change-Id: Idce5400a65352d38f08d11548dfa43280cb71d03
Signed-off-by: NJuxin Gao <gaojuxin@loongson.cn>
Signed-off-by: NHongchen Zhang <zhanghongchen@loongson.cn>

hulk inclusion
category: feature
bugzilla: https://gitee.com/openeuler/kernel/issues/I79J3X
CVE: N/A

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

It is already enabled by default on the x86 and loongarch platforms, so
let's enable it on the arm64 platform.
Signed-off-by: NLiu Jian <liujian56@huawei.com>
Reviewed-by: NWei Yongjun <weiyongjun1@huawe.com>

mainline inclusion
from mainline-v5.16-rc3
commit 0276af21
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7A2A0
CVE: NA

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

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

ethtool_set_coalesce() now uses both the .get_coalesce() and
.set_coalesce() callbacks. But the check for their availability is
buggy, so changing the coalesce settings on a device where the driver
provides only _one_ of the callbacks results in a NULL pointer
dereference instead of an -EOPNOTSUPP.

Fix the condition so that the availability of both callbacks is
ensured. This also matches the netlink code.

Note that reproducing this requires some effort - it only affects the
legacy ioctl path, and needs a specific combination of driver options:
- have .get_coalesce() and .coalesce_supported but no
 .set_coalesce(), or
- have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn't
  cause the crash as it first attempts to call ethtool_get_coalesce()
  and bails out on error.

Fixes: f3ccfda1 ("ethtool: extend coalesce setting uAPI with CQE mode")
Cc: Yufeng Mo <moyufeng@huawei.com>
Cc: Huazhong Tan <tanhuazhong@huawei.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NJulian Wiedmann <jwi@linux.ibm.com>
Link: https://lore.kernel.org/r/20211126175543.28000-1-jwi@linux.ibm.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>
Signed-off-by: NZhengchao Shao <shaozhengchao@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/thread/XWHRWDMB4P3YRCQBLQMFWCV4DDLKNDHE/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/886 

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

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

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

The inode can be different in a container, for example, a docker and host
both open the same uacce parent device, which uses the same uacce struct
but different inode, so uacce->inode is not enough.

What's worse, when docker stopped, the inode will be destroyed as well,
causing use-after-free in uacce_remove.

So use q->filep->f_mapping to replace uacce->inode->i_mapping.
Signed-off-by: NZhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>

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

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

After the queue isolation function is enabled in the BIOS.
If the current default number of queues is used to enable PF,
the default number of queues will be greater than the number of
queues supported by the function set in the BIOS, which will cause
the driver to fail to load.
After modification. If queue isolation is enabled. When the default
queue parameter is larger than the number supported by the function.
The number of enabled queues will be changed to the number supported
by the function.
So that the driver can be loaded normally.
Signed-off-by: NLongfang Liu <liulongfang@huawei.com>
Signed-off-by: NJiangShui Yang <yangjiangshui@h-partners.com>

Merge Pull Request from: @yanan-wang 
 
Currently, the bitfield of HWCAP2_WFXT is (1 << 23) inconsistent with mainline set (1UL << 31).
To avoid possible uapi break, keep the bitfield consistent with mainline. 
 
Link:https://gitee.com/openeuler/kernel/pulls/881 

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

mainline inclusion
from mainline-v5.19-rc1
commit b2c4caf3
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I78WD0

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

Currently, the bitfield of HWCAP2_WFXT is (1 << 23)
inconsistent with mainline set (1UL << 31). To avoid
possible uapi break, keep the bitfield consistent
with mainline.
Signed-off-by: NYanan Wang <wangyanan55@huawei.com>

mainline inclusion
from mainline-v6.4-rc5
commit 36eec020
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I79V6E
CVE: NA

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

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

When use the following command to test:
1)ip link add bond0 type bond
2)ip link set bond0 up
3)tc qdisc add dev bond0 root handle ffff: mq
4)tc qdisc replace dev bond0 parent ffff:fff1 handle ffff: mq

The kernel reports NULL pointer dereference issue. The stack information
is as follows:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
Internal error: Oops: 0000000096000006 [#1] SMP
Modules linked in:
pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mq_attach+0x44/0xa0
lr : qdisc_graft+0x20c/0x5cc
sp : ffff80000e2236a0
x29: ffff80000e2236a0 x28: ffff0000c0e59d80 x27: ffff0000c0be19c0
x26: ffff0000cae3e800 x25: 0000000000000010 x24: 00000000fffffff1
x23: 0000000000000000 x22: ffff0000cae3e800 x21: ffff0000c9df4000
x20: ffff0000c9df4000 x19: 0000000000000000 x18: ffff80000a934000
x17: ffff8000f5b56000 x16: ffff80000bb08000 x15: 0000000000000000
x14: 0000000000000000 x13: 6b6b6b6b6b6b6b6b x12: 6b6b6b6b00000001
x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
x8 : ffff0000c0be0730 x7 : bbbbbbbbbbbbbbbb x6 : 0000000000000008
x5 : ffff0000cae3e864 x4 : 0000000000000000 x3 : 0000000000000001
x2 : 0000000000000001 x1 : ffff8000090bc23c x0 : 0000000000000000
Call trace:
mq_attach+0x44/0xa0
qdisc_graft+0x20c/0x5cc
tc_modify_qdisc+0x1c4/0x664
rtnetlink_rcv_msg+0x354/0x440
netlink_rcv_skb+0x64/0x144
rtnetlink_rcv+0x28/0x34
netlink_unicast+0x1e8/0x2a4
netlink_sendmsg+0x308/0x4a0
sock_sendmsg+0x64/0xac
____sys_sendmsg+0x29c/0x358
___sys_sendmsg+0x90/0xd0
__sys_sendmsg+0x7c/0xd0
__arm64_sys_sendmsg+0x2c/0x38
invoke_syscall+0x54/0x114
el0_svc_common.constprop.1+0x90/0x174
do_el0_svc+0x3c/0xb0
el0_svc+0x24/0xec
el0t_64_sync_handler+0x90/0xb4
el0t_64_sync+0x174/0x178

This is because when mq is added for the first time, qdiscs in mq is set
to NULL in mq_attach(). Therefore, when replacing mq after adding mq, we
need to initialize qdiscs in the mq before continuing to graft. Otherwise,
it will couse NULL pointer dereference issue in mq_attach(). And the same
issue will occur in the attach functions of mqprio, taprio and htb.
ffff:fff1 means that the repalce qdisc is ingress. Ingress does not allow
any qdisc to be attached. Therefore, ffff:fff1 is incorrectly used, and
the command should be dropped.

Fixes: 6ec1c69a ("net_sched: add classful multiqueue dummy scheduler")
Signed-off-by: NZhengchao Shao <shaozhengchao@huawei.com>
Tested-by: NPeilin Ye <peilin.ye@bytedance.com>
Acked-by: NJamal Hadi Salim <jhs@mojatatu.com>
Link: https://lore.kernel.org/r/20230527093747.3583502-1-shaozhengchao@huawei.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>