linux-kernel - Re: [PATCH v4 4/6] kernel/watchdog: Adapt the watchdog

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <YodhoxG0xmfrNYoN@alley>
Date:   Fri, 20 May 2022 11:38:43 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Lecopzer Chen <lecopzer.chen@...iatek.com>
Cc:     linux-kernel@...r.kernel.org, acme@...nel.org,
        akpm@...ux-foundation.org, alexander.shishkin@...ux.intel.com,
        catalin.marinas@....com, davem@...emloft.net, jolsa@...hat.com,
        jthierry@...hat.com, keescook@...omium.org, kernelfans@...il.com,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        linux-perf-users@...r.kernel.org, mark.rutland@....com,
        masahiroy@...nel.org, matthias.bgg@...il.com, maz@...nel.org,
        mcgrof@...nel.org, mingo@...hat.com, namhyung@...nel.org,
        nixiaoming@...wei.com, peterz@...radead.org,
        sparclinux@...r.kernel.org, sumit.garg@...aro.org,
        wangqing@...o.com, will@...nel.org, yj.chiang@...iatek.com
Subject: Re: [PATCH v4 4/6] kernel/watchdog: Adapt the watchdog_hld interface
 for async model

On Thu 2022-04-28 00:13:38, Lecopzer Chen wrote:
> When lockup_detector_init()->watchdog_nmi_probe(), PMU may be not ready
> yet. E.g. on arm64, PMU is not ready until
> device_initcall(armv8_pmu_driver_init).  And it is deeply integrated
> with the driver model and cpuhp. Hence it is hard to push this
> initialization before smp_init().
> 
> But it is easy to take an opposite approach and try to initialize
> the watchdog once again later.
> The delayed probe is called using workqueues. It need to allocate
> memory and must be proceed in a normal context.
> The delayed probe is able to use if watchdog_nmi_probe() returns
> non-zero which means the return code returned when PMU is not ready yet.
> 
> Provide an API - retry_lockup_detector_init() for anyone who needs
> to delayed init lockup detector if they had ever failed at
> lockup_detector_init().
> 
> The original assumption is: nobody should use delayed probe after
> lockup_detector_check() which has __init attribute.
> That is, anyone uses this API must call between lockup_detector_init()
> and lockup_detector_check(), and the caller must have __init attribute
> 
> --- a/kernel/watchdog.c
> +++ b/kernel/watchdog.c
> +/*
> + * retry_lockup_detector_init - retry init lockup detector if possible.
> + *
> + * Retry hardlockup detector init. It is useful when it requires some
> + * functionality that has to be initialized later on a particular
> + * platform.
> + */
> +void __init retry_lockup_detector_init(void)
> +{
> +	/* Must be called before late init calls */
> +	if (!allow_lockup_detector_init_retry)
> +		return;
> +
> +	queue_work_on(__smp_processor_id(), system_wq, &detector_work);

Just a small nit. This can be simplified by calling:

	schedule_work(&detector_work);

It uses "system_wq" that uses CPU-bound workers. It prefers
the current CPU. But the exact CPU is not important. Any CPU-bound
worker is enough.

> +}
> +

With the above change, feel free to use:

Reviewed-by: Petr Mladek <pmladek@...e.com>

Best Regards,
Petr

PS: I am sorry for the late review. I had busy weeks.