Merge Pull Request from: @zhangjialin11 
 
Backport 5.10.150 LTS patches from upstream.

Conflicts:

Already merged(19):
f039b43cbaea inet: fully convert sk->sk_rx_dst to RCU rules
45c33966759e mm: hugetlb: fix UAF in hugetlb_handle_userfault
c378c479c517 io_uring/af_unix: defer registered files gc to io_uring release
67cbc8865a66 io_uring: correct pinned_vm accounting
904f881b5736 arm64: topology: fix possible overflow in amu_fie_setup()
dbcca76435a6 HID: roccat: Fix use-after-free in roccat_read()
484400d433ca r8152: Rate limit overflow messages
d88b88514ef2 crypto: hisilicon/zip - fix mismatch in get/set sgl_sge_nr
657de36c72f5 arm64: ftrace: fix module PLTs with mcount
29f50bcf0f8b net: mvpp2: fix mvpp2 debugfs leak
6cc0e2afc6a1 bnx2x: fix potential memory leak in bnx2x_tpa_stop()
2a1d03632085 mISDN: fix use-after-free bugs in l1oip timer handlers
0cf6c09dafee ring-buffer: Fix race between reset page and reading page
fbb0e601bd51 ext4: ext4_read_bh_lock() should submit IO if the buffer isn't uptodate
483831ad0440 ext4: fix check for block being out of directory size
f34ab9516276 ext4: fix null-ptr-deref in ext4_write_info
e50472949604 fbdev: smscufx: Fix use-after-free in ufx_ops_open()
7d551b7d6114 block: fix inflight statistics of part0
6b7ae4a904a4 quota: Check next/prev free block number after reading from quota file

Context conflict(1):
c13d0d2f5a48 usb: host: xhci-plat: suspend and resume clocks

Total patches: 389 - 19 = 370 
 
Link:https://gitee.com/openeuler/kernel/pulls/592 

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

Merge Pull Request from: @xia-bing1 
 
We use init_reg_v3_hw() to set some registers, for the latest HBA devices,
    some of these HW registers are set through firmware. Therefore, different
    HBA models are distinguished through pci_dev->revision. 
 
Link:https://gitee.com/openeuler/kernel/pulls/644 

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

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

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

We use init_reg_v3_hw() to set some registers, for the latest HBA devices,
some of these HW registers are set through firmware. Therefore, different
HBA models are distinguished through pci_dev->revision.
Signed-off-by: NYihang Li <liyihang9@huawei.com>
Reviewed-by: NXiang Chen <chenxiang66@hisilicon.com>
Signed-off-by: Nxiabing <xiabing12@h-partners.com>

Merge Pull Request from: @did-you-collect-the-wool-today 
 
virt inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6LQMC
CVE: NA

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

In commit 6f5013f4, the 'vdev->num_regions' was deleted by mistake.

Fixes: 6f5013f4 (Revert "vfio/pci: Add framework for custom interrupt indices")
Signed-off-by: Kunkun Jiang <jiangkunkun@huawei.com> 
 
Link:https://gitee.com/openeuler/kernel/pulls/630 

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

Merge Pull Request from: @stinft 
 
1. #I6Z4E9 
2. #I6ZACP 
3. #I6ZAIM 
4. #I6ZBLL 
 
Link:https://gitee.com/openeuler/kernel/pulls/639 

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

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

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

When the compatibility flag is interacted, the kernel space does
not confirm whether the user space has issued the flag but
responds directly, which will cause the flag to be received in
any scenario in the user space, and the current patch adds this
judgment.

Fixes: b3b7a525 ("RDMA/hns: Support cqe inline in user space")
Fixes: d67087cc ("RDMA/hns: Remove enable rq inline in kernel and add compatibility handling")
Signed-off-by: NLuoyouming <luoyouming@huawei.com>

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

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

In the community version, the rq inline bit is set to 2.
This patch is used for synchronization.

Fixes: d67087cc ("RDMA/hns: Remove enable rq inline in kernel and add compatibility handling")
Signed-off-by: NLuoyouming <luoyouming@huawei.com>

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

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

RoCE Bonding supports up to 4 slaves in a bond group, but
currently there are no such constraint in the driver. This patch
fixes it.

Fixes: 6ba084e0 ("RDMA/hns: add constraints for bonding-unsupported situations")
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

Support dispatching IB event for RoCE bonding. After setting bond,
IB_EVENT_PORT_ERR is dispatched in the following situation:
	1. bond0 becomes link down;
	2. all slaves become link down (as it will lead to a link-down
           of the upper device).

