December 2023 - Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 v3 0/7] arm64: Add support to turn an IPI as NMI
by Liao Chen 22 Dec '23

22 Dec '23

With pseudo NMIs support available its possible to configure SGIs to be triggered as pseudo NMIs running in NMI context. And kernel features such as: - NMI backtrace can leverage IPI turned as NMI to get a backtrace of CPU stuck in hard lockup using magic SYSRQ. - kgdb relies on NMI support to round up CPUs which are stuck in hard lockup state with interrupts disabled. This patch-set adds framework to turn an IPI as NMI which can be triggered as a pseudo NMI which in turn invokes registered NMI handlers. After this patch-set we should be able to get a backtrace for a CPU stuck in HARDLOCKUP. Sumit Garg (7): arm64: Add framework to turn IPI as NMI irqchip/gic-v3: Enable support for SGIs to act as NMIs arm64: smp: Assign and setup an IPI as NMI nmi: backtrace: Allow runtime arch specific override arm64: ipi_nmi: Add support for NMI backtrace kgdb: Expose default CPUs roundup fallback mechanism arm64: kgdb: Roundup cpus using IPI as NMI arch/arm/include/asm/irq.h | 2 +- arch/arm/kernel/smp.c | 3 +- arch/arm64/include/asm/irq.h | 6 +++ arch/arm64/include/asm/nmi.h | 17 +++++++ arch/arm64/kernel/Makefile | 2 +- arch/arm64/kernel/ipi_nmi.c | 84 ++++++++++++++++++++++++++++++++ arch/arm64/kernel/kgdb.c | 18 +++++++ arch/arm64/kernel/smp.c | 8 +++ arch/mips/include/asm/irq.h | 2 +- arch/mips/kernel/process.c | 3 +- arch/powerpc/include/asm/irq.h | 2 +- arch/powerpc/kernel/stacktrace.c | 3 +- arch/sparc/include/asm/irq_64.h | 2 +- arch/sparc/kernel/process_64.c | 4 +- arch/x86/include/asm/irq.h | 2 +- arch/x86/kernel/apic/hw_nmi.c | 3 +- drivers/irqchip/irq-gic-v3.c | 29 ++++++++--- include/linux/kgdb.h | 12 +++++ include/linux/nmi.h | 12 ++--- kernel/debug/debug_core.c | 8 ++- 20 files changed, 194 insertions(+), 28 deletions(-) create mode 100644 arch/arm64/include/asm/nmi.h create mode 100644 arch/arm64/kernel/ipi_nmi.c -- 2.34.1

2 8

[PATCH v2 openEuler-1.0-LTS] umh: fix memory leak on execve failure
by Wenyu Huang 22 Dec '23

22 Dec '23

From: Vincent Minet <v.minet(a)criteo.com> mainline inclusion from mainline-v5.10-rc1 commit db803036ada7d61d096783726f9771b3fc540370 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8J9MA CVE: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------------------------------------- If a UMH process created by fork_usermode_blob() fails to execute, a pair of struct file allocated by umh_pipe_setup() will leak. Under normal conditions, the caller (like bpfilter) needs to manage the lifetime of the UMH and its two pipes. But when fork_usermode_blob() fails, the caller doesn't really have a way to know what needs to be done. It seems better to do the cleanup ourselves in this case. Fixes: 449325b52b7a ("umh: introduce fork_usermode_blob() helper") Signed-off-by: Vincent Minet <v.minet(a)criteo.com> Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Wenyu Huang <huangwenyu5(a)huawei.com> --- kernel/umh.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/umh.c b/kernel/umh.c index 53611efb10cb..715b4368f9ed 100644 --- a/kernel/umh.c +++ b/kernel/umh.c @@ -495,6 +495,12 @@ static void umh_clean_and_save_pid(struct subprocess_info *info) { struct umh_info *umh_info = info->data; + /* cleanup if umh_pipe_setup() was successful but exec failed */ + if (info->pid && info->retval) { + fput(umh_info->pipe_to_umh); + fput(umh_info->pipe_from_umh); + } + argv_free(info->argv); umh_info->pid = info->pid; } -- 2.34.1

2 1

