Offering: HULK
hulk inclusion
category: bugfix
bugzilla: 188865, https://gitee.com/openeuler/kernel/issues/I76JSK

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

When recovery intents, it may capture some deferred ops and commit the new
intent items, if recovery intents fails, there will be no done item drop
the reference to the new intent item. This leads to a memory leak as
fllows:

unreferenced object 0xffff888016719108 (size 432):
  comm "mount", pid 529, jiffies 4294706839 (age 144.463s)
  hex dump (first 32 bytes):
    08 91 71 16 80 88 ff ff 08 91 71 16 80 88 ff ff  ..q.......q.....
    18 91 71 16 80 88 ff ff 18 91 71 16 80 88 ff ff  ..q.......q.....
  backtrace:
    [<ffffffff8230c68f>] xfs_efi_init+0x18f/0x1d0
    [<ffffffff8230c720>] xfs_extent_free_create_intent+0x50/0x150
    [<ffffffff821b671a>] xfs_defer_create_intents+0x16a/0x340
    [<ffffffff821bac3e>] xfs_defer_ops_capture_and_commit+0x8e/0xad0
    [<ffffffff82322bb9>] xfs_cui_item_recover+0x819/0x980
    [<ffffffff823289b6>] xlog_recover_process_intents+0x246/0xb70
    [<ffffffff8233249a>] xlog_recover_finish+0x8a/0x9a0
    [<ffffffff822eeafb>] xfs_log_mount_finish+0x2bb/0x4a0
    [<ffffffff822c0f4f>] xfs_mountfs+0x14bf/0x1e70
    [<ffffffff822d1f80>] xfs_fs_fill_super+0x10d0/0x1b20
    [<ffffffff81a21fa2>] get_tree_bdev+0x3d2/0x6d0
    [<ffffffff81a1ee09>] vfs_get_tree+0x89/0x2c0
    [<ffffffff81a9f35f>] path_mount+0xecf/0x1800
    [<ffffffff81a9fd83>] do_mount+0xf3/0x110
    [<ffffffff81aa00e4>] __x64_sys_mount+0x154/0x1f0
    [<ffffffff83968739>] do_syscall_64+0x39/0x80

Fix it by abort intent items in capture list that don't have a done item
when recovery intents fail. If transaction that have deferred ops is
commmit fails in xfs_defer_ops_capture_and_commit(), defer capture would
not added to capture list, it also need abort too.
Signed-off-by: NLong Li <leo.lilong@huawei.com>
(cherry picked from commit c1b08a41)

Offering: HULK
hulk inclusion
category: bugfix
bugzilla: 188865, https://gitee.com/openeuler/kernel/issues/I76JSK

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

Factor out xfs_defer_pending_abort() from xfs_defer_trans_abort(), which
not use transaction parameter, so it can be used after the transaction
life cycle.
Signed-off-by: NLong Li <leo.lilong@huawei.com>
(cherry picked from commit 9bd2b3bd)

Offering: HULK
hulk inclusion
category: bugfix
bugzilla: 188870, https://gitee.com/openeuler/kernel/issues/I76JSK

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

During the test of growfs + power-off, we encountered a mounting failure
issue.
The specific call stack is as follows:

[584505.210179] XFS (loop0): xfs_buf_find: daddr 0x6d6002 out of range,
EOFS 0x6d6000
...
[584505.210739] Call Trace:
[584505.210776]  xfs_buf_get_map+0x44/0x230 [xfs]
[584505.210780]  ? trace_event_buffer_commit+0x57/0x140
[584505.210818]  xfs_buf_read_map+0x54/0x280 [xfs]
[584505.210858]  ? xlog_recover_items_pass2+0x53/0xb0 [xfs]
[584505.210899]  xlog_recover_buf_commit_pass2+0x112/0x440 [xfs]
[584505.210939]  ? xlog_recover_items_pass2+0x53/0xb0 [xfs]
[584505.210980]  xlog_recover_items_pass2+0x53/0xb0 [xfs]
[584505.211020]  xlog_recover_commit_trans+0x2ca/0x320 [xfs]
[584505.211061]  xlog_recovery_process_trans+0xc6/0xf0 [xfs]
[584505.211101]  xlog_recover_process_data+0x9e/0x110 [xfs]
[584505.211141]  xlog_do_recovery_pass+0x3b4/0x5c0 [xfs]
[584505.211181]  xlog_do_log_recovery+0x5e/0x80 [xfs]
[584505.211223]  xlog_do_recover+0x33/0x1a0 [xfs]
[584505.211262]  xlog_recover+0xd7/0x170 [xfs]
[584505.211303]  xfs_log_mount+0x217/0x2b0 [xfs]
[584505.211341]  xfs_mountfs+0x3da/0x870 [xfs]
[584505.211384]  xfs_fc_fill_super+0x3fa/0x7a0 [xfs]
[584505.211428]  ? xfs_setup_devices+0x80/0x80 [xfs]
[584505.211432]  get_tree_bdev+0x16f/0x260
[584505.211434]  vfs_get_tree+0x25/0xc0
[584505.211436]  do_new_mount+0x156/0x1b0
[584505.211438]  __se_sys_mount+0x165/0x1d0
[584505.211440]  do_syscall_64+0x33/0x40
[584505.211442]  entry_SYSCALL_64_after_hwframe+0x61/0xc6

