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

Date:	Fri, 15 Nov 2013 16:42:23 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Peter Zijlstra <peterz@...radead.org>
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 01:33:37PM +0100, Peter Zijlstra wrote:
> On Fri, Nov 15, 2013 at 04:10:51PM +0400, Cyrill Gorcunov wrote:
> > On Fri, Nov 15, 2013 at 12:51:50PM +0100, Peter Zijlstra wrote:
> > > 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.
> > 
> > The events are sensitive to which cpu they're scheduled to execute on
> > (if HT is turned on, we need to setup thread bit in register).
> > As far as I understand once events are assigned to cpu_hw_events
> > they are executing on this cpu, when tasks are migrated to another
> > cpu, they're re-scheduled. Or I miss something obvious here?
> 
> No this is correct, but that is simply about event encoding, right?

Yes, sorry for not mentioning it earlier.

> 
> The situation we should be avoiding is:
> 
>  {x, y, z}
> 
> being a valid event group on ht0 but an invalid group for ht1.

I see. No, this can't happen. (The idea of using cpu here is to
split the whole set of perf registers available on a core [which
are shared between HT threads]  into two set, one half used for thread 1
and second half used for thread 2 only).

> 
> So the whole fake_cpuc / validate_{event,group} code that triggered this
> isn't actually scheduling them, its testing to see if all the provided
> events could possibly be scheduled together -- and we would want to
> avoid giving a sibling dependent answer here.

Yes, I looked into fake_cpuc, and our @cpu variable used in p4_pmu_schedule_events
will simply either answer us "ok, there is enough registers to carry
all events requested", either it will decline events if no space left.
--
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/