IB_EVENT_PORT_ACTIVE is dispatched in the following situation:
	1. bond0 becomes link up;
	2. one slave becomes link up when all slaves were link down (as
           it will lead to a link-up of the upper device).
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

For RoCE bonding, the IB port state should depend on the link
status of upper device. When the upper device is link up, the
IB port state should be IB_PORT_ATIVE; otherwise, the state
should be IB_PORT_DOWN.

Particularly, when all slaves are link down, the upper device will become
link down automatically, and when at least one slave become link up, the
upper device will become link up. In these situations the IB port will
also change accordingly.
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

Currently, when a change-lowerstate event occurs, the bonding driver
gets the slave's port state from the event notifier and stores it in
the bond_grp struct. Whenever the state needs to be configured to HW
or is queried, the driver reads from bond_grp.

But actually, the state read in this way is not real-time data, as there
is always a delay before the newly changed state is stored. So it is
uneccessary and also inaccurate to store the state. Whenever the state
is needed, just read it from kernel in real time.
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

When changeupper event happens involving bond group with more than 2
slaves, the counting of slave num is incorrect for the reason that there
are no corresponding hr_dev for uninited slaves, which leads to the
failure in adding 3 or more slaves to a bond group.

Applying this patch, the counting begins from the previous value but not
0, and updates slave_map and slave_map_diff depending on whether slave
num increases or decreases. Besides, since bond_grp->slave_num is no
longer used, remove it.

Fixes: e62a2027 ("RDMA/hns: support RoCE bonding")
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

When the third slave is going to be added to a bond group, a
ChangeLowerState event happens firstly and notifies the driver
to queue a ChangeState mission. However, the hr_dev of the third
slave and bond group will both be notified and queue a repetitive
mission separately. As the mission is triggered twice, there will
be also repetitive mission printing, which is misleading and
incorrect.

Applying this patch, only the hr_dev of the bond group will queue and
trigger the mission.

Fixes: e62a2027 ("RDMA/hns: support RoCE bonding")
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

The "record" in "hns_roce_bond_info_record()" is not accurate.
Change the name to "hns_roce_bond_info_update()".
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

Currently, a RoCE bond device cannot be recovered to a bond
device after reset.

Applying this patch, RoCE bonding device 'hns_bond_xx' can be recovered
after reset, including the following changes:
   1. modify the condition for juding whether bond_grp is active, as the
      bond_grp may be also holding HNS_ROCE_CHANGE_BOND during reset init.
      Thus, as long as the bond_grp's state is not
      HNS_ROCE_BOND_NOT_BONDED, it should be considered active.
   2. update the link status of slave in bond_grp from NIC bonding driver
      right before sending command to firmware, as RoCE driver is uninited
      for a while in reset process, and during this period bond_grp cannot
      update the information.
   3. After the reset, re-config the bond_grp information to firmware,
      as the firmware is also reset and the previous configuration is
      cleared.
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

Currently, the driver will count the number of slave hr_dev,
but during bond clearing event and slave decreasing event, only
one slave has a corresponding hr_dev, and the number will always
be 1. It causes that all slave decrease events are redirected to
a bond clearing operation.

This patch fixes this problem by counting slave netdev directly instead
of getting its hr_dev during bond clearing event and slave decreasing
event.

Fixes: 646b97db ("RDMA/hns: adjust the structure of RoCE bonding driver")
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

In the slave list of bond_grp, the first slave is always the main_hr_dev,
and the main_hr_dev is responsible for bonding netdev event handling. If
the main_hr_dev is uninit too early, some CHANGELOWERSTATE events may be
missed before the main_hr_dev is re-register, which may cause the HW is
configured with an outdated slave state.

This patch reverses the order of uniniting slave hr_dev to ensure
main_hr_dev is the last one being uninited.

Fixes: e62a2027 ("RDMA/hns: support RoCE bonding")
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

Currently, bond group resource is always associated to a main_hr_dev
whether bond device has been set or not. When setting bond, all slaves,
including the main_hr_dev, will be uninited. Normally, during main_hr_dev
uninit, the bond group resource is also released. However, the bond group
resource should not be released in the case of setting bond.

To avoid releasing bond group resource when setting bond, the code logic
is like:
    1. uninit a not-main_hr_dev slave
    2. register bond device, with the slave in step 1 becoming the new
       main_hr_dev
    3. uninit the original main_hr_dev.
In step 3, the slave is not current main_hr_dev any more, so during its
uninit, bond group resource will not be released. But in general, the
logic is not simple enough to understand.

This patch adds an argument 'bond_cleanup' to
__hns_roce_hw_v2_uninit_instance() in order to indicate whether bond
group resources should be released during RoCE driver uninit. During
driver uninit when setting bond or clearing bond, 'bond_cleanup' is false;
when RoCE driver kernel object is being removed , 'bond_cleanup' is true.