After analyzing the log records, we have discovered the following
content:

============================================================================
cycle: 173  version: 2    lsn: 173,2742 tail_lsn: 173,1243
length of Log Record: 25600 prev offset: 2702   num ops: 258
uuid: fb958458-48a3-4c76-ae23-7a1cf3053065   format: little endian linux
h_size: 32768
----------------------------------------------------------------------------
...
----------------------------------------------------------------------------
Oper (100): tid: 1c010724  len: 24  clientid: TRANS  flags: none
BUF:  #regs: 2   start blkno: 7168002 (0x6d6002)  len: 1  bmap size: 1
flags: 0x3800
Oper (101): tid: 1c010724  len: 128  clientid: TRANS  flags: none
AGI Buffer: XAGI
ver: 1  seq#: 28  len: 2048  cnt: 0  root: 3
level: 1  free#: 0x0  newino: 0x140
bucket[0 - 3]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
bucket[4 - 7]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
bucket[8 - 11]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
bucket[12 - 15]: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
bucket[16 - 19]: 0xffffffff
----------------------------------------------------------------------------
...
----------------------------------------------------------------------------
Oper (108): tid: 1c010724  len: 24  clientid: TRANS  flags: none
BUF:  #regs: 2   start blkno: 0 (0x0)  len: 1  bmap size: 1  flags:
0x9000
Oper (109): tid: 1c010724  len: 384  clientid: TRANS  flags: none
SUPER BLOCK Buffer:
icount: 6360863066640355328  ifree: 898048  fdblks: 0  frext: 0
----------------------------------------------------------------------------
...

We found that in the log records, the modification transaction for the
expanded block is before the growfs transaction, which leads to
verification
failure during log replay.

We need to ensure that when replaying logs, transactions related to the
superblock are replayed first.
Signed-off-by: NWu Guanghao <wuguanghao3@huawei.com>
Signed-off-by: Nyangerkun <yangerkun@huawei.com>
Signed-off-by: NLong Li <leo.lilong@huawei.com>
(cherry picked from commit dba19fb8)

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1297 
 
PR sync from: Zhang Zekun <zhangzekun11@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/62KOPQGPH57KOUCLU3BZ6ECRRXYWU4HB/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1306 

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1191 
 
PR sync from: Wupeng Ma <mawupeng1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/DBYQ7YX2NZXNZFVXLHOUZRNTPCMRY75Q/ 
From: Ma Wupeng <mawupeng1@huawei.com>

Fix memory reliable related issues.

Ma Wupeng (3):
  mm: mem_reliable: Fix reliable page counter mismatch problem
  mm: mem_reliable: Update reliable page counter to zero if underflows
  efi: Disable mirror feature during crashkernel


-- 
2.25.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1231 

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1194 
 
PR sync from: Wupeng Ma <mawupeng1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/JDE2LDXAOHQR2RGYUMOGCZOLNJGVO7EW/ 
From: Ma Wupeng <mawupeng1@huawei.com>

1. fix memleak with efi_fake_mem
2. disable efi_fake_mem support by default for arm64

Ma Wupeng (2):
  efi: Fix UAF for arm64 when enable efi_fake_mem
  config: Disable EFI_FAKE_MEMMAP support for arm64 by default


-- 
2.25.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1236 

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1247 
 
PR sync from: Cai Xinchen <caixinchen1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/NYV2JFJ3O7YZNQOGH4SYOIN6Z5C2J3LP/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1257 

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1245 
 
PR sync from: Liu Shixin <liushixin2@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/NL3WSSDH4CG2P2J6NDYTGUIS3A4PSEFY/ 
Fix two bugfix of hugetlb:
1) Invalid use of nr_online_nodes;
2) Inconsistency between 1G hugepage and 2M hugepage.

