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:	Sun, 18 Mar 2007 14:36:08 -0500
From:	"richardvoigt@...il.com" <richardvoigt@...il.com>
To:	"Jean Delvare" <khali@...ux-fr.org>
Cc:	"Matthew Garrett" <mjg59@...f.ucam.org>,
	"Pavel Machek" <pavel@....cz>, "Chuck Ebbert" <cebbert@...hat.com>,
	"Rudolf Marek" <r.marek@...embler.cz>, linux-acpi@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>,
	lm-sensors@...sensors.org
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

On 3/3/07, Jean Delvare <khali@...ux-fr.org> wrote:
> Hi Matthew,
>
> On Fri, 2 Mar 2007 21:12:51 +0000, Matthew Garrett wrote:
> > On Fri, Mar 02, 2007 at 10:04:54PM +0100, Jean Delvare wrote:
> > > It might be more elegant but it won't work. We don't want to prevent
> > > ACPI from accessing these I/O ports. If we need to choose only one
> > > "driver" accessing the I/O port, it must be acpi, at leat for now,
> > > despite the fact that acpi provides very weak hardware monitoring
> > > capabilities compared to the specific drivers.
> >
> > Assuming arbitration of access, what's the problem with having two
> > drivers accessing the same hardware? Do these chips generally have any
> > significant internal state other than trip points and the like?
>
> The "assuming arbitration of access" is the key part of your
> sentence ;) The problem is that currently no arbitration is done. If it
> was done, then state would probably not be a problem. Most hardware
> monitoring drivers don't assume any state is preserved between
> accesses, and those which do can easily be changed not to. The ACPI
> side is another story though, I guess we can't assume anything about
> the AML code's assumption on states, as it differs from one machine to
> the next. But we can try to be cooperative and restore the sensible
> registers (e.g. bank selector) in the same state we found them.

I recall that one of the stated drawbacks of a lock was that no ACPI
code could execute while the hwmon driver was doing its fairly lengthy
conversation with the hardware.

It seems that using transactional concepts here would solve that
problem.  For example, the hwmon driver issues a start transaction
request.  The first write request to any given location (bank register
for example) causes the previous memory value to be saved.  Then,
instead of locking AML out, AML is allowed to execute, but any access
to the memory/port ranges reserved by the driver (when the transaction
is set up) cause the hwmon transaction to be rolled back so the AML
sees the expected state.  Then AML proceeds as usual.  When hwmon
tries additional operations, they fail with some "transaction
interrupted" error message, indicating to the hwmon driver to start
over.

The only issue with this that I can see, is that if AML isn['t
executed atomically wrt hwmon, then knowing when it is safe for hwmon
to retry is going to be difficult.

This probably requires changes to every hwmon driver, but they can be
updated piecemeal, starting with the ones most commonly found in
notebooks, where ACPI is most important.
-
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/