With this change and the previous patch, bonding operations including
bond setting, bond clearing and decreasing slave do not have to concern
about avoiding releasing bond_grp when uniniting hr_dev. The uninit
order is simplified to a more intuitive one: simply uninit all slaves and
then register the bond device.
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

Currently, bond_grp is attached to only one hr_dev corresponding to a
slave in RoCE bonding, which is called main_hr_dev in the driver. When
a non-main_hr_dev try to obtain its bond_grp, the driver has to find
the main_hr_dev, and then obtain the bond_grp, which leads to a
complicated code.

Applying this patch, bond_grp is removed from struct hns_roce_dev. hr_dev
can obtain bond_grp by XArray, where die_info and bond_grp are stored
according to bus number. With this change, hr_dev can get its bond_grp
directly without depending on main_hr_dev, and the code logic can be
simplified.
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

This patch assigns initial value when variable is defined in
HNS RoCE Bonding driver, instead of doing so on a new line.
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

In hns_roce_slave_dec(), bond_state will be changed to
HNS_ROCE_BOND_REGISTERING right before the current main_hr_dev
is being removed from bond group. When the slave decrease
operation is over, bond_state will be changed to
HNS_ROCE_BOND_IS_BONDED in the end of this function. So the
assignment to bond_state in the beginning of the function is
useless and should be deleted.
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

This patch provides the ability to map an integer ID to a bond
group pointer by:
	1. adding a new struct hns_roce_die_info to store the
	   pointers and IDs of bond groups on a specific I/O die.
	2. applying XArray to map the bus number to the die info struct.
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

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

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

Currently, bond_work, the struct of delayed work for RoCE bonding,
is attached to hns_roce_dev. During setting bond, hns_roce_dev
will be uninited and the pending works will be canceled.

This patch moves bond_work from hns_roce_dev to hns_roce_bond_group so
that the pending works can be executed after setting bond rather than
being cancelled.
Signed-off-by: NJunxian Huang <huangjunxian6@hisilicon.com>

Merge Pull Request from: @chenke1978 
 
[Description]
For ROH distributed scenario, EID is allocated by DHCP mode.
Driver needs to convert the origin MAC address to EID format,
and updates the destination MAC, chaddr and client id(if exists)
when transmit DHCP packets. Meantime, the chaddr field should
follow the source mac address, in order to make the dhcp
server reply to the right client. For the payload of
dhcp packet changed, so the checksum of L4 should be
calculated too.

[Testing]
kernel options:
CONFIG_ROH=m
CONFIG_ROH_HNS=m

Test passed with below step:
1. Load the NIC/ROCE/ROH driver normally on the ROH device.
2. Preparing the DHCP Server and DHCP Client applications
3. Enable the DHCP service on the server node.
4. Execute the DHCP client application on the client node.
5. Check the DHCP process and wait until the DHCP IP address
   allocation is complete.
6. The communication is normal based on the new IP address.

    
 
Link:https://gitee.com/openeuler/kernel/pulls/381 

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

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

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

For ROH distributed scenario, EID is allocated by DHCP mode.
Driver needs to convert the origin MAC address to EID format,
and updates the destination MAC, chaddr and client id(if exists)
when transmit DHCP packets. Meantime, the chaddr field should
follow the source mac address, in order to make the dhcp
server reply to the right client. For the payload of
dhcp packet changed, so the checksum of L4 should be
calculated too.
Signed-off-by: NJian Shen <shenjian15@huawei.com>
Signed-off-by: NKe Chen <chenke54@huawei.com>

Merge Pull Request from: @stinft 
 
Support driver gets the num_xrcds and reserved_xrcds from firmware.
#I6WAZI 
 
Link:https://gitee.com/openeuler/kernel/pulls/617 

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

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

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

Support driver gets the num_xrcds and reserved_xrcds from firmware.
Signed-off-by: NLuoyouming <luoyouming@huawei.com>
Signed-off-by: NChengchang Tang <tangchengchang@huawei.com>

Merge Pull Request from: @zhangjialin11 
 
Pull new CVEs:
CVE-2023-1855
CVE-2023-2006
CVE-2023-30772
CVE-2023-1872

net bugfixes from Ziyang Xuan
mm cleanup from Ma Wupeng
timer bugfix from Yu Liao
xfs bugfixes from Guo Xuenan 
 
Link:https://gitee.com/openeuler/kernel/pulls/633 

Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> 
Signed-off-by: Xie XiuQi <xiexiuqi@huawei.com> 