Peng Liu (2):
  hugetlb: fix wrong use of nr_online_nodes
  hugetlb: fix hugepages_setup when deal with pernode


-- 
2.25.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1249 

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

!1234 [sync] PR-1220:  mm/memory_hotplug: extend offline_and_remove_memory() to handle more than one memory block

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1220 
 
PR sync from: Wupeng Ma <mawupeng1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/HO6QXFWOBWOT6QFQ3P5VMHCBDUJXVKCI/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1234 

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1185 
 
PR sync from: Zhong Jinghua <zhongjinghua@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/4GPNRNM6BTL377CSMFTAKUUAS34YECTL/ 
nbd: validate the block size in nbd_set_size

Christoph Hellwig (1):
  nbd: validate the block size in nbd_set_size

Zhong Jinghua (1):
  nbd: fix incomplete validation of ioctl arg


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

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

!1276 [sync] PR-1253:  media: saa7134: fix use after free bug in saa7134_finidev due to race condition

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1253 
 
PR sync from: Longlong Xia <xialonglong1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/O25ROO7NSR27YAETYTL5DMZW7DV6CNOO/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1276 

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1283 
 
PR sync from: Pu Lehui <pulehui@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/I6FYDSV7M256UEC5NL26CH6SJ3NLHPXX/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1304 

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1270 
 
PR sync from: Chen Jiahao <chenjiahao16@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/LKM3OGRPHUFIBAXN26GKXPU4STERGPYH/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1301 

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

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

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

The commit 0227a749 introduce
a config CONFIG_IOVA_MAX_GLOBAL_MAGS, but it relies on IOMMU_SUPPORT.
Some drivers can compile without IOMMU_SUPPORT, but still include
include/linux/iova.h, which can cause compile problem. Fix this
by moving the definition of CONFIG_IOVA_MAX_GLOBAL_MAGS out of
IOMMU_SUPPORT.

The error compile message is showned as below:

In file included from ./include/linux/intel-iommu.h:14,
                 from ./include/drm/intel-gtt.h:8,
                 from drivers/char/agp/intel-agp.c:15:
./include/linux/iova.h:29:25: error: ‘CONFIG_IOVA_MAX_GLOBAL_MAGS’ undeclared here (not in a function)
   29 | #define MAX_GLOBAL_MAGS CONFIG_IOVA_MAX_GLOBAL_MAGS /* magazines per bin */
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/iova.h:34:30: note: in expansion of macro ‘MAX_GLOBAL_MAGS’
   34 |  struct iova_magazine *depot[MAX_GLOBAL_MAGS];
      |                              ^~~~~~~~~~~~~~~
In file included from ./include/linux/intel-iommu.h:14,
                 from ./include/drm/intel-gtt.h:8,
                 from drivers/char/agp/intel-gtt.c:27:
./include/linux/iova.h:29:25: error: ‘CONFIG_IOVA_MAX_GLOBAL_MAGS’ undeclared here (not in a function)
   29 | #define MAX_GLOBAL_MAGS CONFIG_IOVA_MAX_GLOBAL_MAGS /* magazines per bin */
      |                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/iova.h:34:30: note: in expansion of macro ‘MAX_GLOBAL_MAGS’
   34 |  struct iova_magazine *depot[MAX_GLOBAL_MAGS];
      |                              ^~~~~~~~~~~~~~~
make[3]: *** [scripts/Makefile.build:286: drivers/char/agp/intel-agp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:286: drivers/char/agp/intel-gtt.o] Error 1
make[2]: *** [scripts/Makefile.build:503: drivers/char/agp] Error 2
make[1]: *** [scripts/Makefile.build:503: drivers/char] Error 2
make[1]: *** Waiting for unfinished jobs....
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>
(cherry picked from commit b86a6767)

!1266 [sync] PR-1261:  usb: gadget: udc: renesas_usb3: Fix use after free bug in renesas_usb3_remove due to race condition

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1261 
 
PR sync from: Jialin Zhang <zhangjialin11@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/7KTWBBNYFJCK5RNBNMDHJRJHHWNO7JEZ/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1266 

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

stable inclusion
from stable-v5.10.180
commit e9d64e90a0ada4d00ac6562e351ef10ae7d9b911
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7F1RG
CVE: CVE-2023-35824

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

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

[ Upstream commit 5abda7a1 ]

In dm1105_probe, it called dm1105_ir_init and bound
&dm1105->ir.work with dm1105_emit_key.
When it handles IRQ request with dm1105_irq,
it may call schedule_work to start the work.

