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 -----
  • 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

  • 50 participants
  • 23122 discussions
[PATCH openEuler-1.0-LTS] mm/huge_memory: fix folio isn't locked in softleaf_to_folio()
by Jinjiang Tu 31 Mar '26

31 Mar '26
mainline inclusion from mainline-v7.0-rc6 commit 4c5e7f0fcd592801c9cc18f29f80fbee84eb8669 category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/8836 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: CPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang(a)huawei.com: update function name and comments] Link: https://lkml.kernel.org/r/20260321075214.3305564-1-tujinjiang@huawei.com Link: https://lkml.kernel.org/r/20260319012541.4158561-1-tujinjiang@huawei.com Fixes: e9b61f19858a ("thp: reintroduce split_huge_page()") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Reviewed-by: Lorenzo Stoakes (Oracle) <ljs(a)kernel.org> Cc: Barry Song <baohua(a)kernel.org> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: include/linux/leafops.h include/linux/swapops.h [miragtion entry hasn't been renamed to softleaf entry.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- include/linux/swapops.h | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/include/linux/swapops.h b/include/linux/swapops.h index 22af9d8a84ae..c742e778e024 100644 --- a/include/linux/swapops.h +++ b/include/linux/swapops.h @@ -205,14 +205,28 @@ static inline unsigned long migration_entry_to_pfn(swp_entry_t entry) return swp_offset(entry); } -static inline struct page *migration_entry_to_page(swp_entry_t entry) +static inline void migration_entry_sync_page(struct page *head) { - struct page *p = pfn_to_page(swp_offset(entry)); + /* + * Ensure we do not race with split, which might alter tail pages into new + * head pages and thus result in observing an unlocked page. + * This matches the write barrier in __split_huge_page_tail(). + */ + smp_rmb(); + /* * Any use of migration entries may only occur while the * corresponding page is locked */ - BUG_ON(!PageLocked(compound_head(p))); + BUG_ON(!PageLocked(head)); +} + +static inline struct page *migration_entry_to_page(swp_entry_t entry) +{ + struct page *p = pfn_to_page(swp_offset(entry)); + + migration_entry_sync_page(compound_head(p)); + return p; } -- 2.43.0
2 1
0 0
[PATCH OLK-5.10] mm/huge_memory: fix folio isn't locked in softleaf_to_folio()
by Jinjiang Tu 31 Mar '26

31 Mar '26
mainline inclusion from mainline-v7.0-rc6 commit 4c5e7f0fcd592801c9cc18f29f80fbee84eb8669 category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/8836 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: CPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang(a)huawei.com: update function name and comments] Link: https://lkml.kernel.org/r/20260321075214.3305564-1-tujinjiang@huawei.com Link: https://lkml.kernel.org/r/20260319012541.4158561-1-tujinjiang@huawei.com Fixes: e9b61f19858a ("thp: reintroduce split_huge_page()") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Reviewed-by: Lorenzo Stoakes (Oracle) <ljs(a)kernel.org> Cc: Barry Song <baohua(a)kernel.org> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: include/linux/leafops.h include/linux/swapops.h mm/filemap.c [miragtion entry hasn't been renamed to softleaf entry. Add new helper migration_entry_to_compound_page().] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- include/linux/swapops.h | 31 ++++++++++++++++++++++++++++--- mm/filemap.c | 2 +- 2 files changed, 29 insertions(+), 4 deletions(-) diff --git a/include/linux/swapops.h b/include/linux/swapops.h index e749c4c86b26..ed33367fb6a6 100644 --- a/include/linux/swapops.h +++ b/include/linux/swapops.h @@ -194,17 +194,42 @@ static inline unsigned long migration_entry_to_pfn(swp_entry_t entry) return swp_offset(entry); } -static inline struct page *migration_entry_to_page(swp_entry_t entry) +static inline void migration_entry_sync_page(struct page *head) { - struct page *p = pfn_to_page(swp_offset(entry)); + /* + * Ensure we do not race with split, which might alter tail pages into new + * head pages and thus result in observing an unlocked page. + * This matches the write barrier in __split_huge_page_tail(). + */ + smp_rmb(); + /* * Any use of migration entries may only occur while the * corresponding page is locked */ - BUG_ON(!PageLocked(compound_head(p))); + BUG_ON(!PageLocked(head)); +} + +static inline struct page *migration_entry_to_page(swp_entry_t entry) +{ + struct page *p = pfn_to_page(swp_offset(entry)); + + migration_entry_sync_page(compound_head(p)); + return p; } +static inline struct page *migration_entry_to_compound_page(swp_entry_t entry) +{ + struct page *p = pfn_to_page(swp_offset(entry)); + struct page *head; + + head = compound_head(p); + migration_entry_sync_page(head); + + return head; +} + static inline void make_migration_entry_read(swp_entry_t *entry) { *entry = swp_entry(SWP_MIGRATION_READ, swp_offset(*entry)); diff --git a/mm/filemap.c b/mm/filemap.c index 18e304ce6229..c2932db70212 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -1334,7 +1334,7 @@ void migration_entry_wait_on_locked(swp_entry_t entry, pte_t *ptep, bool delayacct = false; unsigned long pflags = 0; wait_queue_head_t *q; - struct page *page = compound_head(migration_entry_to_page(entry)); + struct page *page = migration_entry_to_compound_page(entry); q = page_waitqueue(page); if (!PageUptodate(page) && PageWorkingset(page)) { -- 2.43.0
2 1
0 0
[PATCH OLK-6.6] mm/huge_memory: fix folio isn't locked in softleaf_to_folio()
by Jinjiang Tu 31 Mar '26

