linux-kernel - Re: perf code using smp_processor_id() in preemptible [00000000] code

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]

Date:	Fri, 15 Nov 2013 12:51:50 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Cyrill Gorcunov <gorcunov@...il.com>
Cc:	Dave Jones <davej@...hat.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: perf code using smp_processor_id() in preemptible [00000000] code

On Fri, Nov 15, 2013 at 03:30:46PM +0400, Cyrill Gorcunov wrote:

>  arch/x86/kernel/cpu/perf_event_p4.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6.git/arch/x86/kernel/cpu/perf_event_p4.c
> ===================================================================
> --- linux-2.6.git.orig/arch/x86/kernel/cpu/perf_event_p4.c
> +++ linux-2.6.git/arch/x86/kernel/cpu/perf_event_p4.c
> @@ -1207,7 +1207,7 @@ static int p4_pmu_schedule_events(struct
>  {
>  	unsigned long used_mask[BITS_TO_LONGS(X86_PMC_IDX_MAX)];
>  	unsigned long escr_mask[BITS_TO_LONGS(P4_ESCR_MSR_TABLE_SIZE)];
> -	int cpu = smp_processor_id();
> +	int cpu = get_cpu();
>  	struct hw_perf_event *hwc;
>  	struct p4_event_bind *bind;
>  	unsigned int i, thread, num;
> @@ -1267,6 +1267,7 @@ reserve:
>  	}
>  
>  done:
> +	put_cpu();
>  	return num ? -EINVAL : 0;
>  }

ok, this will make the error go away, but what about the semantics of
the case? Does it really matter for the grouping on which cpu we compute
it? That is can we end up with a different group for one cpu as for
another?

Or do we simply need a coherent single cpu to do the computation with?
In which case raw_smp_processor_id() would also suffice.

If we can indeed get a different result depending on which cpu we do the
computation, then things are broken, because it might be a task group
we're building which has to be able to migrate around with the task.

In that case we must compute the maximal group that can be scheduled on
all cpus.

This wasn't at all clear.
--
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/