When we call dm1105_remove to remove the driver, there
may be a sequence as follows:

Fix it by finishing the work before cleanup in dm1105_remove

CPU0                  CPU1

                    |dm1105_emit_key
dm1105_remove      |
  dm1105_ir_exit       |
    rc_unregister_device |
    rc_free_device  |
    rc_dev_release  |
    kfree(dev);     |
                    |
                    | rc_keydown
                    |   //use

Fixes: 34d2f9bf ("V4L/DVB: dm1105: use dm1105_dev & dev instead of dm1105dvb")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NPu Lehui <pulehui@huawei.com>
Reviewed-by: NXu Kuohai <xukuohai@huawei.com>
Reviewed-by: NXiu Jianfeng <xiujianfeng@huawei.com>
(cherry picked from commit a7d0cd45)

mainline inclusion
from mainline-v6.4-rc3
commit b8c75e4a
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I6YKXB
CVE: CVE-2023-31084

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

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

Using a semaphore in the wait_event*() condition is no good idea.
It hits a kernel WARN_ON() at prepare_to_wait_event() like:
  do not call blocking ops when !TASK_RUNNING; state=1 set at
  prepare_to_wait_event+0x6d/0x690

For avoiding the potential deadlock, rewrite to an open-coded loop
instead.  Unlike the loop in wait_event*(), this uses wait_woken()
after the condition check, hence the task state stays consistent.

CVE-2023-31084 was assigned to this bug.

Link: https://lore.kernel.org/r/CA+UBctCu7fXn4q41O_3=id1+OdyQ85tZY1x+TkT-6OVBL6KAUw@mail.gmail.com/

Link: https://lore.kernel.org/linux-media/20230512151800.1874-1-tiwai@suse.deReported-by: NYu Hao <yhao016@ucr.edu>
Closes: https://nvd.nist.gov/vuln/detail/CVE-2023-31084Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NChen Jiahao <chenjiahao16@huawei.com>
(cherry picked from commit c008597c)

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1181 
 
PR sync from: "GONG, Ruiqi" <gongruiqi1@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/2UQWQFUDJJ3AA4KWKXEAZSYYXWTLW3UM/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1240 

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

stable inclusion
from stable-v5.10.180
commit 7dac96e9cc985328ec1fae92f0c245f559dc0e11
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7ERIV
CVE: CVE-2023-3327

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

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

[ Upstream commit 30cf57da ]

In saa7134_initdev, it will call saa7134_hwinit1. There are three
function invoking here: saa7134_video_init1, saa7134_ts_init1
and saa7134_vbi_init1.

All of them will init a timer with same function. Take
saa7134_video_init1 as an example. It'll bound &dev->video_q.timeout
with saa7134_buffer_timeout.

In buffer_activate, the timer funtcion is started.

If we remove the module or device which will call saa7134_finidev
to make cleanup, there may be a unfinished work. The
possible sequence is as follows, which will cause a
typical UAF bug.

Fix it by canceling the timer works accordingly before cleanup in
saa7134_finidev.

CPU0                  CPU1

                    |saa7134_buffer_timeout
saa7134_finidev     |
  kfree(dev);       |
                    |
                    | saa7134_buffer_next
                    | //use dev

Fixes: 1e7126b4 ("media: saa7134: Convert timers to use timer_setup()")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NLonglong Xia <xialonglong1@huawei.com>
(cherry picked from commit d046e6f3)

mainline inclusion
from mainline-v6.4-rc1
commit 2b947f87
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7EDYS
CVE: CVE-2023-35828

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

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

In renesas_usb3_probe, role_work is bound with renesas_usb3_role_work.
renesas_usb3_start will be called to start the work.

If we remove the driver which will call usbhs_remove, there may be
an unfinished work. The possible sequence is as follows:

CPU0                  			CPU1

                    			 renesas_usb3_role_work
renesas_usb3_remove
usb_role_switch_unregister
device_unregister
kfree(sw)
//free usb3->role_sw
                    			 usb_role_switch_set_role
                    			 //use usb3->role_sw

The usb3->role_sw could be freed under such circumstance and then
used in usb_role_switch_set_role.

This bug was found by static analysis. And note that removing a
driver is a root-only operation, and should never happen in normal
case. But the root user may directly remove the device which
will also trigger the remove function.

Fix it by canceling the work before cleanup in the renesas_usb3_remove.

