Merge Pull Request from: @liuyonglong86 
 
This patch set fix wrong head when modify the tx feature when sending
packets problem and modify the driver version. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1571 

Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> 
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> 

Merge Pull Request from: @liuyonglong86 
 
This patch set fix some bugs found on hns3 drivers and modify the
driver version. 
 
Link:https://gitee.com/openeuler/kernel/pulls/1570 

Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> 
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> 

driver inclusion
category: other
bugzilla: https://gitee.com/openeuler/kernel/issues/I7OSIE
CVE: NA

----------------------------
Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>

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

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

When modify the tx feature, the hns driver will modify the
maybe_stop_tx() and fill_desc() functions, if the modify happens
during packet sending, will cause the hardware and software
pointers do not match, and the port can not work anymore.

This patch deletes the maybe_stop_tx() and fill_desc() functions
modification when setting tx feature, and use the skb_is_gro()
to determine use tso functions or non-tso functions when packets
sending.

Fixes: 38f616da ("net:hns: Add support of ethtool TSO set option for Hip06 in HNS")
Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>

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

----------------------------
Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>

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

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

Currently, the driver knocks the ring doorbell before updating
the ring->last_to_use in tx flow. if the hardware transmiting
packet and napi poll scheduling are fast enough, it may get
the old ring->last_to_use in drivers' napi poll.
In this case, the driver will think the tx is not completed, and
return directly without clear the flag __QUEUE_STATE_STACK_XOFF,
which may cause tx timeout.

Fixes: 62ef41eb ("net: hns3: optimize the tx clean process")
Signed-off-by: NJian Shen <shenjian15@huawei.com>

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

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

Currently, the HNS3 driver reports the rss hash type
of each packet based on the rss hash tuples set. It
always reports PKT_HASH_TYPE_L4, without checking the
type of current packet. It's incorrect.
Fixes it by reporting it base on the packet type.

Fixes: 232fc64b ("net: hns3: Add HW RSS hash information to RX skb")
Fixes: ea485867 ("net: hns3: handle the BD info on the last BD of the packet")
Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>

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

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

In hclgevf_mbx_handler() and hclgevf_get_mbx_resp() functions,
there is a typical store-store and load-load scenario between
received_resp and additional_info. This patch adds barrier
to fix the problem.
Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>

mainline inclusion
from mainline-v5.16-rc6
commit 27cbf64a
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7OQ7U
CVE: NA

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

Currently, the hns3_remove function firstly uninstall client instance,
and then uninstall acceletion engine device. The netdevice is freed in
client instance uninstall process, but acceletion engine device uninstall
process still use it to trace runtime information. This causes a use after
free problem.

So fixes it by check the instance register state to avoid use after free.

Fixes: d8355240 ("net: hns3: add trace event support for PF/VF mailbox")
Signed-off-by: NJie Wang <wangjie125@huawei.com>
Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>

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

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

The variable reset_fail_cnt has moved into the struct rst_stats,
but in hclge_reset_end_it(), still using the old reset_fail_cnt,
so when reset fail, the reset_fail_cnt is always 0, and will not
call nic_call_event() to notify who cares about this event.

This patch use the correct variable rst_stats.reset_fail_cnt to
fix the problem.

Fixes: bc70c292 ("net: hns3: add some DFX info for reset issue")
Signed-off-by: NYonglong Liu <liuyonglong@huawei.com>

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

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Lu Wei <luwei32@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/6L365ADXKYRWFSYG3HPROXFVPSGHUTTY/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7N3N2 
 
Link:https://gitee.com/openeuler/kernel/pulls/1568 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

mainline inclusion
from mainline-v6.4-rc7
commit 04c55383
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7N3N2
CVE: NA

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

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

In the event of a failure in tcf_change_indev(), u32_set_parms() will
immediately return without decrementing the recently incremented
reference counter.  If this happens enough times, the counter will
rollover and the reference freed, leading to a double free which can be
used to do 'bad things'.

In order to prevent this, move the point of possible failure above the
point where the reference counter is incremented.  Also save any
meaningful return values to be applied to the return data at the
appropriate point in time.

This issue was caught with KASAN.

Fixes: 705c7091 ("net: sched: cls_u32: no need to call tcf_exts_change for newly allocated struct")
Suggested-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NLee Jones <lee@kernel.org>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Acked-by: NJamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

conflict:
	net/sched/cls_u32.c
Signed-off-by: NLu Wei <luwei32@huawei.com>

mainline inclusion
from mainline-v6.4
commit 0323bce598eea038714f941ce2b22541c46d488f
category: bugfix
bugzilla: 189032, https://gitee.com/src-openeuler/kernel/issues/I7N3N3
CVE: CVE-2023-3776

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

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

In the event of a failure in tcf_change_indev(), fw_set_parms() will
immediately return an error after incrementing or decrementing
reference counter in tcf_bind_filter().  If attacker can control
reference counter to zero and make reference freed, leading to
use after free.