31 Mar '26
mainline inclusion from mainline-v7.0-rc6 commit 4c5e7f0fcd592801c9cc18f29f80fbee84eb8669 category: bugfix bugzilla: https://gitcode.com/openeuler/kernel/issues/8836 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- On arm64 server, we found folio that get from migration entry isn't locked in softleaf_to_folio(). This issue triggers when mTHP splitting and zap_nonpresent_ptes() races, and the root cause is lack of memory barrier in softleaf_to_folio(). The race is as follows: CPU0 CPU1 deferred_split_scan() zap_nonpresent_ptes() lock folio split_folio() unmap_folio() change ptes to migration entries __split_folio_to_order() softleaf_to_folio() set flags(including PG_locked) for tail pages folio = pfn_folio(softleaf_to_pfn(entry)) smp_wmb() VM_WARN_ON_ONCE(!folio_test_locked(folio)) prep_compound_page() for tail pages In __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smp_wmb() should be paired with smp_rmb() in softleaf_to_folio(), which is missed. As a result, if zap_nonpresent_ptes() accesses migration entry that stores tail pfn, softleaf_to_folio() may see the updated compound_head of tail page before page->flags. This issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio() because of the race between folio split and zap_nonpresent_ptes() leading to a folio incorrectly undergoing modification without a folio lock being held. This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1. To fix it, add missing smp_rmb() if the softleaf entry is migration entry in softleaf_to_folio() and softleaf_to_page(). [tujinjiang(a)huawei.com: update function name and comments] Link: https://lkml.kernel.org/r/20260321075214.3305564-1-tujinjiang@huawei.com Link: https://lkml.kernel.org/r/20260319012541.4158561-1-tujinjiang@huawei.com Fixes: e9b61f19858a ("thp: reintroduce split_huge_page()") Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> Acked-by: David Hildenbrand (Arm) <david(a)kernel.org> Reviewed-by: Lorenzo Stoakes (Oracle) <ljs(a)kernel.org> Cc: Barry Song <baohua(a)kernel.org> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Nanyong Sun <sunnanyong(a)huawei.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: include/linux/leafops.h include/linux/swapops.h [miragtion entry hasn't been renamed to softleaf entry.] Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- include/linux/swapops.h | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/include/linux/swapops.h b/include/linux/swapops.h index b32d696242b6..7bb5937a3f3c 100644 --- a/include/linux/swapops.h +++ b/include/linux/swapops.h @@ -500,15 +500,28 @@ static inline int is_userswap_entry(swp_entry_t entry) } #endif -static inline struct page *pfn_swap_entry_to_page(swp_entry_t entry) +static inline void migration_entry_sync(struct folio *folio) { - struct page *p = pfn_to_page(swp_offset_pfn(entry)); + /* + * Ensure we do not race with split, which might alter tail pages into new + * folios and thus result in observing an unlocked folio. + * This matches the write barrier in __split_folio_to_order(). + */ + smp_rmb(); /* * Any use of migration entries may only occur while the * corresponding page is locked */ - BUG_ON(is_migration_entry(entry) && !PageLocked(p)); + BUG_ON(!folio_test_locked(folio)); +} + +static inline struct page *pfn_swap_entry_to_page(swp_entry_t entry) +{ + struct page *p = pfn_to_page(swp_offset_pfn(entry)); + + if (is_migration_entry(entry)) + migration_entry_sync(page_folio(p)); return p; } @@ -517,11 +530,8 @@ static inline struct folio *pfn_swap_entry_folio(swp_entry_t entry) { struct folio *folio = pfn_folio(swp_offset_pfn(entry)); - /* - * Any use of migration entries may only occur while the - * corresponding folio is locked - */ - BUG_ON(is_migration_entry(entry) && !folio_test_locked(folio)); + if (is_migration_entry(entry)) + migration_entry_sync(folio); return folio; } -- 2.43.0
2 1
0 0
[PATCH OLK-6.6 v4 0/2] kvm: arm64: Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 31 Mar '26

