linux-kernel - Re: [PATCH] ACPI: don't walk tables if ACPI was disabled

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: <19f34abd0806201427h740ca3e7gc2f01c7e34616fd4@mail.gmail.com>
Date:	Fri, 20 Jun 2008 23:27:25 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Len Brown" <lenb@...nel.org>
Cc:	"Ingo Molnar" <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org, "Zhao Yakui" <yakui.zhao@...el.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"Alexey Starikovskiy" <astarikovskiy@...e.de>,
	"Yinghai Lu" <yhlu.kernel@...il.com>,
	"Bjorn Helgaas" <bjorn.helgaas@...com>
Subject: Re: [PATCH] ACPI: don't walk tables if ACPI was disabled

On Fri, Jun 20, 2008 at 10:40 PM, Vegard Nossum <vegard.nossum@...il.com> wrote:
> On Fri, Jun 20, 2008 at 9:00 PM, Len Brown <lenb@...nel.org> wrote:
>>> @@ -333,6 +333,9 @@ static int __init acpi_rtc_init(void)
>>>  {
>>>       struct device *dev = get_rtc_dev();
>>>
>>> +     if (acpi_disabled)
>>> +             return 0;
>>> +
>>
>> hmm, i would expect dev to be 0 for acpi=off,
>> since pnp_match would fail, no?
>
> Obviously not. Because Ingo is booting with acpi=off and he still gets
> a warning about some mutex operation that originates from this very
> initcall:
>
> [    3.976213] calling  acpi_rtc_init+0x0/0xd3
> [    3.980213] ACPI Exception (utmutex-0263): AE_BAD_PARAMETER, Thread
> F7C50000 could not acquire Mutex [3] [20080321]
>
>

Aha. The device in question (PNP0b00) is discovered while doing
pnpbios_init(), NOT pnpacpi_init:

[    1.712032] initcall pnpacpi_init+0x0/0x80 returned 0 after 3 msecs
[    1.716032] calling  pnpbios_init+0x0/0x322
[    1.720032] PnPBIOS: Scanning system for PnP BIOS support...
[    1.724032] PnPBIOS: Found PnP BIOS installation structure at 0xc00fc550
[    1.728032] PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xc580, dseg 0xf0000
...
[    1.876032] pnp 00:03: parse allocated resources
[    1.880032] pnp 00:03:   add irq 8 flags 0x0
[    1.884032] pnp 00:03:   add io  0x70-0x71 flags 0x0
[    1.888032] pnp 00:03: parse resource options
[    1.892032] pnp 00:03: new independent option
[    1.896032] device: '00:03': device_add
[    1.900032] bus: 'pnp': add device 00:03
[    1.904032] PM: Adding info for pnp:00:03
[    1.908032] pnp 00:03: Plug and Play BIOS device, IDs PNP0b00 (active)

So I guess this function, pnpbios_init() needs the check as well. In
fact, it has this:

#ifdef CONFIG_PNPACPI
        if (!acpi_disabled && !pnpacpi_disabled) {
                pnpbios_disabled = 1;
                printk(KERN_INFO "PnPBIOS: Disabled by ACPI PNP\n");
                return -ENODEV;
        }
#endif                          /* CONFIG_ACPI */

...I guess that should be changed to say if (acpi_disabled ||
pnpacpi_disabled)? Or... I don't understand the purpose of the
original test. But it seems to be there since the beginning of time
(or, well, v2.6.12-rc2).


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036
--
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/