mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2026 -----
  • April
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 39 participants
  • 23265 discussions
[PATCH OLK-6.6] net: usb: kaweth: validate USB endpoints
by Jinjiang Tu 21 Apr '26

21 Apr '26
From: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> stable inclusion from stable-v6.6.130 commit 72f90f481c6a059680b9b976695d4cfb04fba1f3 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13969 CVE: CVE-2026-23312 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4b063c002ca759d1b299988ee23f564c9609c875 upstream. The kaweth driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints. Cc: stable <stable(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Reviewed-by: Simon Horman <horms(a)kernel.org> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://patch.msgid.link/2026022305-substance-virtual-c728@gregkh Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/net/usb/kaweth.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/net/usb/kaweth.c b/drivers/net/usb/kaweth.c index c9efb7df892e..a8c3ecf7d810 100644 --- a/drivers/net/usb/kaweth.c +++ b/drivers/net/usb/kaweth.c @@ -885,6 +885,13 @@ static int kaweth_probe( const eth_addr_t bcast_addr = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF }; int result = 0; int rv = -EIO; + static const u8 bulk_ep_addr[] = { + 1 | USB_DIR_IN, + 2 | USB_DIR_OUT, + 0}; + static const u8 int_ep_addr[] = { + 3 | USB_DIR_IN, + 0}; dev_dbg(dev, "Kawasaki Device Probe (Device number:%d): 0x%4.4x:0x%4.4x:0x%4.4x\n", @@ -898,6 +905,12 @@ static int kaweth_probe( (int)udev->descriptor.bLength, (int)udev->descriptor.bDescriptorType); + if (!usb_check_bulk_endpoints(intf, bulk_ep_addr) || + !usb_check_int_endpoints(intf, int_ep_addr)) { + dev_err(dev, "couldn't find required endpoints\n"); + return -ENODEV; + } + netdev = alloc_etherdev(sizeof(*kaweth)); if (!netdev) return -ENOMEM; -- 2.43.0
2 1
0 0
[PATCH OLK-6.6] perf/core: Fix race between perf_event_exit_task and perf_pending_task
by Luo Gengkun 21 Apr '26

21 Apr '26
hulk inclusion category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14165 -------------------------------- A race condition exists between perf_event_exit_task() and perf_pending_task(). During begin_new_exec(), perf_event_exit_task() may be called, and the PF_EXITING flag is not set on task. so perf_sigtrap() continues to execute and triggers WARN_ON_ONCE(event->ctx->task != current). To fix this problem, also check if the event->ctx->task is TASK_TOMBSTONE. Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index cdd34d6e3dd4..7657ddf008ce 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -6782,7 +6782,7 @@ static void perf_sigtrap(struct perf_event *event) * Both perf_pending_task() and perf_pending_irq() can race with the * task exiting. */ - if (current->flags & PF_EXITING) + if (current->flags & PF_EXITING || event->ctx->task == TASK_TOMBSTONE) return; /* -- 2.34.1
2 1
0 0
[PATCH OLK-6.6] arm64: mm: fix pass user prot to ioremap_prot in generic_access_phys
by Jinjiang Tu 20 Apr '26

20 Apr '26
hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8982 ---------------------------------------- Here is a syzkaller error log: [0000000020ffc000] pgd=080000010598d403, p4d=080000010598d403, pud=0800000125ddb403, pmd=080000007833c403, pte=01608000007fcfcf Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 KASAN: probably user-memory-access in range [0x0000000475448000-0x0000000475448007] Mem abort info: ESR = 0x000000009600000f EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x0f: level 3 permission fault Data abort info: ISV = 0, ISS = 0x0000000f, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000001244aa000 [ffff80008ea89000] pgd=100000013ffff403, p4d=100000013ffff403, pud=100000013fffe403, pmd=100000010a453403, pte=01608000007fcfcf Internal error: Oops: 000000009600000f [#1] SMP Modules linked in: team CPU: 1 PID: 10840 Comm: syz.9.83 Kdump: loaded Tainted: G Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy_fromio+0x80/0xf8 lr : generic_access_phys+0x20c/0x2b8 sp : ffff8000a0507960 x29: ffff8000a0507960 x28: 1ffff000140a0f44 x27: ffff00003833cfe0 x26: 0000000000000000 x25: 0000000000001000 x24: 0010000000000001 x23: ffff80008ea89000 x22: ffff00004ea63000 x21: 0000000000001000 x20: ffff80008ea89000 x19: ffff00004ea62000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000806f1e3c x14: ffff8000806f1d44 x13: 0000000041b58ab3 x12: ffff7000140a0f23 x11: 1ffff000140a0f22 x10: ffff7000140a0f22 x9 : ffff800080579d24 x8 : 0000000000000004 x7 : 0000000000000003 x6 : 0000000000000001 x5 : ffff8000a0507910 x4 : ffff7000140a0f22 x3 : dfff800000000000 x2 : 0000000000001000 x1 : ffff80008ea89000 x0 : ffff00004ea62000 Call trace: __memcpy_fromio+0x80/0xf8 generic_access_phys+0x20c/0x2b8 __access_remote_vm+0x46c/0x5b8 access_remote_vm+0x18/0x30 environ_read+0x238/0x3e8 vfs_read+0xe4/0x2b0 ksys_read+0xcc/0x178 __arm64_sys_read+0x4c/0x68 invoke_syscall+0x68/0x1a0 el0_svc_common.constprop.0+0x11c/0x150 do_el0_svc+0x38/0x50 el0_svc+0x50/0x258 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x1a4/0x1a8 Code: 91002339 aa1403f7 8b190276 d503201f (f94002f8) The local syzkaller first maps I/O address from /dev/mem to userspace, overiding the stack vma with MAP_FIXED flag. As a result, when reading /proc/$pid/environ, generic_access_phys() is called to access the region, which triggers a PAN permission-check fault and causes a kernel access fault. The root cause is that generic_access_phys() passes a user pte to ioremap_prot(), the user pte sets PTE_USER and PTE_NG bits. Consequently, any subsequent kernel-mode access to the remapped address raises a fault. To fix it, define arch_mk_kernel_prot() to convert user prot to kernel prot for arm64, and call arch_mk_kernel_prot() in generic_access_phys(), so that a user prot is passed to ioremap_prot(). Mainline kernel fixes this issue by commit f6bf47ab32e0 ("arm64: io: Rename ioremap_prot() to __ioremap_prot()") and commit 8f098037139b ("arm64: io: Extract user memory type in ioremap_prot()"), which breaks KABI. So don't fix with the mainline kernel approach. Fixes: 893dea9ccd08 ("arm64: Add HAVE_IOREMAP_PROT support") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- arch/arm64/include/asm/io.h | 11 +++++++++++ mm/memory.c | 14 ++++++++++++-- 2 files changed, 23 insertions(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h index e9d6bcfddf35..227c16c8fc1d 100644 --- a/arch/arm64/include/asm/io.h +++ b/arch/arm64/include/asm/io.h @@ -146,6 +146,17 @@ int arm64_ioremap_prot_hook_register(const ioremap_prot_hook_t hook); #define ioremap_prot ioremap_prot +#define arch_mk_kernel_prot arch_mk_kernel_prot +static inline unsigned long arch_mk_kernel_prot(unsigned long user_prot) +{ + unsigned long kernel_prot_val; + + kernel_prot_val = _PAGE_KERNEL & ~PTE_ATTRINDX_MASK; + kernel_prot_val |= user_prot & PTE_ATTRINDX_MASK; + + return kernel_prot_val; +} + #define _PAGE_IOREMAP PROT_DEVICE_nGnRE #define ioremap_wc(addr, size) \ diff --git a/mm/memory.c b/mm/memory.c index 794233ef55eb..28de289fe973 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -6536,6 +6536,14 @@ int follow_phys(struct vm_area_struct *vma, return ret; } +#ifndef arch_mk_kernel_prot +#define arch_mk_kernel_prot arch_mk_kernel_prot +static inline unsigned long arch_mk_kernel_prot(unsigned long user_prot) +{ + return user_prot; +} +#endif + /** * generic_access_phys - generic implementation for iomem mmap access * @vma: the vma to access @@ -6552,7 +6560,8 @@ int generic_access_phys(struct vm_area_struct *vma, unsigned long addr, void *buf, int len, int write) { resource_size_t phys_addr; - unsigned long prot = 0; + unsigned long user_prot = 0; + unsigned long prot; void __iomem *maddr; pte_t *ptep, pte; spinlock_t *ptl; @@ -6568,12 +6577,13 @@ int generic_access_phys(struct vm_area_struct *vma, unsigned long addr, pte = ptep_get(ptep); pte_unmap_unlock(ptep, ptl); - prot = pgprot_val(pte_pgprot(pte)); + user_prot = pgprot_val(pte_pgprot(pte)); phys_addr = (resource_size_t)pte_pfn(pte) << PAGE_SHIFT; if ((write & FOLL_WRITE) && !pte_write(pte)) return -EINVAL; + prot = arch_mk_kernel_prot(user_prot); maddr = ioremap_prot(phys_addr, PAGE_ALIGN(len + offset), prot); if (!maddr) return -ENOMEM; -- 2.43.0
2 1
0 0
[PATCH OLK-6.6] drm/logicvc: Fix device node reference leak in logicvc_drm_config_parse()
by Jiacheng Yu 20 Apr '26

20 Apr '26
From: Felix Gu <ustc.gu(a)gmail.com> stable inclusion from stable-v6.6.130 commit 0bd326dffd9e103335d77d9c31275c0d5a7979eb category: bugfix bugzilla: http://atomgit.com/src-openeuler/kernel/issues/14066 CVE: CVE-2026-23426 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fef0e649f8b42bdffe4a916dd46e1b1e9ad2f207 ] The logicvc_drm_config_parse() function calls of_get_child_by_name() to find the "layers" node but fails to release the reference, leading to a device node reference leak. Fix this by using the __free(device_node) cleanup attribute to automatic release the reference when the variable goes out of scope. Fixes: efeeaefe9be5 ("drm: Add support for the LogiCVC display controller") Signed-off-by: Felix Gu <ustc.gu(a)gmail.com> Reviewed-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> Reviewed-by: Kory Maincent <kory.maincent(a)bootlin.com> Link: https://patch.msgid.link/20260130-logicvc_drm-v1-1-04366463750c@gmail.com Signed-off-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Jiacheng Yu <yujiacheng3(a)huawei.com> --- drivers/gpu/drm/logicvc/logicvc_drm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/logicvc/logicvc_drm.c b/drivers/gpu/drm/logicvc/logicvc_drm.c index 749debd3d6a57..df74572e6d2ea 100644 --- a/drivers/gpu/drm/logicvc/logicvc_drm.c +++ b/drivers/gpu/drm/logicvc/logicvc_drm.c @@ -90,7 +90,6 @@ static int logicvc_drm_config_parse(struct logicvc_drm *logicvc) struct device *dev = drm_dev->dev; struct device_node *of_node = dev->of_node; struct logicvc_drm_config *config = &logicvc->config; - struct device_node *layers_node; int ret; logicvc_of_property_parse_bool(of_node, LOGICVC_OF_PROPERTY_DITHERING, @@ -126,7 +125,8 @@ static int logicvc_drm_config_parse(struct logicvc_drm *logicvc) if (ret) return ret; - layers_node = of_get_child_by_name(of_node, "layers"); + struct device_node *layers_node __free(device_node) = + of_get_child_by_name(of_node, "layers"); if (!layers_node) { drm_err(drm_dev, "Missing non-optional layers node\n"); return -EINVAL; -- 2.43.0
2 1
0 0
[PATCH OLK-6.6] perf/core: Fix race between perf_event_exit_task and perf_pending_task
by Luo Gengkun 20 Apr '26

20 Apr '26
Offering: HULK hulk inclusion category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14165 -------------------------------- A race condition exists between perf_event_exit_task() and perf_pending_task(). During begin_new_exec(), perf_event_exit_task() may be called, and the PF_EXITING flag is not set on task. so perf_sigtrap() continues to execute and triggers WARN_ON_ONCE(event->ctx->task != current). To fix this problem, also check if the event->ctx->task is TASK_TOMBSTONE. Fixes: 97ba62b27867 ("perf: Add support for SIGTRAP on perf events") Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index cdd34d6e3dd4..7657ddf008ce 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -6782,7 +6782,7 @@ static void perf_sigtrap(struct perf_event *event) * Both perf_pending_task() and perf_pending_irq() can race with the * task exiting. */ - if (current->flags & PF_EXITING) + if (current->flags & PF_EXITING || event->ctx->task == TASK_TOMBSTONE) return; /* -- 2.34.1
2 1
0 0
[PATCH OLK-6.6 0/2] ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz
by Pan Taixi 20 Apr '26

20 Apr '26
Backport "ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz" to OLK-6.6 Include "xsk: introduce helper to determine rxq->frag_size" to introduce the helper function xsk_pool_get_rx_frag_step() Larysa Zaremba (2): xsk: introduce helper to determine rxq->frag_size ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz drivers/net/ethernet/intel/ice/ice_base.c | 7 ++++--- include/net/xdp_sock_drv.h | 10 ++++++++++ 2 files changed, 14 insertions(+), 3 deletions(-) -- 2.34.1
2 1
0 0
[PATCH OLK-6.6 2/2] ice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz
by Pan Taixi 20 Apr '26

20 Apr '26
From: Larysa Zaremba <larysa.zaremba(a)intel.com> mainline inclusion from mainline-v7.0-rc3 commit e142dc4ef0f451b7ef99d09aaa84e9389af629d7 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14020/ CVE: CVE-2026-23377 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The only user of frag_size field in XDP RxQ info is bpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead of DMA write size. Different assumptions in ice driver configuration lead to negative tailroom. This allows to trigger kernel panic, when using XDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to 6912 and the requested offset to a huge value, e.g. XSK_UMEM__MAX_FRAME_SIZE * 100. Due to other quirks of the ZC configuration in ice, panic is not observed in ZC mode, but tailroom growing still fails when it should not. Use fill queue buffer truesize instead of DMA write size in XDP RxQ info. Fix ZC mode too by using the new helper. Fixes: 2fba7dc5157b ("ice: Add support for XDP multi-buffer on Rx side") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba(a)intel.com> Link: https://patch.msgid.link/20260305111253.2317394-5-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Conflicts: drivers/net/ethernet/intel/ice/ice_base.c [Adapted calculation of frag size. truesize is introduced into mainline in patch 93f53db9f9dc ("ice: switch to Page Pool"), which is not merged. Use frame_sz as the truesize of underlying buffer.] Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_base.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_base.c b/drivers/net/ethernet/intel/ice/ice_base.c index 9a0682b05c4f..1408089a6549 100644 --- a/drivers/net/ethernet/intel/ice/ice_base.c +++ b/drivers/net/ethernet/intel/ice/ice_base.c @@ -557,7 +557,7 @@ int ice_vsi_cfg_rxq(struct ice_rx_ring *ring) err = __xdp_rxq_info_reg(&ring->xdp_rxq, ring->netdev, ring->q_index, ring->q_vector->napi.napi_id, - ring->rx_buf_len); + ice_get_frame_sz(ring)); if (err) return err; } @@ -568,10 +568,11 @@ int ice_vsi_cfg_rxq(struct ice_rx_ring *ring) ring->rx_buf_len = xsk_pool_get_rx_frame_size(ring->xsk_pool); + u32 frag_size = xsk_pool_get_rx_frag_step(ring->xsk_pool); err = __xdp_rxq_info_reg(&ring->xdp_rxq, ring->netdev, ring->q_index, ring->q_vector->napi.napi_id, - ring->rx_buf_len); + frag_size); if (err) return err; err = xdp_rxq_info_reg_mem_model(&ring->xdp_rxq, @@ -588,7 +589,7 @@ int ice_vsi_cfg_rxq(struct ice_rx_ring *ring) err = __xdp_rxq_info_reg(&ring->xdp_rxq, ring->netdev, ring->q_index, ring->q_vector->napi.napi_id, - ring->rx_buf_len); + ice_get_frame_sz(ring)); if (err) return err; } -- 2.34.1
1 0
0 0
[PATCH OLK-6.6 1/2] xsk: introduce helper to determine rxq->frag_size
by Pan Taixi 20 Apr '26

20 Apr '26
From: Larysa Zaremba <larysa.zaremba(a)intel.com> stable inclusion from stable-v6.6.130 commit 183f940bdf9074f4fd7d32badeb0d73c93dc2070 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14020/ CVE: CVE-2026-23377 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 16394d80539937d348dd3b9ea32415c54e67a81b ] rxq->frag_size is basically a step between consecutive strictly aligned frames. In ZC mode, chunk size fits exactly, but if chunks are unaligned, there is no safe way to determine accessible space to grow tailroom. Report frag_size to be zero, if chunks are unaligned, chunk_size otherwise. Fixes: 24ea50127ecf ("xsk: support mbuf on ZC RX") Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov(a)intel.com> Signed-off-by: Larysa Zaremba <larysa.zaremba(a)intel.com> Link: https://patch.msgid.link/20260305111253.2317394-3-larysa.zaremba@intel.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Pan Taixi <pantaixi1(a)huawei.com> --- include/net/xdp_sock_drv.h | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/include/net/xdp_sock_drv.h b/include/net/xdp_sock_drv.h index 5425f7ad5ebd..e1e46de7a875 100644 --- a/include/net/xdp_sock_drv.h +++ b/include/net/xdp_sock_drv.h @@ -41,6 +41,11 @@ static inline u32 xsk_pool_get_rx_frame_size(struct xsk_buff_pool *pool) return xsk_pool_get_chunk_size(pool) - xsk_pool_get_headroom(pool); } +static inline u32 xsk_pool_get_rx_frag_step(struct xsk_buff_pool *pool) +{ + return pool->unaligned ? 0 : xsk_pool_get_chunk_size(pool); +} + static inline void xsk_pool_set_rxq_info(struct xsk_buff_pool *pool, struct xdp_rxq_info *rxq) { @@ -263,6 +268,11 @@ static inline u32 xsk_pool_get_rx_frame_size(struct xsk_buff_pool *pool) return 0; } +static inline u32 xsk_pool_get_rx_frag_step(struct xsk_buff_pool *pool) +{ + return 0; +} + static inline void xsk_pool_set_rxq_info(struct xsk_buff_pool *pool, struct xdp_rxq_info *rxq) { -- 2.34.1
1 0
0 0
[PATCH OLK-6.6] mm/numa_remote: set default distance between remote nodes to 255
by Jinjiang Tu 20 Apr '26

20 Apr '26
hulk inclusion category: other bugzilla: https://atomgit.com/openeuler/kernel/issues/8974 ---------------------------------------- Set default distance between remote nodes to 255, indicating unreachable. Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- drivers/base/numa_remote.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/numa_remote.c b/drivers/base/numa_remote.c index 19f16d265820..74eb87ac8b26 100644 --- a/drivers/base/numa_remote.c +++ b/drivers/base/numa_remote.c @@ -16,8 +16,8 @@ /* The default distance between local node and remote node */ #define REMOTE_TO_LOCAL_DISTANCE 100 -/* The default distance between two remtoe node */ -#define REMOTE_TO_REMOTE_DISTANCE 254 +/* The default distance between two remote node */ +#define REMOTE_TO_REMOTE_DISTANCE 255 bool numa_remote_enabled __ro_after_init; static bool numa_remote_nofallback_mode __ro_after_init; -- 2.43.0
2 1
0 0
[PATCH OLK-6.6 v8 0/2] kvm: arm64: Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 20 Apr '26

20 Apr '26
Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register. liqiqi (2): kvm: arm64: Add MIDR definitions and use MIDR to determine whether features are supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 4 + arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 110 +++------------------------ arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 14 insertions(+), 113 deletions(-) -- 2.43.0
2 3
0 0
  • ← Newer
  • 1
  • 2
  • 3
  • 4
  • ...
  • 2327
  • Older →

HyperKitty Powered by HyperKitty