31 Mar '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/cache.h | 2 +- arch/arm64/include/asm/cputype.h | 8 +- arch/arm64/kernel/cpu_errata.c | 4 +- arch/arm64/kernel/cpufeature.c | 2 +- arch/arm64/kernel/proton-pack.c | 4 +- arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++-------------------- arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- drivers/perf/hisilicon/hisi_uncore_pmu.c | 2 +- tools/arch/arm64/include/asm/cputype.h | 4 +- 10 files changed, 26 insertions(+), 124 deletions(-) -- 2.43.0
2 7
0 0
[PATCH OLK-5.10] xfs: fix internal error from AGFL exhaustion
by Long Li 31 Mar '26

31 Mar '26
From: Omar Sandoval <osandov(a)fb.com> mainline inclusion from mainline-v6.7-rc1 commit f63a5b3769ad7659da4c0420751d78958ab97675 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14036 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- We've been seeing XFS errors like the following: XFS: Internal error i != 1 at line 3526 of file fs/xfs/libxfs/xfs_btree.c. Caller xfs_btree_insert+0x1ec/0x280 ... Call Trace: xfs_corruption_error+0x94/0xa0 xfs_btree_insert+0x221/0x280 xfs_alloc_fixup_trees+0x104/0x3e0 xfs_alloc_ag_vextent_size+0x667/0x820 xfs_alloc_fix_freelist+0x5d9/0x750 xfs_free_extent_fix_freelist+0x65/0xa0 __xfs_free_extent+0x57/0x180 ... This is the XFS_IS_CORRUPT() check in xfs_btree_insert() when xfs_btree_insrec() fails. After converting this into a panic and dissecting the core dump, I found that xfs_btree_insrec() is failing because it's trying to split a leaf node in the cntbt when the AG free list is empty. In particular, it's failing to get a block from the AGFL _while trying to refill the AGFL_. If a single operation splits every level of the bnobt and the cntbt (and the rmapbt if it is enabled) at once, the free list will be empty. Then, when the next operation tries to refill the free list, it allocates space. If the allocation does not use a full extent, it will need to insert records for the remaining space in the bnobt and cntbt. And if those new records go in full leaves, the leaves (and potentially more nodes up to the old root) need to be split. Fix it by accounting for the additional splits that may be required to refill the free list in the calculation for the minimum free list size. P.S. As far as I can tell, this bug has existed for a long time -- maybe back to xfs-history commit afdf80ae7405 ("Add XFS_AG_MAXLEVELS macros ...") in April 1994! It requires a very unlucky sequence of events, and in fact we didn't hit it until a particular sparse mmap workload updated from 5.12 to 5.19. But this bug existed in 5.12, so it must've been exposed by some other change in allocation or writeback patterns. It's also much less likely to be hit with the rmapbt enabled, since that increases the minimum free list size and is unlikely to split at the same time as the bnobt and cntbt. Reviewed-by: "Darrick J. Wong" <djwong(a)kernel.org> Reviewed-by: Dave Chinner <dchinner(a)redhat.com> Signed-off-by: Omar Sandoval <osandov(a)fb.com> Signed-off-by: Chandan Babu R <chandanbabu(a)kernel.org> Conflicts: fs/xfs/libxfs/xfs_alloc.c [Context conflicts] Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/libxfs/xfs_alloc.c | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c index 23c0e666d2f4..15dce9276d45 100644 --- a/fs/xfs/libxfs/xfs_alloc.c +++ b/fs/xfs/libxfs/xfs_alloc.c @@ -2328,16 +2328,37 @@ xfs_alloc_min_freelist( ASSERT(mp->m_ag_maxlevels > 0); + /* + * For a btree shorter than the maximum height, the worst case is that + * every level gets split and a new level is added, then while inserting + * another entry to refill the AGFL, every level under the old root gets + * split again. This is: + * + * (full height split reservation) + (AGFL refill split height) + * = (current height + 1) + (current height - 1) + * = (new height) + (new height - 2) + * = 2 * new height - 2 + * + * For a btree of maximum height, the worst case is that every level + * under the root gets split, then while inserting another entry to + * refill the AGFL, every level under the root gets split again. This is + * also: + * + * 2 * (current height - 1) + * = 2 * (new height - 1) + * = 2 * new height - 2 + */ + /* space needed by-bno freespace btree */ min_free = min_t(unsigned int, levels[XFS_BTNUM_BNOi] + 1, - mp->m_ag_maxlevels); + mp->m_ag_maxlevels) * 2 - 2; /* space needed by-size freespace btree */ min_free += min_t(unsigned int, levels[XFS_BTNUM_CNTi] + 1, - mp->m_ag_maxlevels); + mp->m_ag_maxlevels) * 2 - 2; /* space needed reverse mapping used space btree */ if (xfs_has_rmapbt(mp)) min_free += min_t(unsigned int, levels[XFS_BTNUM_RMAPi] + 1, - mp->m_rmap_maxlevels); + mp->m_rmap_maxlevels) * 2 - 2; return min_free; } -- 2.39.2
2 1
0 0
[PATCH OLK-6.6 v3 0/3] kvm: arm64: Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 31 Mar '26

