linux-kernel - Re: [PATCH v3 0/3] ACPI: container hot remove support.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50B3014E.3040107@huawei.com>
Date:	Mon, 26 Nov 2012 13:42:38 +0800
From:	Hanjun Guo <guohanjun@...wei.com>
To:	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	Tang Chen <tangchen@...fujitsu.com>, <yinghai@...nel.org>,
	<bhelgaas@...gle.com>, <lenb@...nel.org>, <jiang.liu@...wei.com>,
	<izumi.taku@...fujitsu.com>, <linux-acpi@...r.kernel.org>,
	<linux-pci@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Wen Congyang <wency@...fujitsu.com>,
	Toshi Kani <toshi.kani@...com>
Subject: Re: [PATCH v3 0/3] ACPI: container hot remove support.

On 2012/10/31 19:09, Yasuaki Ishimatsu wrote:
> Hi Tang,
> 
> 2012/10/31 16:27, Tang Chen wrote:
>> Hi,
>>
>> The container hotplug handler container_notify_cb() didn't implement
>> the hot-remove functionality. So, these 3 patches implement it like
>> the following way:
>>
>> patch 1. Do not use kacpid_wq/kacpid_notify_wq to handle container hotplug event,
>>           use kacpi_hotplug_wq instead to avoid deadlock.
>>           Doing this is to reuse acpi_bus_hot_remove_device() in container
>>           hot-remove handling.
>>
>> patch 2. Introduce a new function container_device_remove() to handle
>>           ACPI_NOTIFY_EJECT_REQUEST event for container.
> 
> If container device contains memory device, the function is 
> very danger. As you know, we are developing a memory hotplug.
> If memory has kernel memory, memory hot remove operations fails.
> But container_device_remove() cannot realize it. So even if
> the memory hot remove operation fails, container_device_remove()
> keeps hot remove operation. Finally, the function sends _EJ0
> to firmware. In this case, if the memory is accessed, kernel
> panic occurs.

Hi all,
I think Yasuaki mentioned the key point for the container device remove,
that is dependency.

Currently, container, processor, and memory hotpulg are managed by different ACPI
hotplug drivers, the driver works when handle device hotplug individually, but they
have no idea for each other.

This may introduce some issues, such as Yasuaki mentioned above, that is to say, we
should remove its child before remove the device itself, and hot add its parent before
the device itself.

According to the ACPI namespace, we can resolve most of dependency issues. On a typical
two processor sockets system, the namespace is like this:

/_SB                   ---container device, with HID ACPI0004
    |_SCK0             ---container device, with HID ACPI0004
	  |_CPU0       ---processor device, with HID ACPI0009 or LNXCPU
          |_...
          |_CPUx
          |_MEM0       ---Memory device, with HID PNP0C80
    |_SCK1
	  |_CPU0
          |_...
          |_CPUx
          |_MEM1
    |_PCI0            ---Host bridge, with HID PNP0A03 or PNP0A08

If hot remove the container device, such as SCK0, we can easily know the dependency list
is CPU0~CPUx and MEM0, but I think the ACPI hotplug driver haven't resolve this now.

And there is another corner case for hotplug devices in the namespace above, that is:
1) Remove SCK0. yes, we can remove it with no dependency to the host bridge PCI0;

2) Remove SCK1 after SCK0. we should remove the host bridge PCI0 first,
   or the system will crash down. yes, dynamic dependency analysis is needed here.
   and the ACPI hotplug driver totally have no idea of this.

so, should we do something to settle this down ?

Thanks
Hanjun Guo

> The example is as follows:
> 
>  https://lkml.org/lkml/2012/9/26/318
> 
> Thanks,
> Yasuaki Ishimatsu
> 
>>

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