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: Sat, 8 Jun 2024 13:27:30 +0000
From: "Luck, Tony" <tony.luck@...el.com>
To: Borislav Petkov <bp@...en8.de>
CC: "x86@...nel.org" <x86@...nel.org>, "Yu, Fenghua" <fenghua.yu@...el.com>,
	"Chatre, Reinette" <reinette.chatre@...el.com>, "Wieczor-Retman, Maciej"
	<maciej.wieczor-retman@...el.com>, Peter Newman <peternewman@...gle.com>,
	James Morse <james.morse@....com>, Babu Moger <babu.moger@....com>, "Drew
 Fustini" <dfustini@...libre.com>, Dave Martin <Dave.Martin@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"patches@...ts.linux.dev" <patches@...ts.linux.dev>
Subject: RE: [PATCH v3 1/2] cacheinfo: Add function to get cacheinfo for a
 given (cpu, cachelevel)

> And yeah, this is an abomination.
>
>> How much do you *REALLY* want that lockdep_assert_cpus_held() to be in <linux/cacheinfo.h>
>
> If we had an easy fix sure but this really is a nightmare after trying
> it a bit here too.

I tried something too. I moved the cpu hotplug lock bits out of <linux/cpu.h>
into their own file <linux/cpuhplock.h>. Made cpu.h include this new file to
keep things the same for anything that includes cpu.h.

In the change to cacheinfo.h I just include the new cpuhplock.h as all
it needs is the lockdep_assert_cpus_held() declaration.

I haven't heard back from lkp yet ... but it may be promising. Code
is the top three commits in:

git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux.git get_cpu_cacheinfo_level


Does this look like an OK direction?

Any better name for the new header?

While I'm moving those declarations, should I zap the "extern " from the
function ones to match current fashion for this (checkpatch barfs all over
them)?

-Tony

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