[PATCH OLK-6.6 0/3] files cgroups feature
by chenridong 22 Dec '23

22 Dec '23

Binder Makin (1): cgroups: Resource controller for open files Hou Tao (1): cgroup/files: fix bugs as mentioned Lu Jialin (1): enable CONFIG_CGROUP_FILES in openeuler_defconfig for x86 and arm64 .../admin-guide/kernel-parameters.txt | 7 +- arch/arm64/configs/openeuler_defconfig | 1 + arch/x86/configs/openeuler_defconfig | 1 + fs/Makefile | 1 + fs/file.c | 68 +++- fs/filescontrol.c | 312 ++++++++++++++++++ include/linux/cgroup-defs.h | 8 +- include/linux/cgroup_subsys.h | 4 + include/linux/fdtable.h | 1 + include/linux/filescontrol.h | 40 +++ init/Kconfig | 10 + 11 files changed, 445 insertions(+), 8 deletions(-) create mode 100644 fs/filescontrol.c create mode 100644 include/linux/filescontrol.h -- 2.34.1

2 4

[PATCH OLK-6.6 v2 0/7] arm64: Add support to turn an IPI as NMI
by Liao Chen 22 Dec '23

22 Dec '23

With pseudo NMIs support available its possible to configure SGIs to be triggered as pseudo NMIs running in NMI context. And kernel features such as: - NMI backtrace can leverage IPI turned as NMI to get a backtrace of CPU stuck in hard lockup using magic SYSRQ. - kgdb relies on NMI support to round up CPUs which are stuck in hard lockup state with interrupts disabled. This patch-set adds framework to turn an IPI as NMI which can be triggered as a pseudo NMI which in turn invokes registered NMI handlers. After this patch-set we should be able to get a backtrace for a CPU stuck in HARDLOCKUP. Sumit Garg (7): arm64: Add framework to turn IPI as NMI irqchip/gic-v3: Enable support for SGIs to act as NMIs arm64: smp: Assign and setup an IPI as NMI nmi: backtrace: Allow runtime arch specific override arm64: ipi_nmi: Add support for NMI backtrace kgdb: Expose default CPUs roundup fallback mechanism arm64: kgdb: Roundup cpus using IPI as NMI arch/arm/include/asm/irq.h | 2 +- arch/arm/kernel/smp.c | 3 +- arch/arm64/include/asm/irq.h | 6 +++ arch/arm64/include/asm/nmi.h | 17 +++++++ arch/arm64/kernel/Makefile | 2 +- arch/arm64/kernel/ipi_nmi.c | 84 ++++++++++++++++++++++++++++++++ arch/arm64/kernel/kgdb.c | 18 +++++++ arch/arm64/kernel/smp.c | 8 +++ arch/mips/include/asm/irq.h | 2 +- arch/mips/kernel/process.c | 3 +- arch/powerpc/include/asm/irq.h | 2 +- arch/powerpc/kernel/stacktrace.c | 3 +- arch/sparc/include/asm/irq_64.h | 2 +- arch/sparc/kernel/process_64.c | 4 +- arch/x86/include/asm/irq.h | 2 +- arch/x86/kernel/apic/hw_nmi.c | 3 +- drivers/irqchip/irq-gic-v3.c | 29 ++++++++--- include/linux/kgdb.h | 12 +++++ include/linux/nmi.h | 12 ++--- kernel/debug/debug_core.c | 8 ++- 20 files changed, 194 insertions(+), 28 deletions(-) create mode 100644 arch/arm64/include/asm/nmi.h create mode 100644 arch/arm64/kernel/ipi_nmi.c -- 2.34.1

2 8

[PATCH openEuler-22.03-LTS-SP2] tick/broadcast-hrtimer: Prevent the timer device on broadcast duty CPU from being disabled
by Yu Liao 22 Dec '23

