September 2023 - Kernel - mailweb.openeuler.org

[PATCH openEuler-23.09] mm: gmem: create gm_as when dont have device avoid mmap failed
by Wupeng Ma 12 Sep '23

12 Sep '23

From: Yang Yanchao <yangyanchao6(a)huawei.com> euleros inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7WLVX --------------------------------------------- Make sure that the mmap is successfully executed when no device exists. Fixes: 46a7894b5e4c ("mm: gmem: Introduce GMEM") Signed-off-by: Yang Yanchao <yangyanchao6(a)huawei.com> --- mm/mmap.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index bff71a766e0a..7d04e54494b6 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2453,6 +2453,9 @@ static void munmap_in_peer_devices(struct mm_struct *mm, if (!obj) return; + if (!mm->gm_as) + return; + do { xa_lock(obj->logical_page_table); gm_mapping = vm_object_lookup(obj, addr); @@ -2480,9 +2483,6 @@ static void munmap_in_peer_devices(struct mm_struct *mm, mutex_unlock(&gm_mapping->lock); } while (addr += HPAGE_SIZE, addr != end); - if (!mm->gm_as) - return; - list_for_each_entry_safe(ctx, tmp, &mm->gm_as->gm_ctx_list, gm_as_link) { if (!gm_dev_is_peer(ctx->dev)) continue; @@ -2746,9 +2746,13 @@ static int alloc_va_in_peer_devices(struct mm_struct *mm, gm_context_t *ctx, *tmp; gm_ret_t ret; + if (!mm->gm_as) { + ret = gm_as_create(0, ULONG_MAX, GM_AS_ALLOC_DEFAULT, PAGE_SIZE, + &mm->gm_as); + if (ret) + return ret; + } pr_debug("gmem: start mmap, as %p\n", mm->gm_as); - if (!mm->gm_as) - return -ENODEV; if (!vma->vm_obj) vma->vm_obj = vm_object_create(vma); -- 2.25.1

2 1

[PATCH OLK-5.10] scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflow
by Yong Hu 12 Sep '23

12 Sep '23

From: Justin Tee <justin.tee(a)broadcom.com> stable inclusion from stable-v5.15.113 commit f91037487036e2d2f18d3c2481be6b9a366bde7f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7ZCDZ CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/dri… -------------------------------- [ Upstream commit c6087b82a9146826564a55c5ca0164cac40348f5 ] A static code analysis tool flagged the possibility of buffer overflow when using copy_from_user() for a debugfs entry. Currently, it is possible that copy_from_user() copies more bytes than what would fit in the mybuf char array. Add a min() restriction check between sizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protect against buffer overflow. Link: https://lore.kernel.org/r/20230301231626.9621-2-justintee8345@gmail.com Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Yong Hu <yong.hu(a)windriver.com> --- drivers/scsi/lpfc/lpfc_debugfs.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c index fbc76d69ea0b..2b77cbbcdccb 100644 --- a/drivers/scsi/lpfc/lpfc_debugfs.c +++ b/drivers/scsi/lpfc/lpfc_debugfs.c @@ -2159,10 +2159,13 @@ lpfc_debugfs_lockstat_write(struct file *file, const char __user *buf, char mybuf[64]; char *pbuf; int i; + size_t bsize; memset(mybuf, 0, sizeof(mybuf)); - if (copy_from_user(mybuf, buf, nbytes)) + bsize = min(nbytes, (sizeof(mybuf) - 1)); + + if (copy_from_user(mybuf, buf, bsize)) return -EFAULT; pbuf = &mybuf[0]; @@ -2183,7 +2186,7 @@ lpfc_debugfs_lockstat_write(struct file *file, const char __user *buf, qp->lock_conflict.wq_access = 0; } } - return nbytes; + return bsize; } #endif -- 2.33.0

2 1

[PATCH OLK-5.10] scsi: lpfc: Fix ioremap issues in lpfc_sli4_pci_mem_setup()
by Yong Hu 12 Sep '23

12 Sep '23

From: Shuchang Li <lishuchang(a)hust.edu.cn> stable inclusion from stable-v5.15.111 commit fd8c83d8375b9dac1949f2753485a5c055ebfad0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7ZCDZ CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/dri… -------------------------------- [ Upstream commit 91a0c0c1413239d0548b5aac4c82f38f6d53a91e ] When if_type equals zero and pci_resource_start(pdev, PCI_64BIT_BAR4) returns false, drbl_regs_memmap_p is not remapped. This passes a NULL pointer to iounmap(), which can trigger a WARN() on certain arches. When if_type equals six and pci_resource_start(pdev, PCI_64BIT_BAR4) returns true, drbl_regs_memmap_p may has been remapped and ctrl_regs_memmap_p is not remapped. This is a resource leak and passes a NULL pointer to iounmap(). To fix these issues, we need to add null checks before iounmap(), and change some goto labels. Fixes: 1351e69fc6db ("scsi: lpfc: Add push-to-adapter support to sli4") Signed-off-by: Shuchang Li <lishuchang(a)hust.edu.cn> Link: https://lore.kernel.org/r/20230404072133.1022-1-lishuchang@hust.edu.cn Reviewed-by: Justin Tee <justin.tee(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Yong Hu <yong.hu(a)windriver.com> --- drivers/scsi/lpfc/lpfc_init.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 17200b453cbb..1bb3c96a04bd 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -10477,7 +10477,7 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba *phba) goto out_iounmap_all; } else { error = -ENOMEM; - goto out_iounmap_all; + goto out_iounmap_ctrl; } } @@ -10495,7 +10495,7 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba *phba) dev_err(&pdev->dev, "ioremap failed for SLI4 HBA dpp registers.\n"); error = -ENOMEM; - goto out_iounmap_ctrl; + goto out_iounmap_all; } phba->pci_bar4_memmap_p = phba->sli4_hba.dpp_regs_memmap_p; } @@ -10520,9 +10520,11 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba *phba) return 0; out_iounmap_all: - iounmap(phba->sli4_hba.drbl_regs_memmap_p); + if (phba->sli4_hba.drbl_regs_memmap_p) + iounmap(phba->sli4_hba.drbl_regs_memmap_p); out_iounmap_ctrl: - iounmap(phba->sli4_hba.ctrl_regs_memmap_p); + if (phba->sli4_hba.ctrl_regs_memmap_p) + iounmap(phba->sli4_hba.ctrl_regs_memmap_p); out_iounmap_conf: iounmap(phba->sli4_hba.conf_regs_memmap_p); -- 2.33.0

2 1

[PATCH OLK-5.10] netfilter: nf_tables: skip immediate deactivate in _PREPARE_ERROR
by Lu Wei 12 Sep '23

12 Sep '23

From: Pablo Neira Ayuso <pablo(a)netfilter.org> mainline inclusion from mainline-v6.5-rc4 commit 0a771f7b266b02d262900c75f1e175c7fe76fec2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I7YIXO CVE: CVE-2022-40982 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… --------------------------- On error when building the rule, the immediate expression unbinds the chain, hence objects can be deactivated by the transaction records. Otherwise, it is possible to trigger the following warning: WARNING: CPU: 3 PID: 915 at net/netfilter/nf_tables_api.c:2013 nf_tables_chain_destroy+0x1f7/0x210 [nf_tables] CPU: 3 PID: 915 Comm: chain-bind-err- Not tainted 6.1.39 #1 RIP: 0010:nf_tables_chain_destroy+0x1f7/0x210 [nf_tables] Fixes: 4bedf9eee016 ("netfilter: nf_tables: fix chain binding transaction logic") Reported-by: Kevin Rich <kevinrich1337(a)gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Florian Westphal <fw(a)strlen.de> conflict: net/netfilter/nft_immediate.c Signed-off-by: Lu Wei <luwei32(a)huawei.com> --- net/netfilter/nft_immediate.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/net/netfilter/nft_immediate.c b/net/netfilter/nft_immediate.c index 6b0efab4fad0..6bf1c852e8ea 100644 --- a/net/netfilter/nft_immediate.c +++ b/net/netfilter/nft_immediate.c @@ -125,15 +125,27 @@ static void nft_immediate_activate(const struct nft_ctx *ctx, return nft_data_hold(&priv->data, nft_dreg_to_type(priv->dreg)); } +static void nft_immediate_chain_deactivate(const struct nft_ctx *ctx, + struct nft_chain *chain, + enum nft_trans_phase phase) +{ + struct nft_ctx chain_ctx; + struct nft_rule *rule; + + chain_ctx = *ctx; + chain_ctx.chain = chain; + + list_for_each_entry(rule, &chain->rules, list) + nft_rule_expr_deactivate(&chain_ctx, rule, phase); +} + static void nft_immediate_deactivate(const struct nft_ctx *ctx, const struct nft_expr *expr, enum nft_trans_phase phase) { const struct nft_immediate_expr *priv = nft_expr_priv(expr); const struct nft_data *data = &priv->data; - struct nft_ctx chain_ctx; struct nft_chain *chain; - struct nft_rule *rule; if (priv->dreg == NFT_REG_VERDICT) { switch (data->verdict.code) { @@ -143,20 +155,17 @@ static void nft_immediate_deactivate(const struct nft_ctx *ctx, if (!nft_chain_binding(chain)) break; - chain_ctx = *ctx; - chain_ctx.chain = chain; - - list_for_each_entry(rule, &chain->rules, list) - nft_rule_expr_deactivate(&chain_ctx, rule, phase); - switch (phase) { case NFT_TRANS_PREPARE_ERROR: nf_tables_unbind_chain(ctx, chain); - fallthrough; + nft_deactivate_next(ctx->net, chain); + break; case NFT_TRANS_PREPARE: + nft_immediate_chain_deactivate(ctx, chain, phase); nft_deactivate_next(ctx->net, chain); break; default: + nft_immediate_chain_deactivate(ctx, chain, phase); nft_chain_del(chain); chain->bound = false; chain->table->use--; -- 2.34.1

2 1

[PATCH openEuler-23.09] mm: gmem: create gm_as when dont have device avoid mmap failed
by Wupeng Ma 12 Sep '23

12 Sep '23

From: Yang Yanchao <yangyanchao6(a)huawei.com> euleros inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7WLVX --------------------------------------------- Make sure that the mmap is successfully executed when no device exists. Fixes: 46a7894b5e4c ("mm: gmem: Introduce GMEM") Signed-off-by: Yang Yanchao <yangyanchao6(a)huawei.com> --- mm/mmap.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index bff71a766e0a..ce998ea4e817 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -2453,6 +2453,9 @@ static void munmap_in_peer_devices(struct mm_struct *mm, if (!obj) return; + if (mm->gm_as == NULL) + return; + do { xa_lock(obj->logical_page_table); gm_mapping = vm_object_lookup(obj, addr); @@ -2480,9 +2483,6 @@ static void munmap_in_peer_devices(struct mm_struct *mm, mutex_unlock(&gm_mapping->lock); } while (addr += HPAGE_SIZE, addr != end); - if (!mm->gm_as) - return; - list_for_each_entry_safe(ctx, tmp, &mm->gm_as->gm_ctx_list, gm_as_link) { if (!gm_dev_is_peer(ctx->dev)) continue; @@ -2747,8 +2747,12 @@ static int alloc_va_in_peer_devices(struct mm_struct *mm, gm_ret_t ret; pr_debug("gmem: start mmap, as %p\n", mm->gm_as); - if (!mm->gm_as) - return -ENODEV; + if (!mm->gm_as) { + ret = gm_as_create(0, ULONG_MAX, GM_AS_ALLOC_DEFAULT, PAGE_SIZE, + &mm->gm_as); + if (ret) + return ret; + } if (!vma->vm_obj) vma->vm_obj = vm_object_create(vma); -- 2.25.1

2 1

[PATCH OLK-5.10] scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflow
by Yong Hu 12 Sep '23

12 Sep '23

From: Justin Tee <justin.tee(a)broadcom.com> stable inclusion from stable-v5.15.131 commit f91037487036e2d2f18d3c2481be6b9a366bde7f category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7ZCDZ CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/dri… -------------------------------- [ Upstream commit c6087b82a9146826564a55c5ca0164cac40348f5 ] A static code analysis tool flagged the possibility of buffer overflow when using copy_from_user() for a debugfs entry. Currently, it is possible that copy_from_user() copies more bytes than what would fit in the mybuf char array. Add a min() restriction check between sizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protect against buffer overflow. Link: https://lore.kernel.org/r/20230301231626.9621-2-justintee8345@gmail.com Signed-off-by: Justin Tee <justin.tee(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Yong Hu <yong.hu(a)windriver.com> --- drivers/scsi/lpfc/lpfc_debugfs.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_debugfs.c b/drivers/scsi/lpfc/lpfc_debugfs.c index fbc76d69ea0b..2b77cbbcdccb 100644 --- a/drivers/scsi/lpfc/lpfc_debugfs.c +++ b/drivers/scsi/lpfc/lpfc_debugfs.c @@ -2159,10 +2159,13 @@ lpfc_debugfs_lockstat_write(struct file *file, const char __user *buf, char mybuf[64]; char *pbuf; int i; + size_t bsize; memset(mybuf, 0, sizeof(mybuf)); - if (copy_from_user(mybuf, buf, nbytes)) + bsize = min(nbytes, (sizeof(mybuf) - 1)); + + if (copy_from_user(mybuf, buf, bsize)) return -EFAULT; pbuf = &mybuf[0]; @@ -2183,7 +2186,7 @@ lpfc_debugfs_lockstat_write(struct file *file, const char __user *buf, qp->lock_conflict.wq_access = 0; } } - return nbytes; + return bsize; } #endif -- 2.33.0

2 1

[PATCH OLK-5.10] scsi: lpfc: Fix ioremap issues in lpfc_sli4_pci_mem_setup()
by Yong Hu 12 Sep '23

12 Sep '23

From: Shuchang Li <lishuchang(a)hust.edu.cn> stable inclusion from stable-v5.15.131 commit fd8c83d8375b9dac1949f2753485a5c055ebfad0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7ZCDZ CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/dri… -------------------------------- [ Upstream commit 91a0c0c1413239d0548b5aac4c82f38f6d53a91e ] When if_type equals zero and pci_resource_start(pdev, PCI_64BIT_BAR4) returns false, drbl_regs_memmap_p is not remapped. This passes a NULL pointer to iounmap(), which can trigger a WARN() on certain arches. When if_type equals six and pci_resource_start(pdev, PCI_64BIT_BAR4) returns true, drbl_regs_memmap_p may has been remapped and ctrl_regs_memmap_p is not remapped. This is a resource leak and passes a NULL pointer to iounmap(). To fix these issues, we need to add null checks before iounmap(), and change some goto labels. Fixes: 1351e69fc6db ("scsi: lpfc: Add push-to-adapter support to sli4") Signed-off-by: Shuchang Li <lishuchang(a)hust.edu.cn> Link: https://lore.kernel.org/r/20230404072133.1022-1-lishuchang@hust.edu.cn Reviewed-by: Justin Tee <justin.tee(a)broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Yong Hu <yong.hu(a)windriver.com> --- drivers/scsi/lpfc/lpfc_init.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 17200b453cbb..1bb3c96a04bd 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -10477,7 +10477,7 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba *phba) goto out_iounmap_all; } else { error = -ENOMEM; - goto out_iounmap_all; + goto out_iounmap_ctrl; } } @@ -10495,7 +10495,7 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba *phba) dev_err(&pdev->dev, "ioremap failed for SLI4 HBA dpp registers.\n"); error = -ENOMEM; - goto out_iounmap_ctrl; + goto out_iounmap_all; } phba->pci_bar4_memmap_p = phba->sli4_hba.dpp_regs_memmap_p; } @@ -10520,9 +10520,11 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba *phba) return 0; out_iounmap_all: - iounmap(phba->sli4_hba.drbl_regs_memmap_p); + if (phba->sli4_hba.drbl_regs_memmap_p) + iounmap(phba->sli4_hba.drbl_regs_memmap_p); out_iounmap_ctrl: - iounmap(phba->sli4_hba.ctrl_regs_memmap_p); + if (phba->sli4_hba.ctrl_regs_memmap_p) + iounmap(phba->sli4_hba.ctrl_regs_memmap_p); out_iounmap_conf: iounmap(phba->sli4_hba.conf_regs_memmap_p); -- 2.33.0

2 1

[PATCH openEuler-23.09 v2] arm64: fix abi change caused by ILP32
by Chen Jiahao 12 Sep '23

12 Sep '23

From: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7WGZU CVE: NA -------------------------------- One of the ILP32 patchset rename 'compat_user_mode' and 'compat_thumb_mode' to 'a32_user_mode' and 'a32_user_mode'. But these two macros are used in some opensource userspace application. To keep compatibility, we redefine these two macros. Fixes: 884eaf44006d ("arm64: rename functions that reference compat term") Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Reviewed-by: Hanjun Guo <guohanjun(a)huawei.com> Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Reviewed-by: liwei <liwei391(a)huawei.com> Signed-off-by: Zheng Zengkai <zhengzengkai(a)huawei.com> Signed-off-by: Chen Jiahao <chenjiahao16(a)huawei.com> --- arch/arm64/include/asm/ptrace.h | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h index 992b04efe7f8..9cb0fd362ac4 100644 --- a/arch/arm64/include/asm/ptrace.h +++ b/arch/arm64/include/asm/ptrace.h @@ -224,6 +224,8 @@ static inline void forget_syscall(struct pt_regs *regs) #define a32_thumb_mode(regs) (0) #endif +#define compat_thumb_mode(regs) a32_thumb_mode(regs) + #define user_mode(regs) \ (((regs)->pstate & PSR_MODE_MASK) == PSR_MODE_EL0t) @@ -231,6 +233,8 @@ static inline void forget_syscall(struct pt_regs *regs) (((regs)->pstate & (PSR_MODE32_BIT | PSR_MODE_MASK)) == \ (PSR_MODE32_BIT | PSR_MODE_EL0t)) +#define compat_user_mode(regs) a32_user_mode(regs) + #define processor_mode(regs) \ ((regs)->pstate & PSR_MODE_MASK) -- 2.34.1

2 1

[PATCH v4 openEuler-23.09 0/1] kernel: add OPENEULER_VERSION_CODE to version.h
by Xie XiuQi 12 Sep '23

12 Sep '23

Add OPENEULER_VERSION_CODE to version.h, so modules or applications can identify the specific kernel version. 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. The version information is generated in "linux/version.h", as bellow: include/generated/uapi/linux/version.h ``` #define OPENEULER_LTS 0 // 1: LTS; 0: none LTS #define OPENEULER_MAJOR 9999 // OS Major version, 9999: none released #define OPENEULER_MINOR 0 // SP release version #define OPENEULER_VERSION(a,b) (((a) << 8) + (b)) #define OPENEULER_VERSION_CODE 2559744 ``` Use Makefile.oever to avoid future merge conflicts. https://gitee.com/openeuler/kernel/pulls/1442 https://gitee.com/openeuler/kernel/issues/I7LEXY https://gitee.com/openeuler/kernel/issues/I575IT https://gitee.com/openeuler/kernel/issues/I7761D Xie XiuQi (1): kernel: add OPENEULER_VERSION_CODE to version.h --- v4: fix commit message format error for pr 1442 Makefile | 11 ++++++++++- Makefile.oever | 4 ++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 Makefile.oever -- 2.20.1

2 2

[PATCH v3 openEuler-23.09 0/1] kernel: add OPENEULER_VERSION_CODE to version.h
by Xie XiuQi 12 Sep '23

12 Sep '23

Add OPENEULER_VERSION_CODE to version.h, so modules or applications can identify the specific kernel version. 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. The version information is generated in "linux/version.h", as bellow: include/generated/uapi/linux/version.h ``` #define OPENEULER_LTS 0 // 1: LTS; 0: none LTS #define OPENEULER_MAJOR 9999 // OS Major version, 9999: none released #define OPENEULER_MINOR 0 // SP release version #define OPENEULER_VERSION(a,b) (((a) << 8) + (b)) #define OPENEULER_VERSION_CODE 2559744 ``` Use Makefile.oever to avoid future merge conflicts. https://gitee.com/openeuler/kernel/pulls/1442 https://gitee.com/openeuler/kernel/issues/I7LEXY https://gitee.com/openeuler/kernel/issues/I575IT https://gitee.com/openeuler/kernel/issues/I7761D Xie XiuQi (1): kernel: add OPENEULER_VERSION_CODE to version.h --- v2: fix commit message format error for pr 1442 Makefile | 11 ++++++++++- Makefile.oever | 4 ++++ 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 Makefile.oever -- 2.20.1

2 2

2024

2023

2022

2021

2020

2019

Kernel September 2023