31 Mar '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 (3): kvm: arm64: Add HIP08, HIP10, HIP10C MIDR definitions kvm: arm64: use MIDR to determine whether features are supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cache.h | 2 +- arch/arm64/include/asm/cputype.h | 8 +- arch/arm64/kernel/cpu_errata.c | 4 +- arch/arm64/kernel/cpufeature.c | 2 +- arch/arm64/kernel/proton-pack.c | 4 +- arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++-------------------- arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- drivers/perf/hisilicon/hisi_uncore_pmu.c | 2 +- tools/arch/arm64/include/asm/cputype.h | 4 +- 10 files changed, 26 insertions(+), 124 deletions(-) -- 2.43.0
2 4
0 0
[PATCH OLK-6.6] time/jiffies: Mark jiffies_64_to_clock_t() notrace
by Liu Kai 31 Mar '26

31 Mar '26
From: Steven Rostedt <rostedt(a)goodmis.org> mainline inclusion from mainline-v7.0-rc4 commit 755a648e78f12574482d4698d877375793867fa1 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8837 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The trace_clock_jiffies() function that handles the "uptime" clock for tracing calls jiffies_64_to_clock_t(). This causes the function tracer to constantly recurse when the tracing clock is set to "uptime". Mark it notrace to prevent unnecessary recursion when using the "uptime" clock. Fixes: 58d4e21e50ff3 ("tracing: Fix wraparound problems in "uptime" trace clock") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Link: https://patch.msgid.link/20260306212403.72270bb2@robin Signed-off-by: Liu Kai <liukai284(a)huawei.com> --- kernel/time/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/time.c b/kernel/time/time.c index 1ad88e97b4eb..da7e8a02a096 100644 --- a/kernel/time/time.c +++ b/kernel/time/time.c @@ -702,7 +702,7 @@ EXPORT_SYMBOL(clock_t_to_jiffies); * * Return: jiffies_64 value converted to 64-bit "clock_t" (CLOCKS_PER_SEC) */ -u64 jiffies_64_to_clock_t(u64 x) +notrace u64 jiffies_64_to_clock_t(u64 x) { #if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0 # if HZ < USER_HZ -- 2.34.1
2 1
0 0
[PATCH OLK-6.6 0/2] arm-smmu-v3: add HIP09A, HIP09B, HIP10C, HIP10CA for 162100602 errata
by Zeng Heng 31 Mar '26