22 Dec '23

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8PL17 CVE: NA ---------------------------------------- It was found that running the LTP hotplug stress test on a aarch64 system could produce rcu_sched stall warnings. The issue is the following: CPU1 (owns the broadcast hrtimer) CPU2 tick_broadcast_enter() //shut down local timer device ... tick_broadcast_exit() //exits with tick_broadcast_force_mask set, timer device remains disabled initiates offlining of CPU1 take_cpu_down() //CPU1 shuts down and does not send broadcast IPI anymore takedown_cpu() hotplug_cpu__broadcast_tick_pull() //move broadcast hrtimer to this CPU clockevents_program_event() bc_set_next() hrtimer_start() //does not call hrtimer_reprogram() to program timer device if expires equals dev->next_event, so the timer device remains disabled. CPU2 takes over the broadcast duty but local timer device is disabled, causing many CPUs to become stuck. Fix this by calling tick_program_event() to reprogram the local timer device in this scenario. Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- kernel/time/tick-broadcast-hrtimer.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/kernel/time/tick-broadcast-hrtimer.c b/kernel/time/tick-broadcast-hrtimer.c index b5a65e212df2..b8e79f8012f3 100644 --- a/kernel/time/tick-broadcast-hrtimer.c +++ b/kernel/time/tick-broadcast-hrtimer.c @@ -42,6 +42,8 @@ static int bc_shutdown(struct clock_event_device *evt) */ static int bc_set_next(ktime_t expires, struct clock_event_device *bc) { + struct clock_event_device *dev = __this_cpu_read(tick_cpu_device.evtdev); + /* * This is called either from enter/exit idle code or from the * broadcast handler. In all cases tick_broadcast_lock is held. @@ -62,6 +64,18 @@ static int bc_set_next(ktime_t expires, struct clock_event_device *bc) * hrtimer_start() can call into tracing. */ RCU_NONIDLE( { + + /* + * This can be called from CPU offline operation to move broadcast + * assignment. If tick_broadcast_force_mask is set, the CPU local + * timer device may be disabled. And hrtimer_reprogram() will not + * called if the timer is not the first expiring timer. Reprogram + * the cpu local timer device to ensure we can take over the + * broadcast duty. + */ + if (tick_check_broadcast_expired() && expires >= dev->next_event) + clockevents_program_event(dev, dev->next_event, 1); + hrtimer_start(&bctimer, expires, HRTIMER_MODE_ABS_PINNED_HARD); /* * The core tick broadcast mode expects bc->bound_on to be set -- 2.33.0

2 1

[PATCH OLK-6.6 0/7] Support Features to Turn an IPI as NMI
by Liao Chen 22 Dec '23

22 Dec '23

With pseudo NMIs support available its possible to configure SGIs to be triggered as pseudo NMIs running in NMI context. And kernel features such as: - NMI backtrace can leverage IPI turned as NMI to get a backtrace of CPU stuck in hard lockup using magic SYSRQ. - kgdb relies on NMI support to round up CPUs which are stuck in hard lockup state with interrupts disabled. This patch-set adds framework to turn an IPI as NMI which can be triggered as a pseudo NMI which in turn invokes registered NMI handlers. After this patch-set we should be able to get a backtrace for a CPU stuck in HARDLOCKUP. Sumit Garg (7): arm64: Add framework to turn IPI as NMI irqchip/gic-v3: Enable support for SGIs to act as NMIs arm64: smp: Assign and setup an IPI as NMI nmi: backtrace: Allow runtime arch specific override arm64: ipi_nmi: Add support for NMI backtrace kgdb: Expose default CPUs roundup fallback mechanism arm64: kgdb: Roundup cpus using IPI as NMI arch/arm/include/asm/irq.h | 2 +- arch/arm/kernel/smp.c | 3 +- arch/arm64/include/asm/irq.h | 6 +++ arch/arm64/include/asm/nmi.h | 17 +++++++ arch/arm64/kernel/Makefile | 4 +- arch/arm64/kernel/ipi_nmi.c | 84 ++++++++++++++++++++++++++++++++ arch/arm64/kernel/kgdb.c | 18 +++++++ arch/arm64/kernel/smp.c | 8 +++ arch/mips/include/asm/irq.h | 2 +- arch/powerpc/kernel/stacktrace.c | 3 +- arch/sparc/include/asm/irq_64.h | 2 +- arch/sparc/kernel/process_64.c | 4 +- arch/x86/include/asm/irq.h | 2 +- arch/x86/kernel/apic/hw_nmi.c | 3 +- drivers/irqchip/irq-gic-v3.c | 29 ++++++++--- include/linux/kgdb.h | 12 +++++ include/linux/nmi.h | 12 ++--- kernel/debug/debug_core.c | 8 ++- 18 files changed, 192 insertions(+), 27 deletions(-) create mode 100644 arch/arm64/include/asm/nmi.h create mode 100644 arch/arm64/kernel/ipi_nmi.c -- 2.34.1

