linux-kernel - Re: maximum count of thermal zones and fans in 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]

Date:	Thu, 24 May 2007 00:20:19 -0400
From:	Len Brown <lenb@...nel.org>
To:	Nico Golde <nico@...lde.de>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: maximum count of thermal zones and fans in acpi?

On Wednesday 23 May 2007 13:07, Nico Golde wrote:
> Hi,
> I am currently implementing a general purpose shared library 
> for acpi focused on all the tools giving acpi information 
> like battery, thermal zones, fans, etc.

Note that /proc/acpi is going away in the long term.

The ideal is that things that are implemented via ACPI
should instead appear as generic features under sysfs
when possible.

There will still be some ACPI-specific things stuffed
into /sys/firmware/acpi -- but not the kind of useful-
to-the-user stuff that you are looking for.

> Since I was not able to find anything about it in the acpi 
> specs[0] (of course I didn't read every single page though)
> and with a quick look into the kernel sources I wondered if 
> there is a maximum count for thermal zones and fans in the 
> acpi implementation of the kernel.
> 
> Every acpi module just calls proc_mkdir for example:
>        acpi_device_dir(device) = proc_mkdir(acpi_device_bid(device),
>                                             acpi_thermal_dir);
> 
> struct proc_dir_entry *proc_mkdir_mode(const char *name, mode_t mode,
>                 struct proc_dir_entry *parent)
> {
>         struct proc_dir_entry *ent;
> 
>         ent = proc_create(&parent, name, S_IFDIR | mode, 2);

And this is a systematic bug in the ACPI code.
The "name" should _never_ be exposed to user-space.
Eg. all the names under, say /proc/acpi/*/*
are arbitrary strings created by the BIOS programmer.

They are meaningless to the user, except that they
are unique.  To answer your question, there is no limit
to instances of ACPI objects, such as the number of thermal zones.

cheers,
-Len

>         if (ent) {
>                 ent->proc_fops = &proc_dir_operations;
>                 ent->proc_iops = &proc_dir_inode_operations;
> 
>                 if (proc_register(parent, ent) < 0) {
>                         kfree(ent);
>                         ent = NULL;
>                 }
>         }
>         return ent;
> }
> 
> struct proc_dir_entry *proc_mkdir(const char *name,
>                 struct proc_dir_entry *parent)
> {
>         return proc_mkdir_mode(name, S_IRUGO | S_IXUGO, parent);
> }
> 
> 
> So is there no check for any max item count here?
> 
> I ask because I need to decide whether I want to allocate space for every
> acpi object or to use a fixed size array for them depending on the maximum
> item (where item is one device) count.
> 
> [0]: http://www.acpi.info/spec.htm
> 
> Kind regards
> Nico
> P.S. Please Cc me I am not subscribed
> 
-
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/