linux-kernel - Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

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:	Tue, 6 Mar 2007 16:10:02 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	"David Hubbard" <david.c.hubbard@...il.com>
Cc:	"Rudolf Marek" <r.marek@...embler.cz>,
	"Matthew Garrett" <mjg59@...f.ucam.org>,
	Ebbert <cebbert@...hat.com>, Chuck@...pms.net,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-acpi@...r.kernel.org, Machek <pavel@....cz>,
	Pavel@...pms.net, lm-sensors@...sensors.org
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

Hi David,

On Mon, 5 Mar 2007 13:35:20 -0800, David Hubbard wrote:
> > 2* It seems to incur a signficant performance penalty.
> > ____request_resource isn't cheap as far as I know. And in the
> > absence of conflict, you are even allocating and releasing the resource
> > on _each_ I/O operation, which certainly isn't cheap either. Again, it
> > is not a blocker point, after all this is a workaround for an improper
> > behavior of the acpi subsystem, this performance penalty is the price to
> > pay. But there is also a performance penalty for legitimate I/O access,
> > which worries me more.
> 
> I thought Rudolf's patch allocated the resource in the driver
> (w83627ehf) and ACPI contacted the driver when it could not allocate
> the resource. Since ACPI never *really* wants to allocate the
> resource, is there a fast-path check it could do? This would help
> performance.

Alas, I don't think it can work safely. If ACPI doesn't actually
allocate the resource, there is a risk that another driver does so
between the conflict check and the I/O access. I believe this is the
reason why Rudolf used ____request_resource and not __check_region.

> I like the virtualized driver method (if it wasn't obvious!) but the
> global AML lock works also. It will be interesting to see profiling of
> both solutions.

In fact Rudolf's solution is nice for LPC chips, however I don't think
it can work with SMBus chips. It might intercept the accesses to the
SMBus master and be able to emulate it, even though this will be more
complex that the W83627EHF case, and I'm not sure about the PCI config
space. But ultimately we need to emulate all the chips behind the
SMBus, too. The drivers for these chips won't know if they are accessed
for real of through the emulation layer, so there is no way they'll
remember states, while they might have to (e.g. the W83781D has a bank
register too.)

The AML lock approach, OTOH, should work fine in all cases as long as
the context doesn't need to be remembered across AML "sections".

-- 
Jean Delvare
-
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/