linux-kernel - Re: [PATCH v4 3/3] powerpc/powernv: Introduce sysfs control for fastsleep workaround behavior

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: <552CCF5E.5040201@linux.vnet.ibm.com>
Date:	Tue, 14 Apr 2015 13:57:10 +0530
From:	Preeti U Murthy <preeti@...ux.vnet.ibm.com>
To:	"Shreyas B. Prabhu" <shreyas@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org,
	Michael Ellerman <mpe@...erman.id.au>,
	"benh@...nel.crashing.org" <benh@...nel.crashing.org>
CC:	linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v4 3/3] powerpc/powernv: Introduce sysfs control for fastsleep
 workaround behavior

Hi Shreyas,

On 04/14/2015 07:26 AM, Shreyas B. Prabhu wrote:
> +	 * fastsleep_workaround_state = WORKAROUND_APPLYONCE implies
> +	 * fastsleep workaround needs to be left in 'applied' state on all
> +	 * the cores. Do this by-
> +	 * 1. Patching out the call to 'undo' workaround in fastsleep exit path
> +	 * 2. Sending ipi to all the cores which have atleast one online thread
> +	 * 3. Patching out the call to 'apply' workaround in fastsleep entry
> +	 * path
> +	 * There is no need to send ipi to cores which have all threads
> +	 * offlined, as last thread of the core entering fastsleep or deeper
> +	 * state would have applied workaround.
> +	 */
> +	err = patch_instruction(
> +		(unsigned int *)pnv_fastsleep_workaround_at_exit,
> +		PPC_INST_NOP);
> +	if (err) {
> +		pr_err("fastsleep_workaround_state change failed while patching pnv_fastsleep_workaround_at_exit");
> +		goto fail;
> +	}
> +
> +	primary_thread_mask = cpu_online_cores_map();
> +	on_each_cpu_mask(&primary_thread_mask,
> +				pnv_fastsleep_workaround_apply,
> +				&err, 1);
> +	if (err) {
> +		pr_err("fastsleep_workaround_state change failed while running pnv_fastsleep_workaround_apply");
> +		goto fail;
> +	}
> +
> +	err = patch_instruction(
> +		(unsigned int *)pnv_fastsleep_workaround_at_entry,
> +		PPC_INST_NOP);
> +	if (err) {
> +		pr_err("fastsleep_workaround_state change failed while patching pnv_fastsleep_workaround_at_entry");
> +		goto fail;
> +	}

A point that bothers me here is if we can potentially race with cpu
hotplug ? If cpuX and its siblings are offline and it was interrupted to
come online:

cpuX                                     cpuY
Interrupted to come online
Undo workaround

                                Nop the fastsleep_workaround_exit path
                                IPI online cores: apply workaround once

Set yourself in the online mask
                                Nop the fastsleep_workaround_entry path


This results in cpuX undoing the workaround on its core, never to set it
back again.

So should we protect the region between the beginning and end of
patching instructions with get_online_cpus() and put_online_cpus() ?

Regards
Preeti U Murthy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/