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]
Date:   Wed, 5 Sep 2018 13:29:05 +0100
From:   Will Deacon <will.deacon@....com>
To:     Zhizhou Zhang <zhizhouzhang@...micro.com>
Cc:     catalin.marinas@....com, james.morse@....com,
        julien.thierry@....com, dave.martin@....com,
        suzuki.poulose@....com, sudeep.holla@....com, adobriyan@...il.com,
        lorenzo.pieralisi@....com, mark.rutland@....com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: don't account for cpu offline time with irqsoff
 tracer

On Wed, Sep 05, 2018 at 04:19:43PM +0800, Zhizhou Zhang wrote:
> This is no need to account for cpu offline time with irqsoff tracer.
> We can trigger a large irqsoff latency with below commands:
> 
> $ echo irqsoff > /sys/kernel/debug/tracing/current_tracer
> $ echo 0 > /sys/kernel/debug/tracing/options/function-trace
> $ echo 1 > /sys/kernel/debug/tracing/tracing_on
> $ echo 0 > /sys/devices/system/cpu/cpu1/online
> $ # wait a while ...
> $ echo 1 > /sys/devices/system/cpu/cpu1/online
> $ cat /sys/kernel/debug/tracing/trace
> 
> Signed-off-by: Zhizhou Zhang <zhizhouzhang@...micro.com>
> ---
>  arch/arm64/kernel/smp.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 25fcd22..faed8f6 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -346,6 +346,7 @@ void cpu_die(void)
>  	idle_task_exit();
>  
>  	local_daif_mask();
> +	stop_critical_timings();
>  
>  	/* Tell __cpu_die() that this CPU is now safe to dispose of */
>  	(void)cpu_report_death();
> -- 
> 1.9.1

Hmm, so there are only a handful of other callers of stop_critical_timings()
which suggests that we probably shouldn't be calling this from deep in the
arch code. Do other architectures have the same problem? If not, how do they
avoid it?

Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