mainline inclusion
from mainline-v6.3
commit c484fcc0
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WNGK
CVE: NA

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

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

When a net device is put administratively up, its 'IFF_UP' flag is set
(if not set already) and a 'NETDEV_UP' notification is emitted, which
causes the 8021q driver to add VLAN ID 0 on the device. The reverse
happens when a net device is put administratively down.

When changing the type of a bond to Ethernet, its 'IFF_UP' flag is
incorrectly cleared, resulting in the kernel skipping the above process
and VLAN ID 0 being leaked [1].

Fix by restoring the flag when changing the type to Ethernet, in a
similar fashion to the restoration of the 'IFF_SLAVE' flag.

The issue can be reproduced using the script in [2], with example out
before and after the fix in [3].

[1]
unreferenced object 0xffff888103479900 (size 256):
  comm "ip", pid 329, jiffies 4294775225 (age 28.561s)
  hex dump (first 32 bytes):
    00 a0 0c 15 81 88 ff ff 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff81a6051a>] kmalloc_trace+0x2a/0xe0
    [<ffffffff8406426c>] vlan_vid_add+0x30c/0x790
    [<ffffffff84068e21>] vlan_device_event+0x1491/0x21a0
    [<ffffffff81440c8e>] notifier_call_chain+0xbe/0x1f0
    [<ffffffff8372383a>] call_netdevice_notifiers_info+0xba/0x150
    [<ffffffff837590f2>] __dev_notify_flags+0x132/0x2e0
    [<ffffffff8375ad9f>] dev_change_flags+0x11f/0x180
    [<ffffffff8379af36>] do_setlink+0xb96/0x4060
    [<ffffffff837adf6a>] __rtnl_newlink+0xc0a/0x18a0
    [<ffffffff837aec6c>] rtnl_newlink+0x6c/0xa0
    [<ffffffff837ac64e>] rtnetlink_rcv_msg+0x43e/0xe00
    [<ffffffff839a99e0>] netlink_rcv_skb+0x170/0x440
    [<ffffffff839a738f>] netlink_unicast+0x53f/0x810
    [<ffffffff839a7fcb>] netlink_sendmsg+0x96b/0xe90
    [<ffffffff8369d12f>] ____sys_sendmsg+0x30f/0xa70
    [<ffffffff836a6d7a>] ___sys_sendmsg+0x13a/0x1e0
unreferenced object 0xffff88810f6a83e0 (size 32):
  comm "ip", pid 329, jiffies 4294775225 (age 28.561s)
  hex dump (first 32 bytes):
    a0 99 47 03 81 88 ff ff a0 99 47 03 81 88 ff ff  ..G.......G.....
    81 00 00 00 01 00 00 00 cc cc cc cc cc cc cc cc  ................
  backtrace:
    [<ffffffff81a6051a>] kmalloc_trace+0x2a/0xe0
    [<ffffffff84064369>] vlan_vid_add+0x409/0x790
    [<ffffffff84068e21>] vlan_device_event+0x1491/0x21a0
    [<ffffffff81440c8e>] notifier_call_chain+0xbe/0x1f0
    [<ffffffff8372383a>] call_netdevice_notifiers_info+0xba/0x150
    [<ffffffff837590f2>] __dev_notify_flags+0x132/0x2e0
    [<ffffffff8375ad9f>] dev_change_flags+0x11f/0x180
    [<ffffffff8379af36>] do_setlink+0xb96/0x4060
    [<ffffffff837adf6a>] __rtnl_newlink+0xc0a/0x18a0
    [<ffffffff837aec6c>] rtnl_newlink+0x6c/0xa0
    [<ffffffff837ac64e>] rtnetlink_rcv_msg+0x43e/0xe00
    [<ffffffff839a99e0>] netlink_rcv_skb+0x170/0x440
    [<ffffffff839a738f>] netlink_unicast+0x53f/0x810
    [<ffffffff839a7fcb>] netlink_sendmsg+0x96b/0xe90
    [<ffffffff8369d12f>] ____sys_sendmsg+0x30f/0xa70
    [<ffffffff836a6d7a>] ___sys_sendmsg+0x13a/0x1e0

[2]
ip link add name t-nlmon type nlmon
ip link add name t-dummy type dummy
ip link add name t-bond type bond mode active-backup

ip link set dev t-bond up
ip link set dev t-nlmon master t-bond
ip link set dev t-nlmon nomaster
ip link show dev t-bond
ip link set dev t-dummy master t-bond
ip link show dev t-bond

ip link del dev t-bond
ip link del dev t-dummy
ip link del dev t-nlmon

[3]
Before:

12: t-bond: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/netlink
12: t-bond: <BROADCAST,MULTICAST,MASTER,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 46:57:39:a4:46:a2 brd ff:ff:ff:ff:ff:ff

After:

12: t-bond: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/netlink
12: t-bond: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 66:48:7b:74:b6:8a brd ff:ff:ff:ff:ff:ff

Fixes: e36b9d16 ("bonding: clean muticast addresses when device changes type")
Fixes: 75c78500 ("bonding: remap muticast addresses without using dev_close() and dev_open()")
Fixes: 9ec7eb60 ("bonding: restore IFF_MASTER/SLAVE flags on bond enslave ether type change")
Reported-by: NMirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Link: https://lore.kernel.org/netdev/78a8a03b-6070-3e6b-5042-f848dab16fb8@alu.unizg.hr/Tested-by: NMirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Signed-off-by: NIdo Schimmel <idosch@nvidia.com>
Acked-by: NJay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc3
commit e667d469
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WNGK
CVE: NA

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

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

syzbot reported a warning[1] where the bond device itself is a slave and
we try to enslave a non-ethernet device as the first slave which fails
but then in the error path when ether_setup() restores the bond device
it also clears all flags. In my previous fix[2] I restored the
IFF_MASTER flag, but I didn't consider the case that the bond device
itself might also be a slave with IFF_SLAVE set, so we need to restore
that flag as well. Use the bond_ether_setup helper which does the right
thing and restores the bond's flags properly.

Steps to reproduce using a nlmon dev:
 $ ip l add nlmon0 type nlmon
 $ ip l add bond1 type bond
 $ ip l add bond2 type bond
 $ ip l set bond1 master bond2
 $ ip l set dev nlmon0 master bond1
 $ ip -d l sh dev bond1
 22: bond1: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000
 (now bond1's IFF_SLAVE flag is gone and we'll hit a warning[3] if we
  try to delete it)

