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: <04bff7a7-3901-4adc-9f6a-466627cc1a21@redhat.com>
Date: Tue, 6 Aug 2024 11:12:49 +0200
From: David Hildenbrand <david@...hat.com>
To: Yu Zhao <yuzhao@...gle.com>, Catalin Marinas <catalin.marinas@....com>,
 Will Deacon <will@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 David Rientjes <rientjes@...gle.com>,
 Douglas Anderson <dianders@...omium.org>,
 Frank van der Linden <fvdl@...gle.com>, Mark Rutland <mark.rutland@....com>,
 Muchun Song <muchun.song@...ux.dev>, Nanyong Sun <sunnanyong@...wei.com>,
 Yang Shi <yang@...amperecomputing.com>,
 linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/4] arm64: use IPIs to pause/resume remote CPUs

[...]

> +
> +void resume_remote_cpus(void)
> +{
> +	cpumask_t cpus_to_resume;
> +
> +	lockdep_assert_cpus_held();
> +	lockdep_assert_preemption_disabled();
> +
> +	cpumask_copy(&cpus_to_resume, cpu_online_mask);
> +	cpumask_clear_cpu(smp_processor_id(), &cpus_to_resume);
> +
> +	spin_lock(&cpu_pause_lock);
> +
> +	cpumask_setall(&resumed_cpus);
> +	/* A typical example for sleep and wake-up functions. */
> +	smp_mb();
> +	while (cpumask_intersects(&cpus_to_resume, &paused_cpus)) {
> +		sev();
> +		cpu_relax();
> +		barrier();
> +	}
>

I'm curious, is there a fundamental reason why we wait for paused CPUs 
to actually start running, or is it simply easier to get the 
implementation race-free, in particular when we have two 
pause_remote_cpus() calls shortly after each other and another remote 
CPU might still be on its way out of pause_local_cpu() from the first pause.

-- 
Cheers,

David / dhildenb


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