2 8

[PATCH OLK-6.6 v2 0/2] optimize inline
by Yuntao Liu 21 Dec '23

21 Dec '23

*** BLURB HERE *** Guo Xuenan (2): Revert "compiler: remove CONFIG_OPTIMIZE_INLINING entirely" make OPTIMIZE_INLINING config editable arch/arm64/kvm/sys_regs.h | 5 +++++ arch/x86/configs/i386_defconfig | 1 + arch/x86/configs/x86_64_defconfig | 1 + drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h | 5 +++++ .../pci/hive_isp_css_include/print_support.h | 4 ++++ include/linux/compiler_types.h | 8 ++++++++ include/trace/trace_events.h | 2 +- kernel/configs/tiny.config | 1 + lib/Kconfig.debug | 13 +++++++++++++ 9 files changed, 39 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH OLK-6.6 v2 0/2] optimize inline
by Yuntao Liu 21 Dec '23

21 Dec '23

*** BLURB HERE *** Guo Xuenan (2): Revert "compiler: remove CONFIG_OPTIMIZE_INLINING entirely" make OPTIMIZE_INLINING config editable arch/arm64/kvm/sys_regs.h | 5 +++++ arch/x86/configs/i386_defconfig | 1 + arch/x86/configs/x86_64_defconfig | 1 + drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h | 5 +++++ .../pci/hive_isp_css_include/print_support.h | 4 ++++ include/linux/compiler_types.h | 8 ++++++++ include/trace/trace_events.h | 2 +- kernel/configs/tiny.config | 1 + lib/Kconfig.debug | 13 +++++++++++++ 9 files changed, 39 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH OLK-5.10] tick/broadcast-hrtimer: Prevent the timer device on broadcast duty CPU from being disabled
by Yu Liao 21 Dec '23

21 Dec '23

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8PL17 CVE: NA ---------------------------------------- It was found that running the LTP hotplug stress test on a aarch64 system could produce rcu_sched stall warnings. The issue is the following: CPU1 (owns the broadcast hrtimer) CPU2 tick_broadcast_enter() //shut down local timer device ... tick_broadcast_exit() //exits with tick_broadcast_force_mask set, timer device remains disabled initiates offlining of CPU1 take_cpu_down() //CPU1 shuts down and does not send broadcast IPI anymore takedown_cpu() hotplug_cpu__broadcast_tick_pull() //move broadcast hrtimer to this CPU clockevents_program_event() bc_set_next() hrtimer_start() //does not call hrtimer_reprogram() to program timer device if expires equals dev->next_event, so the timer device remains disabled. CPU2 takes over the broadcast duty but local timer device is disabled, causing many CPUs to become stuck. Fix this by calling tick_program_event() to reprogram the local timer device in this scenario. Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- kernel/time/tick-broadcast-hrtimer.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/kernel/time/tick-broadcast-hrtimer.c b/kernel/time/tick-broadcast-hrtimer.c index b5a65e212df2..b8e79f8012f3 100644 --- a/kernel/time/tick-broadcast-hrtimer.c +++ b/kernel/time/tick-broadcast-hrtimer.c @@ -42,6 +42,8 @@ static int bc_shutdown(struct clock_event_device *evt) */ static int bc_set_next(ktime_t expires, struct clock_event_device *bc) { + struct clock_event_device *dev = __this_cpu_read(tick_cpu_device.evtdev); + /* * This is called either from enter/exit idle code or from the * broadcast handler. In all cases tick_broadcast_lock is held. @@ -62,6 +64,18 @@ static int bc_set_next(ktime_t expires, struct clock_event_device *bc) * hrtimer_start() can call into tracing. */ RCU_NONIDLE( { + + /* + * This can be called from CPU offline operation to move broadcast + * assignment. If tick_broadcast_force_mask is set, the CPU local + * timer device may be disabled. And hrtimer_reprogram() will not + * called if the timer is not the first expiring timer. Reprogram + * the cpu local timer device to ensure we can take over the + * broadcast duty. + */ + if (tick_check_broadcast_expired() && expires >= dev->next_event) + clockevents_program_event(dev, dev->next_event, 1); + hrtimer_start(&bctimer, expires, HRTIMER_MODE_ABS_PINNED_HARD); /* * The core tick broadcast mode expects bc->bound_on to be set -- 2.33.0