Fixes: 39facfa0 ("usb: gadget: udc: renesas_usb3: Add register of usb role switch")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Reviewed-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20230320062931.505170-1-zyytlz.wz@163.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NJialin Zhang <zhangjialin11@huawei.com>
(cherry picked from commit c6acce6a)

Merge Pull Request from: @ci-robot 
 
PR sync from: Zhang Zekun <zhangzekun11@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/QTEAS342W3GWUZ4HON7LSTQKXGLF5G3K/ 
The iova rcache will have performance problem, set the iova rcache
global mag max size to 128 to fix it.

Zhang Zekun (2):
  iommu/iova: increase the iova_rcache depot max size
  config: enable set the max iova mag size to 128


-- 
2.17.1
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1244 

Reviewed-by: Zheng Zengkai <zhengzengkai@huawei.com> 
Reviewed-by: Liu Chao <liuchao173@huawei.com> 
Reviewed-by: Weilong Chen <chenweilong@huawei.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

stable inclusion
from stable-v5.10.166
commit 7b4516ba56f1fcb13ffc91912f3074e28362228d
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7FCLX
CVE: CVE-2023-3358

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

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

[ Upstream commit b3d40c3e ]

As the kcalloc may return NULL pointer,
it should be better to check the ishtp_dma_tx_map
before use in order to avoid NULL pointer dereference.

Fixes: 3703f53b ("HID: intel_ish-hid: ISH Transport layer")
Signed-off-by: NJiasheng Jiang <jiasheng@iscas.ac.cn>
Acked-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NCai Xinchen <caixinchen1@huawei.com>
(cherry picked from commit beefe46c)

mainline inclusion
from mainline-v5.19-rc1
commit f87442f4
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6OWV4
CVE: NA

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

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

Hugepages can be specified to pernode since "hugetlbfs: extend the
definition of hugepages parameter to support node allocation", but the
following problem is observed.

Confusing behavior is observed when both 1G and 2M hugepage is set
after "numa=off".
 cmdline hugepage settings:
  hugepagesz=1G hugepages=0:3,1:3
  hugepagesz=2M hugepages=0:1024,1:1024
 results:
  HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
  HugeTLB registered 2.00 MiB page size, pre-allocated 1024 pages

Furthermore, confusing behavior can be also observed when an invalid node
behind a valid node.  To fix this, never allocate any typical hugepage
when an invalid parameter is received.

Link: https://lkml.kernel.org/r/20220413032915.251254-3-liupeng256@huawei.com
Fixes: b5389086 ("hugetlbfs: extend the definition of hugepages parameter to support node allocation")
Signed-off-by: NPeng Liu <liupeng256@huawei.com>
Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Liu Yuntao <liuyuntao10@huawei.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Zhenguo Yao <yaozhenguo1@gmail.com>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
(cherry picked from commit 3aa26c25)

mainline inclusion
from mainline-v5.19-rc1
commit 0a7a0f6f
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I6OWV4
CVE: NA

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

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

Patch series "hugetlb: Fix some incorrect behavior", v3.

This series fix three bugs of hugetlb:
1) Invalid use of nr_online_nodes;
2) Inconsistency between 1G hugepage and 2M hugepage;
3) Useless information in dmesg.

This patch (of 4):

Certain systems are designed to have sparse/discontiguous nodes.  In this
case, nr_online_nodes can not be used to walk through numa node.  Also, a
valid node may be greater than nr_online_nodes.

However, in hugetlb, it is assumed that nodes are contiguous.

For sparse/discontiguous nodes, the current code may treat a valid node
as invalid, and will fail to allocate all hugepages on a valid node that
"nid >= nr_online_nodes".

As David suggested:

	if (tmp >= nr_online_nodes)
		goto invalid;

Just imagine node 0 and node 2 are online, and node 1 is offline.
Assuming that "node < 2" is valid is wrong.

Recheck all the places that use nr_online_nodes, and repair them one by
one.

[liupeng256@huawei.com: v4]
  Link: https://lkml.kernel.org/r/20220416103526.3287348-1-liupeng256@huawei.com