In order to prevent this, move the point of possible failure above the
point where the TC_FW_CLASSID is handled.

Fixes: 1da177e4 ("Linux-2.6.12-rc2")
Reported-by: NM A Ramdhan <ramdhan@starlabs.sg>
Signed-off-by: NM A Ramdhan <ramdhan@starlabs.sg>
Acked-by: NJamal Hadi Salim <jhs@mojatatu.com>
Reviewed-by: NPedro Tammela <pctammela@mojatatu.com>
Message-ID: <20230705161530.52003-1-ramdhan@starlabs.sg>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
Conflict:
	net/sched/cls_fw.c
Signed-off-by: Ndongchenchen <dongchenchen2@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Longlong Xia <xialonglong1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/TUVVFQUDMHOOCKGRZ5V2L6BODB3T276K/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7L0Z9 
 
Link:https://gitee.com/openeuler/kernel/pulls/1549 

Reviewed-by: Liu YongQiang <liuyongqiang13@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

stable inclusion
from stable-v5.10.182
commit 2218752325a98861dfb10f59a9b0270d6d4abe21
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7L0Z9
CVE: CVE-2023-21255

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

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

commit bdc1c5fa upstream.

In binder_transaction_buffer_release() the 'failed_at' offset indicates
the number of objects to clean up. However, this function was changed by
commit 44d8047f ("binder: use standard functions to allocate fds"),
to release all the objects in the buffer when 'failed_at' is zero.

This introduced an issue when a transaction buffer is released without
any objects having been processed so far. In this case, 'failed_at' is
indeed zero yet it is misinterpreted as releasing the entire buffer.

This leads to use-after-free errors where nodes are incorrectly freed
and subsequently accessed. Such is the case in the following KASAN
report:

  ==================================================================
  BUG: KASAN: slab-use-after-free in binder_thread_read+0xc40/0x1f30
  Read of size 8 at addr ffff4faf037cfc58 by task poc/474

  CPU: 6 PID: 474 Comm: poc Not tainted 6.3.0-12570-g7df047b3 #5
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   dump_backtrace+0x94/0xec
   show_stack+0x18/0x24
   dump_stack_lvl+0x48/0x60
   print_report+0xf8/0x5b8
   kasan_report+0xb8/0xfc
   __asan_load8+0x9c/0xb8
   binder_thread_read+0xc40/0x1f30
   binder_ioctl+0xd9c/0x1768
   __arm64_sys_ioctl+0xd4/0x118
   invoke_syscall+0x60/0x188
  [...]

  Allocated by task 474:
   kasan_save_stack+0x3c/0x64
   kasan_set_track+0x2c/0x40
   kasan_save_alloc_info+0x24/0x34
   __kasan_kmalloc+0xb8/0xbc
   kmalloc_trace+0x48/0x5c
   binder_new_node+0x3c/0x3a4
   binder_transaction+0x2b58/0x36f0
   binder_thread_write+0x8e0/0x1b78
   binder_ioctl+0x14a0/0x1768
   __arm64_sys_ioctl+0xd4/0x118
   invoke_syscall+0x60/0x188
  [...]

  Freed by task 475:
   kasan_save_stack+0x3c/0x64
   kasan_set_track+0x2c/0x40
   kasan_save_free_info+0x38/0x5c
   __kasan_slab_free+0xe8/0x154
   __kmem_cache_free+0x128/0x2bc
   kfree+0x58/0x70
   binder_dec_node_tmpref+0x178/0x1fc
   binder_transaction_buffer_release+0x430/0x628
   binder_transaction+0x1954/0x36f0
   binder_thread_write+0x8e0/0x1b78
   binder_ioctl+0x14a0/0x1768
   __arm64_sys_ioctl+0xd4/0x118
   invoke_syscall+0x60/0x188
  [...]
  ==================================================================

In order to avoid these issues, let's always calculate the intended
'failed_at' offset beforehand. This is renamed and wrapped in a helper
function to make it clear and convenient.

Fixes: 32e9f56a ("binder: don't detect sender/target during buffer cleanup")
Reported-by: NZi Fan Tan <zifantan@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: NCarlos Llamas <cmllamas@google.com>
Acked-by: NTodd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20230505203020.4101154-1-cmllamas@google.com
[cmllamas: resolve trivial conflict due to missing commit 9864bb48]
Signed-off-by: NCarlos Llamas <cmllamas@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NWang Hai <wanghai38@huawei.com>
Signed-off-by: NLonglong Xia <xialonglong1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Ntong tiangen <tongtiangen@huawei.com>
Reviewed-by: NNanyong Sun <sunnanyong@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>

Merge Pull Request from: @zhangjialin11 
 
https://gitee.com/openeuler/kernel/issues/I7M52S 
 
Link:https://gitee.com/openeuler/kernel/pulls/1534 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Reviewed-by: Wei Li <liwei391@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

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

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