2 1

[PATCH OLK-6.6] timekeeping: Avoiding false sharing in field access of tk_core
by Yu Liao 21 Dec '23

21 Dec '23

From: Wang ShaoBo <bobo.shaobowang(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I47W8L CVE: NA --------------------------- We detect a performance deterioration when using Unixbench, we use the dichotomy to locate the patch 7e66740ad725 ("MPAM / ACPI: Refactoring MPAM init process and set MPAM ACPI as entrance"), In comparing two commit df5defd901ff ("KVM: X86: MMU: Use the correct inherited permissions to get shadow page") and ac4dbb7554ef ("ACPI 6.x: Add definitions for MPAM table") we get following testing result: CMD: ./Run -c xx context1 RESULT: +-------------UnixBench context1-----------+ +---------+--------------+-----------------+ + + ac4dbb7554ef + df5defd901ff + +---------+--------------+---------+-------+ + Cores + Score + Score + +---------+--------------+-----------------+ + 1 + 522.8 + 535.7 + +---------+--------------+-----------------+ + 24 + 11231.5 + 12111.2 + +---------+--------------+-----------------+ + 48 + 8535.1 + 8745.1 + +---------+--------------+-----------------+ + 72 + 10821.9 + 10343.8 + +---------+--------------+-----------------+ + 96 + 15238.5 + 42947.8 + +---------+--------------+-----------------+ We found a irrefutable difference in latency sampling when using the perf tool: HEAD:ac4dbb7554ef HEAD:df5defd901ff 45.18% [kernel] [k] ktime_get_coarse_real_ts64 -> 1.78% [kernel] [k] ktime_get_coarse_real_ts64 ... 65.87 │ dmb ishld //smp_rmb() Through ftrace we get the calltrace and and detected the number of visits of ktime_get_coarse_real_ts64, which frequently visits tk_core->seq and tk_core->timekeeper->tkr_mono: - 48.86% [kernel] [k] ktime_get_coarse_real_ts64 - 5.76% ktime_get_coarse_real_ts64 #about 111437657 times per 10 seconds - 14.70% __audit_syscall_entry syscall_trace_enter el0_svc_common el0_svc_handler + el0_svc - 2.85% current_time So this may be performance degradation caused by interference when happened different fields access, We compare .bss and .data section of this two version: HEAD:ac4dbb7554ef `-> ffff00000962e680 l O .bss 0000000000000110 tk_core ffff000009355680 l O .data 0000000000000078 tk_fast_mono ffff0000093557a0 l O .data 0000000000000090 dummy_clock ffff000009355700 l O .data 0000000000000078 tk_fast_raw ffff000009355778 l O .data 0000000000000028 timekeeping_syscore_ops ffff00000962e640 l O .bss 0000000000000008 cycles_at_suspend HEAD:df5defd901ff `-> ffff00000957dbc0 l O .bss 0000000000000110 tk_core ffff0000092b4e80 l O .data 0000000000000078 tk_fast_mono ffff0000092b4fa0 l O .data 0000000000000090 dummy_clock ffff0000092b4f00 l O .data 0000000000000078 tk_fast_raw ffff0000092b4f78 l O .data 0000000000000028 timekeeping_syscore_ops ffff00000957db80 l O .bss 0000000000000008 cycles_at_suspend By comparing this two version tk_core's address: ffff00000962e680 is 128Byte aligned but latter df5defd901ff is 64Byte aligned, the memory storage layout of tk_core has undergone subtle changes: HEAD:ac4dbb7554ef `-> |<--------formmer 64Bytes---------->|<------------latter 64Byte------------->| 0xffff00000957dbc0_>|<-seq 8Bytes->|<-tkr_mono 56Bytes->|<-thr_raw 56Bytes->|<-xtime_sec 8Bytes->| 0xffff00000957dc00_>... HEAD:df5defd901ff `-> |<------formmer 64Bytes---->|<------------latter 64Byte-------->| 0xffff00000962e680_>|<-Other variables 64Bytes->|<-seq 8Bytes->|<-tkr_mono 56Bytes->| 0xffff00000962e6c0_>.. We testified thr_raw,xtime_sec fields interfere strongly with seq,tkr_mono field because of frequent load/store operation, this will cause as known false sharing. We add a 64Bytes padding field in tk_core for reservation of any after usefull usage and keep tk_core 128Byte aligned, this can avoid changes in the way tk_core's layout is stored, In this solution, layout of tk_core always like this: crash> struct -o tk_core_t struct tk_core_t { [0] u64 padding[8]; [64] seqcount_t seq; [72] struct timekeeper timekeeper; } SIZE: 336 crash> struct -o timekeeper struct timekeeper { [0] struct tk_read_base tkr_mono; [56] struct tk_read_base tkr_raw; [112] u64 xtime_sec; [120] unsigned long ktime_sec; ... } SIZE: 264 After appling our own solution: +---------+--------------+ + + Our solution + +---------+--------------+ + Cores + Score + +---------+--------------+ + 1 + 548.9 + +---------+--------------+ + 24 + 11018.3 + +---------+--------------+ + 48 + 8938.2 + +---------+--------------+ + 72 + 14610.7 + +---------+--------------+ + 96 + 40811.7 + +---------+--------------+ Signed-off-by: Wang ShaoBo <bobo.shaobowang(a)huawei.com> Signed-off-by: Yu Liao <liaoyu15(a)huawei.com> --- arch/arm64/Kconfig | 9 +++++++++ arch/arm64/include/asm/cache.h | 6 ++++++ kernel/time/timekeeping.c | 7 +++++++ 3 files changed, 22 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 2aca373a7038..f5559e38b243 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1493,6 +1493,15 @@ config HW_PERF_EVENTS def_bool y depends on ARM_PMU +config ARCH_LLC_128_LINE_SIZE + bool "Force 128 bytes alignment for fitting LLC cacheline" + depends on ARM64 + default y + help + As specific machine's LLC cacheline size may be up to + 128 bytes, gaining performance improvement from fitting + 128 Bytes LLC cache aligned. + # Supported by clang >= 7.0 or GCC >= 12.0.0 config CC_HAVE_SHADOW_CALL_STACK def_bool $(cc-option, -fsanitize=shadow-call-stack -ffixed-x18) diff --git a/arch/arm64/include/asm/cache.h b/arch/arm64/include/asm/cache.h index 1613779be63a..8455df351ef8 100644 --- a/arch/arm64/include/asm/cache.h +++ b/arch/arm64/include/asm/cache.h @@ -8,6 +8,12 @@ #define L1_CACHE_SHIFT (6) #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT) +#ifdef CONFIG_ARCH_LLC_128_LINE_SIZE +#ifndef ____cacheline_aligned_128 +#define ____cacheline_aligned_128 __attribute__((__aligned__(128))) +#endif +#endif + #define CLIDR_LOUU_SHIFT 27 #define CLIDR_LOC_SHIFT 24 #define CLIDR_LOUIS_SHIFT 21 diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 266d02809dbb..35b366addf07 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -48,9 +48,16 @@ DEFINE_RAW_SPINLOCK(timekeeper_lock); * cache line. */ static struct { +#ifdef CONFIG_ARCH_LLC_128_LINE_SIZE + u64 padding[8]; +#endif seqcount_raw_spinlock_t seq; struct timekeeper timekeeper; +#ifdef CONFIG_ARCH_LLC_128_LINE_SIZE +} tk_core ____cacheline_aligned_128 = { +#else } tk_core ____cacheline_aligned = { +#endif .seq = SEQCNT_RAW_SPINLOCK_ZERO(tk_core.seq, &timekeeper_lock), }; -- 2.33.0

2 1

2024

2023

2022

2021

2020

2019

Kernel December 2023