linux-kernel - Re: [PATCH 0/4, v3] Physical PCI slot objects

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]

Date:	Mon, 03 Dec 2007 12:30:55 +0900
From:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>
To:	Alex Chiang <achiang@...com>, pcihpd-discuss@...ts.sourceforge.net
Cc:	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	Gary Hade <garyhade@...ibm.com>,
	Matthew Wilcox <matthew@....cx>, gregkh@...e.de,
	kristen.c.accardi@...el.com, lenb@...nel.org, rick.jones2@...com,
	linux-kernel@...r.kernel.org, linux-pci@...ey.karlin.mff.cuni.cz,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH 0/4, v3] Physical PCI slot objects

Hi Alex-san,

>> On my system, hotplug slots themselves can be added, removed
>> and replaced with the ohter type of I/O box. The ACPI firmware
>> tells OS the presence of those slots using _STA method (That
>> is, it doesn't use 'LoadTable()' AML operator). On the other
>> hand, current pci_slot driver doesn't check _STA.  As a result,
>> pci_slot driver tryied to register the invalid (non-existing)
>> slots. The ACPI firmware of my system returns '1023' if the
>> invalid slot's _SUN is evaluated. This is the cause of Call
>> Traces mentioned above. To fix this problem, pci_slot driver
>> need to check _STA when scanning ACPI Namespace.
> 
> Now this is very curious. The relevant line in pci_slot is:
> 
> check_slot()
> 	status = acpi_evaluate_integer(handle, "_SUN", NULL, sun);
> 	if (ACPI_FAILURE(status))
> 		return -1;
> 
> Why does your firmware return the error information inside sun,
> instead of returning an error in status? That doesn't seem right
> to me...

Because ACPI spec doesn't provide any way for firmware (AML)
to return as error.

In addtion, I think we should not trust the _SUN value of
non-existing device because the ACPI spec says in "6.5.1 _INI
(Init)" that _INI method is run before _ADR, _CID, _HID, _SUN, and
_UID are run. It means _SUN could be initialized in _INI method
implecitely. And it also says that "If the _STA method indicates
that the device is not present, OSPM will not run the _INI and will
not examine the children of the device for _INI methods.". After all,
_SUN for non-existing device is not reliable because it might not
initialized by _INI method.

> 
>> I'm sorry for reporting this so late. I'm attaching the patch
>> to fix the problem. This is against 2.6.24-rc3 with your
>> patches applied. Could you try it?
> 
> Applying this patch causes me to only detect populated slots in
> my system, which isn't what I want -- otherwise, I could have
> just enumerated the PCI bus and found the devices that way. :)
> 
> Maybe on your machine, checking existence of _STA might do the
> right thing, but I don't think we should actually be looking at
> any of the actual bits returned. 
> 
> If we check ACPI_STA_DEVICE_PRESENT, then we will not detect
> empty slots on my system. Can you try this patch to see if at
> least the first call to acpi_evaluate_integer helps? If that
> doesn't help, maybe the second block will help you, but it breaks
> my machine...

Maybe the result is as you guess.
The first block doesn't help me (with the first block, all of the
slot disappeared. Please see the bottom of this mail for details).
The second block helps me.

There seems a difference of the interpretation about _STA for PCI
hotplug slot between your firmware and my firmware. The difference
is:

  - Your firmware provides the _STA method to represent the presence
    of PCI adapter card on the slot.

  - My firmware provides the _STA method to represent the presence
    of the slot.

Providing _STA method to represent the presence of PCI adpater card
on the slot (as your firmware does) doesn't seem right to me because
of the following reasons.

  - ACPI spec says "After calling _EJ0, OSPM verifies the device no
    longer exists to determine if the eject succeeded. For _HID devices,
    OSPM evaluates the _STA method. For _ADR devices, OSPM checks with
    the bus driver for that device." in "6.3.3 _EJx (Eject)". Because
    PCI adapter card on the slot is _ADR device, the presence of the
    card must be checked with bus driver, not _STA.

  - ACPI spec provides the example AML code which uses _STA to
    represent Docking Station (See 6.3.2 _EJD (Ejection Dependent
    Device)". The usage of this is same as my firmware.

What do you think about that?

P.S. None of the slots except the strange slot named '1023' were
detected with your patch. It would happen on other machines
(might including hp machine) too. The reason is _STA evaluation
fails on the hotplug slot which doesn't have _STA method. If the
device object doesn't have a _STA method, we need to handle it as
if it is present. I believe firmware normally doesn't provide
_STA method for PCI hotplug slots.

Thanks,
Kenji Kaneshige

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