Fix mpam memleak issue found by kmemleak:
unreferenced object 0xffff204000d1d000 (size 128):
  comm "cpuhp/24", pid 132, jiffies 4294896121 (age 146328.256s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 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:
    [<00000000dd76fed3>] __kmalloc+0x478/0x664
    [<00000000e2fa4b32>] mpam_resctrl_setup_domain+0x290/0x5d0
    [<0000000088adc589>] mpam_resctrl_cpu_online+0x14c/0x1d0
    [<00000000b223bfaa>] mpam_cpu_online+0x1c8/0x2e4
    [<000000004438534a>] cpuhp_invoke_callback+0x1f4/0x11b0
    [<0000000049ede841>] cpuhp_thread_fun+0x2b8/0x510
    [<000000000d731c73>] smpboot_thread_fn+0x260/0x5a0
    [<0000000093c61bad>] kthread+0x27c/0x350
    [<00000000379f0572>] ret_from_fork+0x10/0x18

There are two cases causing memleak:
1. When offline all cpus of a domain in mpam_resctrl_cpu_offline(),
we only free domain's space but not the space of ctrl_val array.
2. When allocating ctrl_val array failed in mpam_resctrl_setup_domain(),
the space of ctrl_val array may not be freed.

Fixes: 88371f8b ("arm64/mpam: resctrl: Handle cpuhp and resctrl_dom allocation")
Signed-off-by: NWang ShaoBo <bobo.shaobowang@huawei.com>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
Reviewed-by: Nliaoyu <liaoyu15@huawei.com>
Reviewed-by: NWei Li <liwei391@huawei.com>

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

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

mainline inclusion
from mainline-v6.5-rc2
commit 3e337087c3b5805fe0b8a46ba622a962880b5d64
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7N3MX
CVE: CVE-2023-3611

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

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

Lion says:
-------
In the QFQ scheduler a similar issue to CVE-2023-31436
persists.

Consider the following code in net/sched/sch_qfq.c:

static int qfq_enqueue(struct sk_buff *skb, struct Qdisc *sch,
                struct sk_buff **to_free)
{
     unsigned int len = qdisc_pkt_len(skb), gso_segs;

    // ...

     if (unlikely(cl->agg->lmax < len)) {
         pr_debug("qfq: increasing maxpkt from %u to %u for class %u",
              cl->agg->lmax, len, cl->common.classid);
         err = qfq_change_agg(sch, cl, cl->agg->class_weight, len);
         if (err) {
             cl->qstats.drops++;
             return qdisc_drop(skb, sch, to_free);
         }

    // ...

     }

Similarly to CVE-2023-31436, "lmax" is increased without any bounds
checks according to the packet length "len". Usually this would not
impose a problem because packet sizes are naturally limited.

This is however not the actual packet length, rather the
"qdisc_pkt_len(skb)" which might apply size transformations according to
"struct qdisc_size_table" as created by "qdisc_get_stab()" in
net/sched/sch_api.c if the TCA_STAB option was set when modifying the qdisc.

A user may choose virtually any size using such a table.

As a result the same issue as in CVE-2023-31436 can occur, allowing heap
out-of-bounds read / writes in the kmalloc-8192 cache.
-------

We can create the issue with the following commands:

tc qdisc add dev $DEV root handle 1: stab mtu 2048 tsize 512 mpu 0 \
overhead 999999999 linklayer ethernet qfq
tc class add dev $DEV parent 1: classid 1:1 htb rate 6mbit burst 15k
tc filter add dev $DEV parent 1: matchall classid 1:1
ping -I $DEV 1.1.1.2

This is caused by incorrectly assuming that qdisc_pkt_len() returns a
length within the QFQ_MIN_LMAX < len < QFQ_MAX_LMAX.

Fixes: 462dbc91 ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost")
Reported-by: NLion <nnamrec@gmail.com>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: NPedro Tammela <pctammela@mojatatu.com>
Reviewed-by: NSimon Horman <simon.horman@corigine.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

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

Merge Pull Request from: @leoliu-oc 
 
There are some issues that need to be resolved for Zhaoxin Platform.
So remove Zhaoxin uncore code first.

### Issue
https://gitee.com/openeuler/kernel/issues/I7LXCE

### Test
NA

### Known Issue
NA

### Default config change
NA
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1474 

Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> 
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Cai Xinchen <caixinchen1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/CDXL6ZE3KXTCFMM7YK2X5W3WEV3HTB7G/ 
 
https://gitee.com/src-openeuler/kernel/issues/I635JD 
 
Link:https://gitee.com/openeuler/kernel/pulls/1498 

Reviewed-by: Liu YongQiang <liuyongqiang13@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

stable inclusion
from stable-v4.19.285
commit 7bb9c6e05efcecb15b0354d574efbc36ca321d75
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I635JD
CVE: CVE-2022-45886

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

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

[ Upstream commit 4172385b ]

A race condition may occur between the .disconnect function, which
is called when the device is disconnected, and the dvb_device_open()
function, which is called when the device node is open()ed.
This results in several types of UAFs.

The root cause of this is that you use the dvb_device_open() function,
which does not implement a conditional statement
that checks 'dvbnet->exit'.

So, add 'remove_mutex` to protect 'dvbnet->exit' and use
locked_dvb_net_open() function to check 'dvbnet->exit'.

[mchehab: fix a checkpatch warning]

Link: https://lore.kernel.org/linux-media/20221117045925.14297-3-imv4bel@gmail.comSigned-off-by: NHyunwoo Kim <imv4bel@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NCai Xinchen <caixinchen1@huawei.com>

Merge Pull Request from: @LiuYongQiang0816 
 
two patches from Zheng Yejian 
 
Link:https://gitee.com/openeuler/kernel/pulls/1444 

Reviewed-by: Xu Kuohai <xukuohai@huawei.com> 
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/A46YSUGPFWTYNDQDDIBLVTYQP7CWKM7I/ 
 
https://gitee.com/src-openeuler/kernel/issues/I7ISR1 
 
Link:https://gitee.com/openeuler/kernel/pulls/1469 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

Merge Pull Request from: @ci-robot 
 
PR sync from: Ziyang Xuan <william.xuanziyang@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/DIK47VH6DI376MCBPUDGF7OCT76C4BMQ/ 
 
https://gitee.com/openeuler/kernel/issues/I7M991 
 
Link:https://gitee.com/openeuler/kernel/pulls/1472 

Reviewed-by: Yue Haibing <yuehaibing@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

zhaoxin inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7LXCE
CVE: NA

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

There are some issues that need to be resolved for Zhaoxin Platform.
So remove Zhaoxin uncore code first.
Signed-off-by: Nleoliu-oc <leoliu-oc@zhaoxin.com>

mainline inclusion
from mainline-v6.5-rc2
commit 06a0716949c22e2aefb648526580671197151acc
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7M991
CVE: NA

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

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

Now in addrconf_mod_rs_timer(), reference idev depends on whether
rs_timer is not pending. Then modify rs_timer timeout.

There is a time gap in [1], during which if the pending rs_timer
becomes not pending. It will miss to hold idev, but the rs_timer
is activated. Thus rs_timer callback function addrconf_rs_timer()
will be executed and put idev later without holding idev. A refcount
underflow issue for idev can be caused by this.

	if (!timer_pending(&idev->rs_timer))
		in6_dev_hold(idev);
		  <--------------[1]
	mod_timer(&idev->rs_timer, jiffies + when);

To fix the issue, hold idev if mod_timer() return 0.

Fixes: b7b1bfce ("ipv6: split duplicate address detection and router solicitation timer")
Suggested-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>

mainline inclusion
from mainline-v6.5-rc2
commit caf3ef7468f7534771b5c44cd8dbd6f7f87c2cbd
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7ISR1
CVE: CVE-2023-35001

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

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

When evaluating byteorder expressions with size 2, a union with 32-bit and
16-bit members is used. Since the 16-bit members are aligned to 32-bit,
the array accesses will be out-of-bounds.

It may lead to a stack-out-of-bounds access like the one below:

[   23.095215] ==================================================================
[   23.095625] BUG: KASAN: stack-out-of-bounds in nft_byteorder_eval+0x13c/0x320
[   23.096020] Read of size 2 at addr ffffc90000007948 by task ping/115
[   23.096358]
[   23.096456] CPU: 0 PID: 115 Comm: ping Not tainted 6.4.0+ #413
[   23.096770] Call Trace:
[   23.096910]  <IRQ>
[   23.097030]  dump_stack_lvl+0x60/0xc0
[   23.097218]  print_report+0xcf/0x630
[   23.097388]  ? nft_byteorder_eval+0x13c/0x320
[   23.097577]  ? kasan_addr_to_slab+0xd/0xc0
[   23.097760]  ? nft_byteorder_eval+0x13c/0x320
[   23.097949]  kasan_report+0xc9/0x110
[   23.098106]  ? nft_byteorder_eval+0x13c/0x320
[   23.098298]  __asan_load2+0x83/0xd0
[   23.098453]  nft_byteorder_eval+0x13c/0x320
[   23.098659]  nft_do_chain+0x1c8/0xc50
[   23.098852]  ? __pfx_nft_do_chain+0x10/0x10
[   23.099078]  ? __kasan_check_read+0x11/0x20
[   23.099295]  ? __pfx___lock_acquire+0x10/0x10
[   23.099535]  ? __pfx___lock_acquire+0x10/0x10
[   23.099745]  ? __kasan_check_read+0x11/0x20
[   23.099929]  nft_do_chain_ipv4+0xfe/0x140
[   23.100105]  ? __pfx_nft_do_chain_ipv4+0x10/0x10
[   23.100327]  ? lock_release+0x204/0x400
[   23.100515]  ? nf_hook.constprop.0+0x340/0x550
[   23.100779]  nf_hook_slow+0x6c/0x100
[   23.100977]  ? __pfx_nft_do_chain_ipv4+0x10/0x10
[   23.101223]  nf_hook.constprop.0+0x334/0x550
[   23.101443]  ? __pfx_ip_local_deliver_finish+0x10/0x10
[   23.101677]  ? __pfx_nf_hook.constprop.0+0x10/0x10
[   23.101882]  ? __pfx_ip_rcv_finish+0x10/0x10
[   23.102071]  ? __pfx_ip_local_deliver_finish+0x10/0x10
[   23.102291]  ? rcu_read_lock_held+0x4b/0x70
[   23.102481]  ip_local_deliver+0xbb/0x110
[   23.102665]  ? __pfx_ip_rcv+0x10/0x10
[   23.102839]  ip_rcv+0x199/0x2a0
[   23.102980]  ? __pfx_ip_rcv+0x10/0x10
[   23.103140]  __netif_receive_skb_one_core+0x13e/0x150
[   23.103362]  ? __pfx___netif_receive_skb_one_core+0x10/0x10
[   23.103647]  ? mark_held_locks+0x48/0xa0
[   23.103819]  ? process_backlog+0x36c/0x380
[   23.103999]  __netif_receive_skb+0x23/0xc0
[   23.104179]  process_backlog+0x91/0x380
[   23.104350]  __napi_poll.constprop.0+0x66/0x360
[   23.104589]  ? net_rx_action+0x1cb/0x610
[   23.104811]  net_rx_action+0x33e/0x610
[   23.105024]  ? _raw_spin_unlock+0x23/0x50
[   23.105257]  ? __pfx_net_rx_action+0x10/0x10
[   23.105485]  ? mark_held_locks+0x48/0xa0
[   23.105741]  __do_softirq+0xfa/0x5ab
[   23.105956]  ? __dev_queue_xmit+0x765/0x1c00
[   23.106193]  do_softirq.part.0+0x49/0xc0
[   23.106423]  </IRQ>
[   23.106547]  <TASK>
[   23.106670]  __local_bh_enable_ip+0xf5/0x120
[   23.106903]  __dev_queue_xmit+0x789/0x1c00
[   23.107131]  ? __pfx___dev_queue_xmit+0x10/0x10
[   23.107381]  ? find_held_lock+0x8e/0xb0
[   23.107585]  ? lock_release+0x204/0x400
[   23.107798]  ? neigh_resolve_output+0x185/0x350
[   23.108049]  ? mark_held_locks+0x48/0xa0
[   23.108265]  ? neigh_resolve_output+0x185/0x350
[   23.108514]  neigh_resolve_output+0x246/0x350
[   23.108753]  ? neigh_resolve_output+0x246/0x350
[   23.109003]  ip_finish_output2+0x3c3/0x10b0
[   23.109250]  ? __pfx_ip_finish_output2+0x10/0x10
[   23.109510]  ? __pfx_nf_hook+0x10/0x10
[   23.109732]  __ip_finish_output+0x217/0x390
[   23.109978]  ip_finish_output+0x2f/0x130
[   23.110207]  ip_output+0xc9/0x170
[   23.110404]  ip_push_pending_frames+0x1a0/0x240
[   23.110652]  raw_sendmsg+0x102e/0x19e0
[   23.110871]  ? __pfx_raw_sendmsg+0x10/0x10
[   23.111093]  ? lock_release+0x204/0x400
[   23.111304]  ? __mod_lruvec_page_state+0x148/0x330
[   23.111567]  ? find_held_lock+0x8e/0xb0
[   23.111777]  ? find_held_lock+0x8e/0xb0
[   23.111993]  ? __rcu_read_unlock+0x7c/0x2f0
[   23.112225]  ? aa_sk_perm+0x18a/0x550
[   23.112431]  ? filemap_map_pages+0x4f1/0x900
[   23.112665]  ? __pfx_aa_sk_perm+0x10/0x10
[   23.112880]  ? find_held_lock+0x8e/0xb0
[   23.113098]  inet_sendmsg+0xa0/0xb0
[   23.113297]  ? inet_sendmsg+0xa0/0xb0
[   23.113500]  ? __pfx_inet_sendmsg+0x10/0x10
[   23.113727]  sock_sendmsg+0xf4/0x100
[   23.113924]  ? move_addr_to_kernel.part.0+0x4f/0xa0
[   23.114190]  __sys_sendto+0x1d4/0x290
[   23.114391]  ? __pfx___sys_sendto+0x10/0x10
[   23.114621]  ? __pfx_mark_lock.part.0+0x10/0x10
[   23.114869]  ? lock_release+0x204/0x400
[   23.115076]  ? find_held_lock+0x8e/0xb0
[   23.115287]  ? rcu_is_watching+0x23/0x60
[   23.115503]  ? __rseq_handle_notify_resume+0x6e2/0x860
[   23.115778]  ? __kasan_check_write+0x14/0x30
[   23.116008]  ? blkcg_maybe_throttle_current+0x8d/0x770
[   23.116285]  ? mark_held_locks+0x28/0xa0
[   23.116503]  ? do_syscall_64+0x37/0x90
[   23.116713]  __x64_sys_sendto+0x7f/0xb0
[   23.116924]  do_syscall_64+0x59/0x90
[   23.117123]  ? irqentry_exit_to_user_mode+0x25/0x30
[   23.117387]  ? irqentry_exit+0x77/0xb0
[   23.117593]  ? exc_page_fault+0x92/0x140
[   23.117806]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
[   23.118081] RIP: 0033:0x7f744aee2bba
[   23.118282] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89
[   23.119237] RSP: 002b:00007ffd04a7c9f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[   23.119644] RAX: ffffffffffffffda RBX: 00007ffd04a7e0a0 RCX: 00007f744aee2bba
[   23.120023] RDX: 0000000000000040 RSI: 000056488e9e6300 RDI: 0000000000000003
[   23.120413] RBP: 000056488e9e6300 R08: 00007ffd04a80320 R09: 0000000000000010
[   23.120809] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000040
[   23.121219] R13: 00007ffd04a7dc38 R14: 00007ffd04a7ca00 R15: 00007ffd04a7e0a0
[   23.121617]  </TASK>
[   23.121749]
[   23.121845] The buggy address belongs to the virtual mapping at
[   23.121845]  [ffffc90000000000, ffffc90000009000) created by:
[   23.121845]  irq_init_percpu_irqstack+0x1cf/0x270
[   23.122707]
[   23.122803] The buggy address belongs to the physical page:
[   23.123104] page:0000000072ac19f0 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x24a09
[   23.123609] flags: 0xfffffc0001000(reserved|node=0|zone=1|lastcpupid=0x1fffff)
[   23.123998] page_type: 0xffffffff()
[   23.124194] raw: 000fffffc0001000 ffffea0000928248 ffffea0000928248 0000000000000000
[   23.124610] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
[   23.125023] page dumped because: kasan: bad access detected
[   23.125326]
[   23.125421] Memory state around the buggy address:
[   23.125682]  ffffc90000007800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   23.126072]  ffffc90000007880: 00 00 00 00 00 f1 f1 f1 f1 f1 f1 00 00 f2 f2 00
[   23.126455] >ffffc90000007900: 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00 00 00
[   23.126840]                                               ^
[   23.127138]  ffffc90000007980: 00 00 00 00 00 00 00 00 00 00 00 00 00 f3 f3 f3
[   23.127522]  ffffc90000007a00: f3 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
[   23.127906] ==================================================================
[   23.128324] Disabling lock debugging due to kernel taint

Using simple s16 pointers for the 16-bit accesses fixes the problem. For
the 32-bit accesses, src and dst can be used directly.

Fixes: 96518518 ("netfilter: add nftables")
Cc: stable@vger.kernel.org
Reported-by: Tanguy DUBROCA (@SidewayRE) from @Synacktiv working with ZDI
Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@canonical.com>
Reviewed-by: NFlorian Westphal <fw@strlen.de>
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: NZiyang Xuan <william.xuanziyang@huawei.com>

mainline inclusion
from mainline-v6.5-rc2
commit 26efd79c4624294e553aeaa3439c646729bad084
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7KYPM
CVE: NA

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

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

As comments in ftrace_process_locs(), there may be NULL pointers in
mcount_loc section:
 > Some architecture linkers will pad between
 > the different mcount_loc sections of different
 > object files to satisfy alignments.
 > Skip any NULL pointers.

After commit 20e5227e ("ftrace: allow NULL pointers in mcount_loc"),
NULL pointers will be accounted when allocating ftrace pages but skipped
before adding into ftrace pages, this may result in some pages not being
used. Then after commit 706c81f8 ("ftrace: Remove extra helper
functions"), warning may occur at:
  WARN_ON(pg->next);

To fix it, only warn for case that no pointers skipped but pages not used
up, then free those unused pages after releasing ftrace_lock.

Link: https://lore.kernel.org/linux-trace-kernel/20230712060452.3175675-1-zhengyejian1@huawei.com

Cc: stable@vger.kernel.org
Fixes: 706c81f8 ("ftrace: Remove extra helper functions")
Suggested-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Signed-off-by: NSteven Rostedt (Google) <rostedt@goodmis.org>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

mainline inclusion
from mainline-v6.5-rc2
commit 7e42907f3a7b4ce3a2d1757f6d78336984daf8f5
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7KXY9
CVE: NA

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

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

Soft lockup occurs when reading file 'trace_pipe':

  watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488]
  [...]
  RIP: 0010:ring_buffer_empty_cpu+0xed/0x170
  RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246
  RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb
  RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218
  RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f
  R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901
  R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000
  [...]
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   __find_next_entry+0x1a8/0x4b0
   ? peek_next_entry+0x250/0x250
   ? down_write+0xa5/0x120
   ? down_write_killable+0x130/0x130
   trace_find_next_entry_inc+0x3b/0x1d0
   tracing_read_pipe+0x423/0xae0
   ? tracing_splice_read_pipe+0xcb0/0xcb0
   vfs_read+0x16b/0x490
   ksys_read+0x105/0x210
   ? __ia32_sys_pwrite64+0x200/0x200
   ? switch_fpu_return+0x108/0x220
   do_syscall_64+0x33/0x40
   entry_SYSCALL_64_after_hwframe+0x61/0xc6

Through the vmcore, I found it's because in tracing_read_pipe(),
ring_buffer_empty_cpu() found some buffer is not empty but then it
cannot read anything due to "rb_num_of_entries() == 0" always true,
Then it infinitely loop the procedure due to user buffer not been
filled, see following code path:

  tracing_read_pipe() {
    ... ...
    waitagain:
      tracing_wait_pipe() // 1. find non-empty buffer here
      trace_find_next_entry_inc()  // 2. loop here try to find an entry
        __find_next_entry()
          ring_buffer_empty_cpu();  // 3. find non-empty buffer
          peek_next_entry()  // 4. but peek always return NULL
            ring_buffer_peek()
              rb_buffer_peek()
                rb_get_reader_page()
                  // 5. because rb_num_of_entries() == 0 always true here
                  //    then return NULL
      // 6. user buffer not been filled so goto 'waitgain'
      //    and eventually leads to an deadloop in kernel!!!
  }

By some analyzing, I found that when resetting ringbuffer, the 'entries'
of its pages are not all cleared (see rb_reset_cpu()). Then when reducing
the ringbuffer, and if some reduced pages exist dirty 'entries' data, they
will be added into 'cpu_buffer->overrun' (see rb_remove_pages()), which
cause wrong 'overrun' count and eventually cause the deadloop issue.

To fix it, we need to clear every pages in rb_reset_cpu().

Link: https://lore.kernel.org/linux-trace-kernel/20230708225144.3785600-1-zhengyejian1@huawei.com

Cc: stable@vger.kernel.org
Fixes: a5fb8331 ("ring-buffer: Fix uninitialized read_stamp")
Signed-off-by: NZheng Yejian <zhengyejian1@huawei.com>
Signed-off-by: NSteven Rostedt (Google) <rostedt@goodmis.org>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

Merge Pull Request from: @LiuYongQiang0816 
 
3 patches from Lu Wei 
 
Link:https://gitee.com/openeuler/kernel/pulls/1435 

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

mainline inclusion
from mainline-v6.4
commit 3e70489721b6c870252c9082c496703677240f53
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N
CVE: CVE-2023-3117

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

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

Otherwise a dangling reference to a rule object that is gone remains
in the set binding list.

Fixes: 26b5a571 ("netfilter: nf_tables: add NFT_TRANS_PREPARE_ERROR to deal with bound set/chain")
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

mainline inclusion
from mainline-v6.4
commit 26b5a571
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N
CVE: CVE-2023-3117

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

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

Add a new state to deal with rule expressions deactivation from the
newrule error path, otherwise the anonymous set remains in the list in
inactive state for the next generation. Mark the set/chain transaction
as unbound so the abort path releases this object, set it as inactive in
the next generation so it is not reachable anymore from this transaction
and reference counter is dropped.

Fixes: 1240eb93 ("netfilter: nf_tables: incorrect error path handling with NFT_MSG_NEWRULE")
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>

conflict:
	include/net/netfilter/nf_tables.h
	net/netfilter/nf_tables_api.c
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

mainline inclusion
from mainline-v6.4-rc7
commit 1240eb93
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7H68N
CVE: CVE-2023-3117

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

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

In case of error when adding a new rule that refers to an anonymous set,
deactivate expressions via NFT_TRANS_PREPARE state, not NFT_TRANS_RELEASE.
Thus, the lookup expression marks anonymous sets as inactive in the next
generation to ensure it is not reachable in this transaction anymore and
decrement the set refcount as introduced by c1592a89 ("netfilter:
nf_tables: deactivate anonymous set from preparation phase"). The abort
step takes care of undoing the anonymous set.

This is also consistent with rule deletion, where NFT_TRANS_PREPARE is
used. Note that this error path is exercised in the preparation step of
the commit protocol. This patch replaces nf_tables_rule_release() by the
deactivate and destroy calls, this time with NFT_TRANS_PREPARE.

Due to this incorrect error handling, it is possible to access a
dangling pointer to the anonymous set that remains in the transaction
list.

[1009.379054] BUG: KASAN: use-after-free in nft_set_lookup_global+0x147/0x1a0 [nf_tables]
[1009.379106] Read of size 8 at addr ffff88816c4c8020 by task nft-rule-add/137110
[1009.379116] CPU: 7 PID: 137110 Comm: nft-rule-add Not tainted 6.4.0-rc4+ #256
[1009.379128] Call Trace:
[1009.379132]  <TASK>
[1009.379135]  dump_stack_lvl+0x33/0x50
[1009.379146]  ? nft_set_lookup_global+0x147/0x1a0 [nf_tables]
[1009.379191]  print_address_description.constprop.0+0x27/0x300
[1009.379201]  kasan_report+0x107/0x120
[1009.379210]  ? nft_set_lookup_global+0x147/0x1a0 [nf_tables]
[1009.379255]  nft_set_lookup_global+0x147/0x1a0 [nf_tables]
[1009.379302]  nft_lookup_init+0xa5/0x270 [nf_tables]
[1009.379350]  nf_tables_newrule+0x698/0xe50 [nf_tables]
[1009.379397]  ? nf_tables_rule_release+0xe0/0xe0 [nf_tables]
[1009.379441]  ? kasan_unpoison+0x23/0x50
[1009.379450]  nfnetlink_rcv_batch+0x97c/0xd90 [nfnetlink]
[1009.379470]  ? nfnetlink_rcv_msg+0x480/0x480 [nfnetlink]
[1009.379485]  ? __alloc_skb+0xb8/0x1e0
[1009.379493]  ? __alloc_skb+0xb8/0x1e0
[1009.379502]  ? entry_SYSCALL_64_after_hwframe+0x46/0xb0
[1009.379509]  ? unwind_get_return_address+0x2a/0x40
[1009.379517]  ? write_profile+0xc0/0xc0
[1009.379524]  ? avc_lookup+0x8f/0xc0
[1009.379532]  ? __rcu_read_unlock+0x43/0x60

Fixes: 958bee14 ("netfilter: nf_tables: use new transaction infrastructure to handle sets")
Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>

conflict:
	net/netfilter/nf_tables_api.c
Signed-off-by: NLu Wei <luwei32@huawei.com>
Reviewed-by: NYue Haibing <yuehaibing@huawei.com>
Reviewed-by: NWang Weiyang <wangweiyang2@huawei.com>
Signed-off-by: NYongqiang Liu <liuyongqiang13@huawei.com>

Merge Pull Request from: @zh-hhhhh 
 

If you run qemu-img convert -t none when iscsi back-end storage is used (mounted using multipath), an error message is displayed indicating Device or resource busy. The error message is resolved after patch is added

bugzilla: https://gitee.com/openeuler/kernel/issues/I7GDLI
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/block_dev.c?h=v5.10.180&id=d44c9780ed40db88626c9354868eab72159c7a7f

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

Reviewed-by: Zhang Changzhong <zhangchangzhong@huawei.com> 
Reviewed-by: Yu Kuai <yukuai3@huawei.com> 
Signed-off-by: Zhang Changzhong <zhangchangzhong@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/message/GAAGSCSVFKUBGX26W76VACFSY63LUWTV/ 
Revert origin fix, add debug message.


Zhihao Cheng (2):
  Revert "ext4: Stop trying writing pages if no free blocks generated"
  ext4: Add debug message to notify user space is out of free


-- 
2.31.1
 
https://gitee.com/openeuler/kernel/issues/I7CBCS 
 
Link:https://gitee.com/openeuler/kernel/pulls/1416 

Reviewed-by: zhangyi (F) <yi.zhang@huawei.com> 
Signed-off-by: Liu YongQiang <liuyongqiang13@huawei.com> 

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

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

Add debug message to notify user that ext4_writepages is stuck in loop
caused by ENOSPC.
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>

This reverts commit 6b84e9d9.

When ext4 runs out of space, there could be a potential data lost in
ext4_writepages:
If there are many preallocated blocks for some files, e4b bitmap is
different from block bitmap, and there are more free blocks accounted
by block bitmap.

    ext4_writepages                         P2
ext4_mb_new_blocks                  ext4_map_blocks
 ext4_mb_regular_allocator // No free bits in e4b bitmap
 ext4_mb_discard_preallocations_should_retry
  ext4_mb_discard_preallocations
   ext4_mb_discard_group_preallocations
    ext4_mb_release_inode_pa // updates e4b bitmap by pa->pa_free
     mb_free_blocks
                                     ext4_mb_new_blocks
                                      ext4_mb_regular_allocator
                                      // Got e4b bitmap's free bits
 ext4_mb_regular_allocator  // After 3 times retrying, ret ENOSPC

ext4_writepages
 mpage_map_and_submit_extent
  mpage_map_one_extent // ret ENOSPC
  if (err == -ENOSPC && EXT4_SB(sb)->s_mb_free_pending)
  // s_mb_free_pending is 0
  *give_up_on_write = true  // Abandon writeback, data lost!

Fixes: 6b84e9d9 ("ext4: Stop trying writing pages if no free ...")
Signed-off-by: NZhihao Cheng <chengzhihao1@huawei.com>

Merge Pull Request from: @ci-robot 
 
PR sync from: Pu Lehui <pulehui@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HKR5D65AUBUR6PQA2JDXV2YLD275ND24/ 
 
https://gitee.com/openeuler/kernel/issues/I7KN6F 
 
Link:https://gitee.com/openeuler/kernel/pulls/1404 

Reviewed-by: Xu Kuohai <xukuohai@huawei.com> 
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>