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-next>] [day] [month] [year] [list]

Date:	Mon, 05 Mar 2007 14:56:44 +0100
From:	Bodo Eggert <7eggert@....de>
To:	David Hubbard <david.c.hubbard@...il.com>,
	Jean Delvare <khali@...ux-fr.org>,
	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?

David Hubbard <david.c.hubbard@...il.com> wrote:

> 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.
> 
> Thoughts?

1) Make a general resource allocation lock, if there is none.
2) make ACPI take this lock whenever it touches ports not allocated by itself
   and release it on function return.
3) Make ACPI callback the allocating device if it touches allocated ranges,
   and on function return.

1 + 2 will replace allocating single ports and freeing them again (so ACPI won't
prevent e.g. the display driver from loading just because it turned on the
backlight) while preventing races with newly allocated ranges, and 3 allows
coexistence with other drivers.
-- 
The problem with the easy way out is that it has already been mined. 

Friß, Spammer: TKF8@...oImLG.7eggert.dyndns.org
 lG@...f0g.7eggert.dyndns.org hffltUu@...8pBwc.7eggert.dyndns.org
-
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/