[1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef
[2] commit 7d5cd2ce ("bonding: correctly handle bonding type change on enslave failure")
[3] example warning:
 [   27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address
 [   27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address
 [   32.464639] bond1 (unregistering): Released all slaves
 [   32.464685] ------------[ cut here ]------------
 [   32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780
 [   32.464694] Modules linked in: br_netfilter bridge bonding virtio_net
 [   32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47
 [   32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014
 [   32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780
 [   32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59
 [   32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206
 [   32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000
 [   32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520
 [   32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728
 [   32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140
 [   32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140
 [   32.464723] FS:  00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000
 [   32.464725] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 [   32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0
 [   32.464730] Call Trace:
 [   32.464763]  <TASK>
 [   32.464767]  rtnl_dellink+0x13e/0x380
 [   32.464776]  ? cred_has_capability.isra.0+0x68/0x100
 [   32.464780]  ? __rtnl_unlock+0x33/0x60
 [   32.464783]  ? bpf_lsm_capset+0x10/0x10
 [   32.464786]  ? security_capable+0x36/0x50
 [   32.464790]  rtnetlink_rcv_msg+0x14e/0x3b0
 [   32.464792]  ? _copy_to_iter+0xb1/0x790
 [   32.464796]  ? post_alloc_hook+0xa0/0x160
 [   32.464799]  ? rtnl_calcit.isra.0+0x110/0x110
 [   32.464802]  netlink_rcv_skb+0x50/0xf0
 [   32.464806]  netlink_unicast+0x216/0x340
 [   32.464809]  netlink_sendmsg+0x23f/0x480
 [   32.464812]  sock_sendmsg+0x5e/0x60
 [   32.464815]  ____sys_sendmsg+0x22c/0x270
 [   32.464818]  ? import_iovec+0x17/0x20
 [   32.464821]  ? sendmsg_copy_msghdr+0x59/0x90
 [   32.464823]  ? do_set_pte+0xa0/0xe0
 [   32.464828]  ___sys_sendmsg+0x81/0xc0
 [   32.464832]  ? mod_objcg_state+0xc6/0x300
 [   32.464835]  ? refill_obj_stock+0xa9/0x160
 [   32.464838]  ? memcg_slab_free_hook+0x1a5/0x1f0
 [   32.464842]  __sys_sendmsg+0x49/0x80
 [   32.464847]  do_syscall_64+0x3b/0x90
 [   32.464851]  entry_SYSCALL_64_after_hwframe+0x44/0xae
 [   32.464865] RIP: 0033:0x7f297bf2e5e7
 [   32.464868] Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 89 74 24 10
 [   32.464869] RSP: 002b:00007ffd96c824c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
 [   32.464872] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f297bf2e5e7
 [   32.464874] RDX: 0000000000000000 RSI: 00007ffd96c82540 RDI: 0000000000000003
 [   32.464875] RBP: 00000000640f19de R08: 0000000000000001 R09: 000000000000007c
 [   32.464876] R10: 00007f297bffabe0 R11: 0000000000000246 R12: 0000000000000001
 [   32.464877] R13: 00007ffd96c82d20 R14: 00007ffd96c82610 R15: 000055bfe38a7020
 [   32.464881]  </TASK>
 [   32.464882] ---[ end trace 0000000000000000 ]---

Fixes: 7d5cd2ce ("bonding: correctly handle bonding type change on enslave failure")
Reported-by: syzbot+9dfc3f3348729cc82277@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3efSigned-off-by: NNikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: NMichal Kubiak <michal.kubiak@intel.com>
Acked-by: NJonathan Toppins <jtoppins@redhat.com>
Acked-by: NJay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc3
commit 9ec7eb60
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WNGK
CVE: NA

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

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

Add bond_ether_setup helper which is used to fix ether_setup() calls in the
bonding driver. It takes care of both IFF_MASTER and IFF_SLAVE flags, the
former is always restored and the latter only if it was set.
If the bond enslaves non-ARPHRD_ETHER device (changes its type), then
releases it and enslaves ARPHRD_ETHER device (changes back) then we
use ether_setup() to restore the bond device type but it also resets its
flags and removes IFF_MASTER and IFF_SLAVE[1]. Use the bond_ether_setup
helper to restore both after such transition.

[1] reproduce (nlmon is non-ARPHRD_ETHER):
 $ ip l add nlmon0 type nlmon
 $ ip l add bond2 type bond mode active-backup
 $ ip l set nlmon0 master bond2
 $ ip l set nlmon0 nomaster
 $ ip l add bond1 type bond
 (we use bond1 as ARPHRD_ETHER device to restore bond2's mode)
 $ ip l set bond1 master bond2
 $ ip l sh dev bond2
 37: bond2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether be:d7:c5:40:5b:cc brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 1500
 (notice bond2's IFF_MASTER is missing)

Fixes: e36b9d16 ("bonding: clean muticast addresses when device changes type")
Signed-off-by: NNikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Conflicts:
	drivers/net/bonding/bond_main.c
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v6.3-rc3
commit cb090e64
category: bugfix
bugzilla: 188657, https://gitee.com/src-openeuler/kernel/issues/I6T36A
CVE: CVE-2023-1855

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

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

In xgene_hwmon_probe, &ctx->workq is bound with xgene_hwmon_evt_work.
Then it will be started.

If we remove the driver which will call xgene_hwmon_remove to clean up,
there may be unfinished work.

The possible sequence is as follows:

Fix it by finishing the work before cleanup in xgene_hwmon_remove.

CPU0                  CPU1

                    |xgene_hwmon_evt_work
xgene_hwmon_remove   |
kfifo_free(&ctx->async_msg_fifo);|
                    |
                    |kfifo_out_spinlocked
                    |//use &ctx->async_msg_fifo
Fixes: 2ca492e2 ("hwmon: (xgene) Fix crash when alarm occurs before driver probe")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Link: https://lore.kernel.org/r/20230310084007.1403388-1-zyytlz.wz@163.comSigned-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NZhao Wenhui <zhaowenhui8@huawei.com>
Reviewed-by: Nsongping yu <yusongping@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
Reviewed-by: NZhang Qiao <zhangqiao22@huawei.com>
Reviewed-by: NChen Hui <judy.chenhui@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.157
commit 3535c632e6d16c98f76e615da8dc0cb2750c66cc
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6VK2H
CVE: CVE-2023-2006

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

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

[ Upstream commit 3bcd6c7e ]

After rxrpc_unbundle_conn() has removed a connection from a bundle, it
checks to see if there are any conns with available channels and, if not,
removes and attempts to destroy the bundle.

Whilst it does check after grabbing client_bundles_lock that there are no
connections attached, this races with rxrpc_look_up_bundle() retrieving the
bundle, but not attaching a connection for the connection to be attached
later.

There is therefore a window in which the bundle can get destroyed before we
manage to attach a new connection to it.

Fix this by adding an "active" counter to struct rxrpc_bundle:

 (1) rxrpc_connect_call() obtains an active count by prepping/looking up a
     bundle and ditches it before returning.

 (2) If, during rxrpc_connect_call(), a connection is added to the bundle,
     this obtains an active count, which is held until the connection is
     discarded.

 (3) rxrpc_deactivate_bundle() is created to drop an active count on a
     bundle and destroy it when the active count reaches 0.  The active
     count is checked inside client_bundles_lock() to prevent a race with
     rxrpc_look_up_bundle().

 (4) rxrpc_unbundle_conn() then calls rxrpc_deactivate_bundle().

Fixes: 245500d8 ("rxrpc: Rewrite the client connection manager")
Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-15975
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Tested-by: zdi-disclosures@trendmicro.com
cc: Marc Dionne <marc.dionne@auristor.com>
cc: linux-afs@lists.infradead.org
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Conflicts:
	net/rxrpc/ar-internal.h
	net/rxrpc/conn_client.c
Signed-off-by: NWang Yufen <wangyufen@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

stable inclusion
from stable-v5.10.177
commit 75e2144291e847009fbc0350e10ec588ff96e05a
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6W80A
CVE: CVE-2023-30772

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

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

[ Upstream commit 06615d11 ]

In da9150_charger_probe, &charger->otg_work is bound with
da9150_charger_otg_work. da9150_charger_otg_ncb may be
called to start the work.

If we remove the module which will call da9150_charger_remove
to make cleanup, there may be a unfinished work. The possible
sequence is as follows:

Fix it by canceling the work before cleanup in the da9150_charger_remove

CPU0                  CPUc1

                    |da9150_charger_otg_work
da9150_charger_remove      |
power_supply_unregister  |
device_unregister   |
power_supply_dev_release|
kfree(psy)          |
                    |
                    | 	power_supply_changed(charger->usb);
                    |   //use

Fixes: c1a281e3 ("power: Add support for DA9150 Charger")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NSebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NGuo Mengqi <guomengqi3@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Reviewed-by: NWeilong Chen <chenweilong@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

hulk inclusion
category: cleanup
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WKXZ
CVE: NA

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

The blank space before kB is needed to align the previous memory report
style.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.16-rc4
commit 53e87e3c
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6WCC1
CVE: NA

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

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

When at least one CPU runs in nohz_full mode, a dedicated timekeeper CPU
is guaranteed to stay online and to never stop its tick.

Meanwhile on some rare case, the dedicated timekeeper may be running
with interrupts disabled for a while, such as in stop_machine.

If jiffies stop being updated, a nohz_full CPU may end up endlessly
programming the next tick in the past, taking the last jiffies update
monotonic timestamp as a stale base, resulting in an tick storm.

Here is a scenario where it matters:

0) CPU 0 is the timekeeper and CPU 1 a nohz_full CPU.

1) A stop machine callback is queued to execute somewhere.

2) CPU 0 reaches MULTI_STOP_DISABLE_IRQ while CPU 1 is still in
   MULTI_STOP_PREPARE. Hence CPU 0 can't do its timekeeping duty. CPU 1
   can still take IRQs.

3) CPU 1 receives an IRQ which queues a timer callback one jiffy forward.

4) On IRQ exit, CPU 1 schedules the tick one jiffy forward, taking
   last_jiffies_update as a base. But last_jiffies_update hasn't been
   updated for 2 jiffies since the timekeeper has interrupts disabled.

5) clockevents_program_event(), which relies on ktime_get(), observes
   that the expiration is in the past and therefore programs the min
   delta event on the clock.

6) The tick fires immediately, goto 3)

7) Tick storm, the nohz_full CPU is drown and takes ages to reach
   MULTI_STOP_DISABLE_IRQ, which is the only way out of this situation.

Solve this with unconditionally updating jiffies if the value is stale
on nohz_full IRQ entry. IRQs and other disturbances are expected to be
rare enough on nohz_full for the unconditional call to ktime_get() to
actually matter.
Reported-by: NPaul E. McKenney <paulmck@kernel.org>
Signed-off-by: NFrederic Weisbecker <frederic@kernel.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Tested-by: NPaul E. McKenney <paulmck@kernel.org>
Link: https://lore.kernel.org/r/20211026141055.57358-2-frederic@kernel.org

 Conflicts:
	kernel/softirq.c
Signed-off-by: NYu Liao <liaoyu15@huawei.com>
Reviewed-by: NXiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.18-rc2
commit a54f78de
category: bugfix
bugzilla: 187526,https://gitee.com/openeuler/kernel/issues/I6WKVJ

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

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

The recent patch to improve btree cycle checking caused a regression
when I rebased the in-memory btree branch atop the 5.19 for-next branch,
because in-memory short-pointer btrees do not have AG numbers.  This
produced the following complaint from kmemleak:

unreferenced object 0xffff88803d47dde8 (size 264):
  comm "xfs_io", pid 4889, jiffies 4294906764 (age 24.072s)
  hex dump (first 32 bytes):
    90 4d 0b 0f 80 88 ff ff 00 a0 bd 05 80 88 ff ff  .M..............
    e0 44 3a a0 ff ff ff ff 00 df 08 06 80 88 ff ff  .D:.............
  backtrace:
    [<ffffffffa0388059>] xfbtree_dup_cursor+0x49/0xc0 [xfs]
    [<ffffffffa029887b>] xfs_btree_dup_cursor+0x3b/0x200 [xfs]
    [<ffffffffa029af5d>] __xfs_btree_split+0x6ad/0x820 [xfs]
    [<ffffffffa029b130>] xfs_btree_split+0x60/0x110 [xfs]
    [<ffffffffa029f6da>] xfs_btree_make_block_unfull+0x19a/0x1f0 [xfs]
    [<ffffffffa029fada>] xfs_btree_insrec+0x3aa/0x810 [xfs]
    [<ffffffffa029fff3>] xfs_btree_insert+0xb3/0x240 [xfs]
    [<ffffffffa02cb729>] xfs_rmap_insert+0x99/0x200 [xfs]
    [<ffffffffa02cf142>] xfs_rmap_map_shared+0x192/0x5f0 [xfs]
    [<ffffffffa02cf60b>] xfs_rmap_map_raw+0x6b/0x90 [xfs]
    [<ffffffffa0384a85>] xrep_rmap_stash+0xd5/0x1d0 [xfs]
    [<ffffffffa0384dc0>] xrep_rmap_visit_bmbt+0xa0/0xf0 [xfs]
    [<ffffffffa0384fb6>] xrep_rmap_scan_iext+0x56/0xa0 [xfs]
    [<ffffffffa03850d8>] xrep_rmap_scan_ifork+0xd8/0x160 [xfs]
    [<ffffffffa0385195>] xrep_rmap_scan_inode+0x35/0x80 [xfs]
    [<ffffffffa03852ee>] xrep_rmap_find_rmaps+0x10e/0x270 [xfs]

I noticed that xfs_btree_insrec has a bunch of debug code that return
out of the function immediately, without freeing the "new" btree cursor
that can be returned when _make_block_unfull calls xfs_btree_split.  Fix
the error return in this function to free the btree cursor.
Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NDave Chinner <dchinner@redhat.com>
Signed-off-by: NDave Chinner <david@fromorbit.com>
Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.18-rc2
commit 5672225e
category: bugfix
bugzilla: 187526,https://gitee.com/openeuler/kernel/issues/I6WKVJ

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

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

Commit dc04db2a has caused a small aim7 regression, showing a
small increase in CPU usage in __xfs_btree_check_sblock() as a
result of the extra checking.

This is likely due to the endian conversion of the sibling poitners
being unconditional instead of relying on the compiler to endian
convert the NULL pointer at compile time and avoiding the runtime
conversion for this common case.

Rework the checks so that endian conversion of the sibling pointers
is only done if they are not null as the original code did.

.... and these need to be "inline" because the compiler completely
fails to inline them automatically like it should be doing.

$ size fs/xfs/libxfs/xfs_btree.o*
   text	   data	    bss	    dec	    hex	filename
  51874	    240	      0	  52114	   cb92 fs/xfs/libxfs/xfs_btree.o.orig
  51562	    240	      0	  51802	   ca5a fs/xfs/libxfs/xfs_btree.o.inline

Just when you think the tools have advanced sufficiently we don't
have to care about stuff like this anymore, along comes a reminder
that *our tools still suck*.

Fixes: dc04db2a ("xfs: detect self referencing btree sibling pointers")
Reported-by: Nkernel test robot <oliver.sang@intel.com>
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDave Chinner <david@fromorbit.com>
Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.18-rc2
commit dc04db2a
category: bugfix
bugzilla: 187526,https://gitee.com/openeuler/kernel/issues/I6WKVJ

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

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

To catch the obvious graph cycle problem and hence potential endless
looping.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
Signed-off-by: NDave Chinner <david@fromorbit.com>
Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>

mainline inclusion
from mainline-v5.14-rc4
commit 04fcad80
category: bugfix
bugzilla: 187526,https://gitee.com/openeuler/kernel/issues/I6WKVJ

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

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

Introduce a helper function xfs_buf_daddr() to extract the disk
address of the buffer from the struct xfs_buf. This will replace
direct accesses to bp->b_bn and bp->b_maps[0].bm_bn, as well as
the XFS_BUF_ADDR() macro.

This patch introduces the helper function and replaces all uses of
XFS_BUF_ADDR() as this is just a simple sed replacement.
Signed-off-by: NDave Chinner <dchinner@redhat.com>
Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
Reviewed-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
Signed-off-by: NGuo Xuenan <guoxuenan@huawei.com>
Reviewed-by: NYang Erkun <yangerkun@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>