linux-kernel - [BUG?] Moving drivers to drivers/cpufreq/ causes all to be loaded

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]

Message-ID: <20110813154638.GA1494@elie.gateway.2wire.net>
Date:	Sat, 13 Aug 2011 10:46:38 -0500
From:	Jonathan Nieder <jrnieder@...il.com>
To:	Dave Jones <davej@...hat.com>
Cc:	cpufreq@...r.kernel.org, linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Arnd Bergmann <arnd@...db.de>,
	Tony Lindgren <tony@...mide.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Mattia Dongili <malattia@...ian.org>
Subject: [BUG?] Moving drivers to drivers/cpufreq/ causes all to be loaded

(-cc: linux-arm-kernel, +cc: linux-kernel, Mattia)
Hi,

Dave Jones wrote:

> in cpufreq.next I moved the x86 drivers over.  Someone look it over ?

Some people[1] have been seeing regressions after this change (when
moving from 2.6.39 to 3.0, presumably from commit bb0a56ecc4ba,
"[CPUFREQ] Move x86 drivers to drivers/cpufreq/").  The first symptom
was messages at boot:

| Loading cpufreq kernel modules...FATAL: Error inserting powernow_k7 (/lib/modules/3.0.0-1-486/kernel/drivers/cpufreq/powernow-k7.ko): No such device
| FATAL: Error inserting speedstep_ich (/lib/modules/3.0.0-1-486/kernel/drivers/cpufreq/speedstep-ich.ko): No such device
| FATAL: Error inserting acpi_cpufreq (/lib/modules/3.0.0-1-486/kernel/drivers/cpufreq/acpi-cpufreq.ko): Device or resource busy
[etc]

The second symptom was the wrong cpufreq driver being loaded
(p4-clockmod instead of acpi-cpufreq).  The cause seems to be some
code in init scripts that originated in powernowd 0.97-2ubuntu1 (2007)
or some time before that:

|         #get list of available modules (governors and helpers)
|         LOC="/lib/modules/$(uname -r)/kernel/drivers/cpufreq"
|         if [ -d $LOC ]; then
|           MODAVAIL=$( ( find $LOC -type f -name "*.o" -printf "basename %f .o\n"; \
|               find $LOC -type f -name "*.ko" -printf "basename %f .ko\n" ) | /bin/sh)
|         else
|           MODAVAIL=""
|         fi
| 
|         #echo "Loading cpufreq modules:"
|         for mod in $MODAVAIL; do
|         #        echo "     $mod"
|                 echo $LIST| grep -q -w "$mod" || modprobe $mod >/dev/null || /bin/true
|         done

This takes all kernel modules in drivers/cpufreq, blindly assumes
they must be governors or helpers, and loads them.  Nowadays it is
in the loadcpufreq script in cpufrequtils; so in cpufrequtils 007-2
(03 Aug 2011), the pattern changed to drivers/cpufreq/cpufreq_*.ko
which just matches the governors and helpers and everybody's happy.

Except:

 (1) This is still incredibly fragile.  What *should* cpufrequtils
     be doing to get the drivers it needs?

 (2) Using the 3.0 or later kernel with old userspace gives bad
     results (e.g., 30% increase in power consumption for one
     reporter).  That's a regression.  Bad kernel, no biscuit.

Ideas?

[1] http://bugs.debian.org/635348
--
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/