linux-kernel - Re: [PATCH v2 0/5] Cavium ThunderX uncore PMU support

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: <20160425131907.GB30830@arm.com>
Date:	Mon, 25 Apr 2016 14:19:07 +0100
From:	Will Deacon <will.deacon@....com>
To:	Jan Glauber <jan.glauber@...iumnetworks.com>
Cc:	Mark Rutland <mark.rutland@....com>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 0/5] Cavium ThunderX uncore PMU support

On Mon, Apr 25, 2016 at 02:02:22PM +0200, Jan Glauber wrote:
> On Mon, Apr 25, 2016 at 12:22:07PM +0100, Will Deacon wrote:
> > On Mon, Apr 04, 2016 at 02:19:54PM +0200, Jan Glauber wrote:
> > > can you have a look at these patches?
> > 
> > Looks like Mark reviewed this last week -- are you planning to respin?
> 
> Yes, of course. I just had no time yet and I'm a bit lost on how to
> proceed without using the NUMA node information which Mark did not like
> to be used.
> 
> The only way to know which device is on which node would be to look
> at the PCI topology (which is also the source of the NUMA node_id).
> We could do this manually in order to not depend on CONFIG_NUMA,
> but I would like to know if that is acceptable before respinning the
> patches.

That doesn't feel like it really addresses Mark's concerns -- it's just
another way to get the information that isn't a first-class PMU topology
description from firmware.

Now, I don't actually mind using the NUMA topology so much in the cases
where it genuinely correlates with the PMU topology. My objection is more
that we end up sticking everything on node 0 if !CONFIG_NUMA, which could
result in working with an incorrect PMU topology and passing all of that
through to userspace.

So I'd prefer either making the driver depend on NUMA, or at the very least
failing to probe  the PMU if we discover a socketed system and NUMA is not
selected. Do either of those work as a compromise?

Will