31 Mar '26
Qinxin Xia (2): arm-smmu-v3: add HIP09A, HIP09B, HIP10C, HIP10CA for 162100602 errata ACPI/IORT: Add PMCG platform information for 162001900 drivers/acpi/arm64/iort.c | 4 ++++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 6 ++++++ 2 files changed, 10 insertions(+) -- 2.25.1
1 1
0 0
[PATCH OLK-5.10] time/jiffies: Mark jiffies_64_to_clock_t() notrace
by Liu Kai 31 Mar '26

31 Mar '26
From: Steven Rostedt <rostedt(a)goodmis.org> mainline inclusion from mainline-v7.0-rc4 commit 755a648e78f12574482d4698d877375793867fa1 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8837 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The trace_clock_jiffies() function that handles the "uptime" clock for tracing calls jiffies_64_to_clock_t(). This causes the function tracer to constantly recurse when the tracing clock is set to "uptime". Mark it notrace to prevent unnecessary recursion when using the "uptime" clock. Fixes: 58d4e21e50ff3 ("tracing: Fix wraparound problems in "uptime" trace clock") Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Thomas Gleixner <tglx(a)kernel.org> Link: https://patch.msgid.link/20260306212403.72270bb2@robin Conflicts: kernel/time/time.c [Context conflict] Signed-off-by: Liu Kai <liukai284(a)huawei.com> --- kernel/time/time.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/time.c b/kernel/time/time.c index 3985b2b32d08..22551ee392e4 100644 --- a/kernel/time/time.c +++ b/kernel/time/time.c @@ -649,7 +649,7 @@ unsigned long clock_t_to_jiffies(unsigned long x) } EXPORT_SYMBOL(clock_t_to_jiffies); -u64 jiffies_64_to_clock_t(u64 x) +notrace u64 jiffies_64_to_clock_t(u64 x) { #if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0 # if HZ < USER_HZ -- 2.34.1
2 1
0 0
[PATCH OLK-6.6 v2 0/3] kvm: arm64: Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 31 Mar '26

31 Mar '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 and removes the need for defining CPU types and their related interfaces. liqiqi (3): kvm: arm64: Add HIP08, HIP10, HIP10C MIDR definitions kvm: arm64: use MIDR to determine whether features are supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cache.h | 2 +- arch/arm64/include/asm/cputype.h | 8 +- arch/arm64/kernel/cpu_errata.c | 4 +- arch/arm64/kernel/cpufeature.c | 2 +- arch/arm64/kernel/proton-pack.c | 4 +- arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 111 +++---------------------- arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- tools/arch/arm64/include/asm/cputype.h | 4 +- 9 files changed, 25 insertions(+), 123 deletions(-) -- 2.43.0
2 4
0 0
  • ← Newer
  • 1
  • 2
  • 3
  • 4
  • ...
  • 2313
  • Older →

HyperKitty Powered by HyperKitty