lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAEEQ3wnGUDW_dqbbhM8nLeDH0kL=s89=8x2ESYs=Nm6AMzkV4A@mail.gmail.com>
Date: Fri, 14 Nov 2025 10:12:41 +0800
From: yunhui cui <cuiyunhui@...edance.com>
To: Doug Anderson <dianders@...omium.org>
Cc: akpm@...ux-foundation.org, alex@...ti.fr, anup@...infault.org, 
	aou@...s.berkeley.edu, atish.patra@...ux.dev, catalin.marinas@....com, 
	johannes@...solutions.net, lihuafei1@...wei.com, mark.rutland@....com, 
	masahiroy@...nel.org, maz@...nel.org, mingo@...nel.org, 
	nicolas.schier@...ux.dev, palmer@...belt.com, paul.walmsley@...ive.com, 
	suzuki.poulose@....com, thorsten.blum@...ux.dev, wangjinchao600@...il.com, 
	will@...nel.org, yangyicong@...ilicon.com, zhanjie9@...ilicon.com, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-perf-users@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [External] Re: [PATCH v5 0/2] Add HARDLOCKUP_DETECTOR_PERF
 support for RISC-V

Hi Doug,

On Fri, Nov 14, 2025 at 6:51 AM Doug Anderson <dianders@...omium.org> wrote:
>
> Hi,
>
> On Mon, Nov 10, 2025 at 11:35 PM Yunhui Cui <cuiyunhui@...edance.com> wrote:
> >
> > After discussion [1],[2], hardlockup_perf cannot be completely replaced by
> > the hardlockup_buddy approach, so this patch is still being submitted.
> >
> > v1->v2:
> > The contents of arch/arm64/watchdog_hld.c are directly consolidated into
> > kernel/watchdog_perf.c.
> >
> >
> > v2->v3:
> > Add CONFIG_WATCHDOG_PERF_ADJUST_PERIOD to enclose the period update logic,
> > select it by default on arm64 and riscv, without affecting other arches
> > like x86 and PPC.
> >
> > v3->v4:
> > Place the line "select WATCHDOG_PERF_ADJUST_PERIOD if HARDLOCKUP_DETECTOR_PERF && CPU_FREQ"
> > in the Kconfig files for arm64 and riscv in one line, with no line breaks.
> >
> > v4->v5:
> > Remove __weak from hw_nmi_get_sample_period()
> >
> > Link: https://lore.kernel.org/all/CAD=FV=UEhVCD6JehQi1wor2sSmtTLDyf=37xfo-DOTK1=u1xzA@mail.gmail.com/ [1]
> > Link: https://lore.kernel.org/all/20250916145122.416128-1-wangjinchao600@gmail.com/ [2]
> >
> > Yunhui Cui (2):
> >   watchdog: move arm64 watchdog_hld into common code
> >   riscv: add HARDLOCKUP_DETECTOR_PERF support
> >
> >  arch/arm64/Kconfig               |  1 +
> >  arch/arm64/kernel/Makefile       |  1 -
> >  arch/arm64/kernel/watchdog_hld.c | 94 --------------------------------
> >  arch/riscv/Kconfig               |  3 +
> >  drivers/perf/arm_pmu.c           | 10 +++-
> >  drivers/perf/riscv_pmu_sbi.c     | 10 ++++
> >  include/linux/perf/arm_pmu.h     |  2 -
> >  kernel/watchdog_perf.c           | 83 ++++++++++++++++++++++++++++
> >  lib/Kconfig.debug                |  8 +++
> >  9 files changed, 114 insertions(+), 98 deletions(-)
> >  delete mode 100644 arch/arm64/kernel/watchdog_hld.c
>
> Perhaps you missed that (I think) Andrew had already dropped your v4
> due to the Kernel Test Robot finding a problem. See:
>
> https://lore.kernel.org/r/202510240701.eB6r97V3-lkp@intel.com
>
> I don't think you've fixed these problems in v5, have you? I think you
> need a v6 for it? I haven't dug all the way, but I'd suspect the
> compile error is if "HARDLOCKUP_DETECTOR_PERF" is defined but not
> "CPU_FREQ". Indeed, that matches the config in the report...
>

Thanks for the reminder. I indeed missed replying to the email dated
October 26th regarding the error "ld.lld: error: undefined symbol:
hw_nmi_get_sample_period".
We can fix it directly as follows:
-       select WATCHDOG_PERF_ADJUST_PERIOD if HARDLOCKUP_DETECTOR_PERF
&& CPU_FREQ
+       select WATCHDOG_PERF_ADJUST_PERIOD if HARDLOCKUP_DETECTOR_PERF
Because when CPU_FREQ is not defined, there is a stub function, and
the corresponding max_cpu_freq will be set to SAFE_MAX_CPU_FREQ.

>
> -Doug

Thanks,
Yunhui

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