linux-kernel - Re: [PATCH] AMD Thermal Interrupt 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: <20080105132402.GA705@one.firstfloor.org>
Date:	Sat, 5 Jan 2008 14:24:02 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Russell Leidich <rml@...gle.com>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Torsten Kaiser <just.for.lkml@...glemail.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, valdis.kletnieks@...edu,
	thockin@...gle.com
Subject: Re: [PATCH] AMD Thermal Interrupt Support

> 
> But if PCI locks are spinlocks, then how can one access config space
> in an interrupt handler, as it might be locked by the foreground?  (No

They disable interrupts

> locks would be required at all, if everyone just saved 0xCF8 and
> 0xCFC, but I digress.)  

Not sure what you mean? Since it is two non atomic accesses even
saving restoring the registers would not make the accesses safe for lockless.
If someone changes 0xcf8 before you can access 0xcfc you always have
a problem.

In fact we had (or still have) races with some older user land accessing these
ports directly.

The only access method that is lockless is mmconfig, which will work
on most (but not all) Fam10h systems.

> And it's one thing to be "likely" already in a
> thread, and another to be sure.  If you can address these issues, I'll
> change or remove the comment.  I just want to prevent a
> reasonable-looking but bad coding change from happening in the future.

Well at least as written the comment is not quite correct.
> 
> 
> Agreed.  I had it at the top of the function, but now I've worked it
> into both places.
> 
> >
> > Anyways I'm unsure about the blacklist here -- white list would
> > probably have been better. k8_northbridges[] will certainly include
> > Griffin northtbridges and who knows if TT will work there or not.
> > [sorry for mentioning that not earlier]
> 
> Ideally, every ID in the k8_northbridges[] whitelist would have

k8_northbridges[] is used by various subsystems, most of them
do not care at all about thermal throttling.

> functional thermal throttling.  If more IDs than 0x1103 turn out to
> have this feature broken, then we may need to add a blacklist as well.

? you already got a blacklist ? 

>  But I expect that most future IDs will function correctly, hence my
> reliance on the whitelist. 

? but you don't have a whitelist, you have a black list.

> In my view, anyone who adds an ID to a
> whitelist (or just a list, for that matter) is obligated to perform a
> static analysis (i.e. grep for "k8_northbridges") of the implications
> of such act; 

That view would require the whitelist.

-Andi
--
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/