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

Message-ID: <Pine.LNX.4.58.0703071806340.2556@be1.lrz>
Date:	Wed, 7 Mar 2007 18:09:09 +0100 (CET)
From:	Bodo Eggert <7eggert@....de>
To:	Jean Delvare <khali@...ux-fr.org>
cc:	Bodo Eggert <7eggert@....de>,
	David Hubbard <david.c.hubbard@...il.com>,
	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?

On Wed, 7 Mar 2007, Jean Delvare wrote:
> On Tue, 6 Mar 2007 21:40:19 +0100 (CET), Bodo Eggert wrote:

> > 1) I asume port allocations or ACPI foreign port acces to be rare, so
> >    there would be little impact on (un)registering hardware. Off cause
> >    there are some long ACPI calls (like reading the battery?), in these
> >    cases it might be beneficial to release the global allocation lock
> >    after gaining exclusive access to the driver's port range. (This can
> >    only be done if the device driver is loaded.)
> 
> The problem is that the rarity of ACPI foreign port access doesn't
> matter much, as you have to do all the tests first to find out that it
> was a foreign port, and I suspect that these tests will cost more than
> taking the lock itself.

Testing for the internal ranges can be done by searching a list of about
five ranges, that should be not much slower than taking an uncontended
lock, and very much faster than waiting for smbus to finish it's current
task in case the lock is contended. I'm more concerned about driver
(un)loading being slowed down by ACPI.

[...]
> We may be able to workaround the inter-driver exclusion though, if we
> use a semaphore initialized to N, have ACPI take N, but other drivers
> take just one. This would let ACPI be exclusive with all the other
> drivers, but drivers themselves could otherwise run concurrently. That
> being said, we do not appear to have the required primitives to take
> more than 1 semaphore resource at once at the moment, so we'd need to
> do that first.

worst case I can imagine: IDE/graphic stalles while ACPI takes a second to
read the battery state.

-- 
Top 100 things you don't want the sysadmin to say:
82. Where's the DIR command?
-
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/