linux-kernel - Re: linux-next: Tree for August 14 (sysfs/acpi errors)

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: <1218856798.3629.45.camel@lgn.site>
Date:	Sat, 16 Aug 2008 05:19:58 +0200
From:	Kay Sievers <kay.sievers@...y.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	gregkh <greg@...ah.com>, linux-next@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org,
	rusty@...tcorp.com.au
Subject: Re: linux-next: Tree for August 14 (sysfs/acpi errors)

On Sat, 2008-08-16 at 04:57 +0200, Andi Kleen wrote:
> >> Extract is:
> >>
> >> XXX adding modparam:'acpi.power_nocheck' 34 (ffffffff806a4cf0)
> > ...
> >> XXX adding modparam:'acpi.acpica_version' 45 (ffffffff806a4ea8)
> > 
> > Two different "modules" use the same prefix, which does not work with
> > the current logic, they need to live next to each other in the sequence
> > of options.
> 
> Sequence of options being defined by link order?

Yeah, they are stored in a global array __start___param, and the current
code expects the prefixes to be sorted, so the sysfs directories can be
created for every first new prefix.

> > This adds a new option:
> >   http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commitdiff;h=1382827e93799ec07790849e361267993cfe549e
> > which specifies MODULE_PARAM_PREFIX="acpi." in:
> >   drivers/acpi/power.c
> > In the same way as:
> >   drivers/acpi/system.c
> > 
> > Seems, two different modules should not declare parameters in different
> > locations, and use the same MODULE_PARAM_PREFIX.
> 
> That seems bogus to me. Assuming we have some code in a module and then split
> it out into two different modules. Or move an option from one file to another.
> Would we need to change the option name then?

They have been module options, not prefixed kernel parameters so far,
and the prefix was just the module name.
So it just strikes back, that acpi uses generic names for the modules,
there would have been no problem if "power" would be called "acpi_power"
and the options would just be "acpi.acpica_version" and
"acpi_power.nocheck".

But well, there are driver modules just called "option", so acpi is not
that bad. :)

> I think the generic params code should be fixed to handle this.

We could try to look up existing directories to use instead of expecting
that we need to create and own them. I guess, we have the same issue if
we compile the code as a module and load it later, while some other
built-in code or module has already used the same prefix.

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/