Link: https://lkml.kernel.org/r/20220413032915.251254-1-liupeng256@huawei.com
Link: https://lkml.kernel.org/r/20220413032915.251254-2-liupeng256@huawei.com
Fixes: 4178158e ("hugetlbfs: fix issue of preallocation of gigantic pages can't work")
Fixes: b5389086 ("hugetlbfs: extend the definition of hugepages parameter to support node allocation")
Fixes: e79ce983 ("hugetlbfs: fix a truncation issue in hugepages parameter")
Fixes: f9317f77 ("hugetlb: clean up potential spectre issue warnings")
Signed-off-by: NPeng Liu <liupeng256@huawei.com>
Suggested-by: NDavid Hildenbrand <david@redhat.com>
Reviewed-by: NBaolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NDavidlohr Bueso <dave@stgolabs.net>
Reviewed-by: NMike Kravetz <mike.kravetz@oracle.com>
Acked-by: NDavid Hildenbrand <david@redhat.com>
Cc: Zhenguo Yao <yaozhenguo1@gmail.com>
Cc: Muchun Song <songmuchun@bytedance.com>
Cc: Liu Yuntao <liuyuntao10@huawei.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Conflicts:
	mm/hugetlb.c
Signed-off-by: NLiu Shixin <liushixin2@huawei.com>
(cherry picked from commit 2e35014f)

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

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

iova mag size will be iova_rcache size to 128, to support more
concurrency in iova allocation, and can fix the problem dixcribe
in bugzilla.
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>

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

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

In fio test with iodepth=256 with allowd cpus to 0-255, we observe a
serve performance decrease. The statistic of cache hit rate are
relatively low. Here are some statistics about the iova_cpu_rcahe of
all cpus:

iova alloc order		0	1	2	3	4	5
----------------------------------------------------------------------
average cpu_rcache hit rate	0.9941	0.7408	0.8109	0.8854	0.9082	0.8887

Jobs: 12 (f=12): [R(12)][20.0%][r=1091MiB/s][r=279k IOPS][eta 00m:28s]
Jobs: 12 (f=12): [R(12)][22.2%][r=1426MiB/s][r=365k IOPS][eta 00m:28s]
Jobs: 12 (f=12): [R(12)][25.0%][r=1607MiB/s][r=411k IOPS][eta 00m:27s]
Jobs: 12 (f=12): [R(12)][27.8%][r=1501MiB/s][r=384k IOPS][eta 00m:26s]
Jobs: 12 (f=12): [R(12)][30.6%][r=1486MiB/s][r=380k IOPS][eta 00m:25s]
Jobs: 12 (f=12): [R(12)][33.3%][r=1393MiB/s][r=357k IOPS][eta 00m:24s]
Jobs: 12 (f=12): [R(12)][36.1%][r=1550MiB/s][r=397k IOPS][eta 00m:23s]
Jobs: 12 (f=12): [R(12)][38.9%][r=1485MiB/s][r=380k IOPS][eta 00m:22s]

The under lying hisi sas driver has 16 thread irqs to free iova, but
these irq call back function will only free iovas on 16 certain cpus(cpu{0,
16,32...,240}). For example, thread irq which smp affinity is 0-15, will
only free iova on cpu 0. However, the driver will alloc iova on all
cpus(cpu{0-255}), cpus without free iova in local cpu_rcache need to get
free iovas from iova_rcache->depot. The current size of
iova_rcache->depot max size is 32, and it seems to be too small for 256
users (16 cpus will put iovas to iova_rcache->depot and 240 cpus will
try to get iova from it). Set iova_rcache->depot to 128 can fix the
performance issue, and the performance can return to normal.

iova alloc order		0	1	2	3	4	5
----------------------------------------------------------------------
average cpu_rcache hit rate	0.9925	0.9736	0.9789	0.9867	0.9889	0.9906

Jobs: 12 (f=12): [R(12)][12.9%][r=7526MiB/s][r=1927k IOPS][eta 04m:30s]
Jobs: 12 (f=12): [R(12)][13.2%][r=7527MiB/s][r=1927k IOPS][eta 04m:29s]
Jobs: 12 (f=12): [R(12)][13.5%][r=7529MiB/s][r=1927k IOPS][eta 04m:28s]
Jobs: 12 (f=12): [R(12)][13.9%][r=7531MiB/s][r=1928k IOPS][eta 04m:27s]
Jobs: 12 (f=12): [R(12)][14.2%][r=7529MiB/s][r=1928k IOPS][eta 04m:26s]
Jobs: 12 (f=12): [R(12)][14.5%][r=7528MiB/s][r=1927k IOPS][eta 04m:25s]
Jobs: 12 (f=12): [R(12)][14.8%][r=7527MiB/s][r=1927k IOPS][eta 04m:24s]
Jobs: 12 (f=12): [R(12)][15.2%][r=7525MiB/s][r=1926k IOPS][eta 04m:23s]
Signed-off-by: NZhang Zekun <zhangzekun11@huawei.com>

