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]

Message-Id: <20070304115440.b212d7ff.khali@linux-fr.org>
Date:	Sun, 4 Mar 2007 11:54:40 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	"David Hubbard" <david.c.hubbard@...il.com>
Cc:	"Matthew Garrett" <mjg59@...f.ucam.org>,
	"Pavel Machek" <pavel@....cz>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	lm-sensors@...sensors.org, linux-acpi@...r.kernel.org,
	"Chuck Ebbert" <cebbert@...hat.com>, Rudolf@...pms.net
Subject: Re: [lm-sensors] Could the k8temp driver be interfering with ACPI?

Hi David,

On Sat, 3 Mar 2007 08:47:21 -0700, David Hubbard wrote:
> > Is there anything preventing us from doing such a walk and pre-allocate
> > all the I/O ranges? I am not familiar with the ACPI code at all, would
> > you possibly propose a patch doing that?
> 
> Here's a random idea -- what do you think of it?
> 
> ACPI already allocates some I/O ranges, which was a surprise to me:
> 
> > My machine looks like this:
> >
> > 1000-107f : 0000:00:1f.0
> >  1000-1003 : ACPI PM1a_EVT_BLK
> >  1004-1005 : ACPI PM1a_CNT_BLK
> >  1008-100b : ACPI PM_TMR
> >  1010-1015 : ACPI CPU throttle
> >  1020-1020 : ACPI PM2_CNT_BLK
> >  1028-102b : ACPI GPE0_BLK
> >  102c-102f : ACPI GPE1_BLK
> 
> For I/O and memory that ACPI accesses and has not reserved, the AML
> interpreter could allocate at run-time.
> 
> I'm not sure how to implement exactly. For example, it would be bad to
> have a /proc/ioports that had a lot of single ports allocated, for
> example:
> 1000-107f : 0000:00:1f.0
>  1000-1000 : ACPI PM1a_EVT_BLK
>  1001-1001 : ACPI PM1a_EVT_BLK
>  1002-1002 : ACPI PM1a_EVT_BLK
>  1003-1003 : ACPI PM1a_EVT_BLK
> 
> Thus the AML interpreter would need to have some reasonable
> intelligence when allocating regions. Conflict resolution would also
> be more difficult, e.g. if a hwmon driver was loaded first and then
> acpi as a module, ACPI could not allocate the region. Maybe run-time
> allocating won't work.
> 
> And then, how would ACPI release a region after it has used it? The
> easiest method would be to never release anything used even once.

I've been thinking about it too, but I could convince myself quickly
that it would never work, so I didn't bother posting about it ;)

As you found out yourself, it isn't trivial to allocate the ports
dynamically. Either you'll end up with lots of 1-address ranges, or
you'll allocate more than is actually needed, or you'll need a
buddy-allocator like mechanism to merge contiguous ranges. This sounds
quite complex to get right. And very costly, too. I don't know the
exact algorithm to find out whether an I/O range is already allocated
or not, and by who, but having to do it for each port access from AML,
forever, sounds like a huge overhead.

On top of that, there is a risk that another driver already requested
the I/O range. And we do not want to prevent ACPI from accessing it!
OK, it would be cleaner that the current situation in a way, but it
could also have bad consequences as was underlined elsewhere in this
thread.

What we want is to grant access to the resources to at least ACPI (and
ACPI only if we can't do better), or if possible to both ACPI and
individual drivers but with some mechanism avoiding concurrent access
(be it a mutex or a port forwarder.)

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