linux-kernel - Re: [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-prev] [day] [month] [year] [list]

Date:	Sun, 14 Aug 2011 19:17:18 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Jonathan Nieder <jrnieder@...il.com>
Cc:	Dave Jones <davej@...hat.com>, cpufreq@...r.kernel.org,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	Mattia Dongili <malattia@...ian.org>
Subject: Re: [BUG?] Moving drivers to drivers/cpufreq/ causes all to be loaded

On Sun, Aug 14, 2011 at 19:01, Jonathan Nieder <jrnieder@...il.com> wrote:
> (-cc: ARM/etc people; +cc: Kay)
>
> Dave Jones wrote:
>
>> If we have to move stuff again, we could do drivers/cpufreq/x86/ etc..
>
> Unfortunately the old script used "find", not "ls", so that wouldn't
> work. :/
>
>> What we used to do in Fedora grew more and more complex over time.
>> Here's the last incarnation: http://fpaste.org/uvDb/
>
> The main difference from Debian seems to be that this script loads the
> module corresponding to the chosen governor, while Debian's init
> script loads all governor modules early (using a heuristic I would
> like to avoid that involves running "find" to list them) and chooses
> the governor to use later.

Right, loading cpufreq drivers from userspace is fragile, and can not
properly work today. Only the kernel itself know which driver to try
to bind in which order. Modular cpufreq kernel modules make no real
sense here with the infrastructure we have available today.

>> In an ideal world, we'd auto-load the right module on a hotplug event
>> from a cpu, but we're not there yet. I believe Kay is working on that.
>
> Yes, that is what I was hoping for.  Are there patches to test?

Yeah, it's on the TODO list, I just get too many 'really broken'
things get sorted on top all time. :) But it will happen in the next
months.

> The comment at
> http://thread.gmane.org/gmane.linux.kernel/796450/focus=796874 also
> looks promising.

That could work, but we better go right for the CPU specific aliases
and do not try to load all of them, even when for completely different
systems. That would just encode another workaround into kernel
modules, which we better solve properly.

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