stable inclusion
from stable-v5.10.180
commit 1b0df44753bf9e45eaf5cee34f87597193f862e8
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7E5C1
CVE: CVE-2023-3268

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

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

commit 43ec16f1 upstream.

There is a crash in relay_file_read, as the var from
point to the end of last subbuf.

The oops looks something like:
pc : __arch_copy_to_user+0x180/0x310
lr : relay_file_read+0x20c/0x2c8
Call trace:
 __arch_copy_to_user+0x180/0x310
 full_proxy_read+0x68/0x98
 vfs_read+0xb0/0x1d0
 ksys_read+0x6c/0xf0
 __arm64_sys_read+0x20/0x28
 el0_svc_common.constprop.3+0x84/0x108
 do_el0_svc+0x74/0x90
 el0_svc+0x1c/0x28
 el0_sync_handler+0x88/0xb0
 el0_sync+0x148/0x180

We get the condition by analyzing the vmcore:

1). The last produced byte and last consumed byte
    both at the end of the last subbuf

2). A softirq calls function(e.g __blk_add_trace)
    to write relay buffer occurs when an program is calling
    relay_file_read_avail().

        relay_file_read
                relay_file_read_avail
                        relay_file_read_consume(buf, 0, 0);
                        //interrupted by softirq who will write subbuf
                        ....
                        return 1;
                //read_start point to the end of the last subbuf
                read_start = relay_file_read_start_pos
                //avail is equal to subsize
                avail = relay_file_read_subbuf_avail
                //from  points to an invalid memory address
                from = buf->start + read_start
                //system is crashed
                copy_to_user(buffer, from, avail)

Link: https://lkml.kernel.org/r/20230419040203.37676-1-zhang.zhengming@h3c.com
Fixes: 8d62fdeb ("relay file read: start-pos fix")
Signed-off-by: NZhang Zhengming <zhang.zhengming@h3c.com>
Reviewed-by: NZhao Lei <zhao_lei1@hoperun.com>
Reviewed-by: NZhou Kete <zhou.kete@h3c.com>
Reviewed-by: NPengcheng Yang <yangpc@wangsu.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: <stable@vger.kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NGONG, Ruiqi <gongruiqi1@huawei.com>
(cherry picked from commit 6b2322db)

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

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

EFI_FAKE_MEMMAP is used specific memory range by updating original
(firmware provided) EFI memmap. This can only be used for debug
propose. Disable it by default.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
(cherry picked from commit 13ecd6fc)

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

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

Efi fake mem support for arm64 is introduced for debug propose
only. However efi_memmap_init_late in arm_enable_runtime_services
will free this memory which will lead to UAF on efi.memmap.map.

In order to slove this, clear efi.memmap.flags to skip free.
Since efi map is never freed in arm64, this will not lead to
memroy leak.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
(cherry picked from commit 6b455c10)

mainline inclusion
from mainline-v5.11-rc1
commit 8dc4bb58
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7F3HQ
CVE: NA

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

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

virtio-mem soon wants to use offline_and_remove_memory() memory that
exceeds a single Linux memory block (memory_block_size_bytes()). Let's
remove that restriction.

Let's remember the old state and try to restore that if anything goes
wrong. While re-onlining can, in general, fail, it's highly unlikely to
happen (usually only when a notifier fails to allocate memory, and these
are rather rare).

This will be used by virtio-mem to offline+remove memory ranges that are
bigger than a single memory block - for example, with a device block
size of 1 GiB (e.g., gigantic pages in the hypervisor) and a Linux memory
block size of 128MB.

While we could compress the state into 2 bit, using 8 bit is much
easier.

This handling is similar, but different to acpi_scan_try_to_offline():

a) We don't try to offline twice. I am not sure if this CONFIG_MEMCG
optimization is still relevant - it should only apply to ZONE_NORMAL
(where we have no guarantees). If relevant, we can always add it.

b) acpi_scan_try_to_offline() simply onlines all memory in case
something goes wrong. It doesn't restore previous online type. Let's do
that, so we won't overwrite what e.g., user space configured.
Reviewed-by: NWei Yang <richard.weiyang@linux.alibaba.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Wei Yang <richard.weiyang@linux.alibaba.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20201112133815.13332-28-david@redhat.comSigned-off-by: NMichael S. Tsirkin <mst@redhat.com>
Acked-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
(cherry picked from commit 9b7206bc)

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

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

If system have no mirrored memory or use crashkernel.high while
kernelcore=mirror is enabled in cmdline, during crashkernel,
there will be limited mirrored memory and this usually lead to
OOM.

To solve this problem, disable mirror feature during crashkernel.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
(cherry picked from commit 2bbd51a7)

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

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

Since reliable page counter is used for debug purpose only, There is no
real function problem by doing this.
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NNanyong Sun <sunnanyong@huawei.com>
(cherry picked from commit a687d7a0)

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

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

During copy_present_pte, rss counter is increased but the corresponding
reliable page counter is not updated. This will lead to reliable page
counter mismatch. Fix this by adding reliable page counter.

Fixes: d81e9624 ("proc: Count reliable memory usage of reliable tasks")
Signed-off-by: NMa Wupeng <mawupeng1@huawei.com>
Reviewed-by: NKefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: NNanyong Sun <sunnanyong@huawei.com>
(cherry picked from commit e70b561e)

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1177 
 
PR sync from: Zhengchao Shao <shaozhengchao@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/SK6QSFRPHOL2JH4U7D5UFNAWUTGI6TVU/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1189 

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1221 
 
PR sync from: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/OUV33PGH22SGOMA622E2MXOQEGDVIIGV/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1226 

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

Merge Pull Request from: @openeuler-sync-bot 
 

Origin pull request: 
https://gitee.com/openeuler/kernel/pulls/1227 
 
PR sync from: Zheng Zengkai <zhengzengkai@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/523BXW5DZPQ2JZPS3ZS4NBZ6GCRCWCWW/ 
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1229 

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

hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/intel-kernel/issues/I5RQLJ

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

5a2451f1 ("x86/fpu: Avoid kabi change caused by struct fpu") will
lead to performance degradation of libmicro pthread_create testcase.
Assuming that no 3rd party driver will reach into struct fpu,
replace kabi fix macro from KABI_DEPRECATE to KABI_BROKEN_REMOVE
for element "union fpregs_state state" of struct fpu.
Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
(cherry picked from commit b60bbfca)

stable inclusion
from stable-v5.10.180
commit de19d02d734ef29f5dbd2c12fe810fa960ecd83f
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7EDZ3
CVE: CVE-2023-35829

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

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

[ Upstream commit 3228cec2 ]

In rkvdec_probe, rkvdec->watchdog_work is bound with
rkvdec_watchdog_func. Then rkvdec_vp9_run may
be called to start the work.

If we remove the module which will call rkvdec_remove
 to make cleanup, there may be a unfinished work.
 The possible sequence is as follows, which will
 cause a typical UAF bug.

Fix it by canceling the work before cleanup in rkvdec_remove.

CPU0                  CPU1

                    |rkvdec_watchdog_func
rkvdec_remove       |
 rkvdec_v4l2_cleanup|
  v4l2_m2m_release  |
    kfree(m2m_dev); |
                    |
                    | v4l2_m2m_get_curr_priv
                    |   m2m_dev->curr_ctx //use

Fixes: cd33c830 ("media: rkvdec: Add the rkvdec driver")
Signed-off-by: NZheng Wang <zyytlz.wz@163.com>
Signed-off-by: NHans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NZhang Xiaoxu <zhangxiaoxu5@huawei.com>
(cherry picked from commit df1542dd)

Merge Pull Request from: @ci-robot 
 
PR sync from: Xie XiuQi <xiexiuqi@huawei.com>
https://mailweb.openeuler.org/hyperkitty/list/kernel@openeuler.org/message/JBDIT3MTL5BQ7CXF4CVKWPIZPIDGXUD7/ 

https://gitee.com/openeuler/kernel/issues/I7761D

In most cases, the out-of-tree module needs to identify the release
version of the openEuler for interface adaptation. The existing
OPENEULER_VERSION() and OPENEULER_VERSION_CODE() cannot distinguish
between LTS versions and innovative versions. Therefore, a new macro
OPENEULER_LTS is introduced.
 
 
Link:https://gitee.com/openeuler/kernel/pulls/1219 

Reviewed-by: sanglipeng <sanglipeng1@jd.com> 
Reviewed-by: Jason Zeng <jason.zeng@intel.com> 
Signed-off-by: Zheng Zengkai <zhengzengkai@huawei.com> 

openEuler inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I7761D
CVE: NA

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

In most cases, the out-of-tree module needs to identify the release
version of the openEuler for interface adaptation. The existing
OPENEULER_VERSION() and OPENEULER_VERSION_CODE() cannot distinguish
between LTS versions and innovative versions. Therefore, a new macro
OPENEULER_LTS is introduced.
Signed-off-by: NXie XiuQi <xiexiuqi@huawei.com>