linux-kernel - Re: [RFC PATCH 0/3] acpi: Introduce prepare

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: <50A07477.2050002@cn.fujitsu.com>
Date:	Mon, 12 Nov 2012 12:00:55 +0800
From:	Wen Congyang <wency@...fujitsu.com>
To:	Vasilis Liaskovitis <vasilis.liaskovitis@...fitbricks.com>
CC:	linux-acpi@...r.kernel.org, isimatu.yasuaki@...fujitsu.com,
	rjw@...k.pl, lenb@...nel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [RFC PATCH 0/3] acpi: Introduce prepare_remove device operation

At 11/09/2012 02:29 AM, Vasilis Liaskovitis Wrote:
> As discussed in
> https://patchwork.kernel.org/patch/1581581/
> the driver core remove function needs to always succeed. This means we need
> to know that the device can be successfully removed before acpi_bus_trim / 
> acpi_bus_hot_remove_device are called. This can cause panics when OSPM-initiated
> eject (echo 1 > /sys/bus/acpi/devices/PNP/eject) of memory devices fails, since
> the ACPI core goes ahead and ejects the device regardless of whether the memory
> is still in use or not.
> 
> For this reason a new acpi_device operation called prepare_remove is introduced.
> This operation should be registered for acpi devices whose removal (from kernel
> perspective) can fail.  Memory devices fall in this category.
> 
> acpi_bus_hot_remove_device is changed to handle removal in 2 steps:
> - preparation for removal i.e. perform part of removal that can fail outside of
>   ACPI core. Should succeed for device and all its children.
> - if above step was successfull, proceed to actual ACPI removal

If we unbind the device from the driver, we still need to do preparation. But
you don't do it in your patch.

Thanks
Wen Congyang
> 
> acpi_bus_trim is changed accordingly to handle preparation for removal and
> actual removal.
> 
> With this patchset, only acpi memory devices use the new prepare_remove
> device operation. The actual memory removal (VM-related offline and other memory
> cleanups) is moved to prepare_remove. The old remove operation just cleans up
> the acpi structures. Directly ejecting PNP0C80 memory devices works safely. I
> haven't tested yet with an ACPI container which contains memory devices.
> 
> Other ACPI devices (e.g. CPU) do not register prepare_remove callbacks, and
> their OSPM-side eject should not be affected.
> 
> I am not happy with the name prepare_remove. Comments welcome. Let me know if I
> should work more in this direction (I think Yasuaki might also look into this
> and might have a simpler idea)
> 
> Patches are on top of Rafael's linux-pm/linux-next
> 
> Vasilis Liaskovitis (3):
>   acpi: Introduce prepare_remove operation in acpi_device_ops
>   acpi: Make acpi_bus_trim handle device removal preparation
>   acpi_memhotplug: Add prepare_remove operation
> 
>  drivers/acpi/acpi_memhotplug.c     |   24 +++++++++++++++++++++---
>  drivers/acpi/dock.c                |    2 +-
>  drivers/acpi/scan.c                |   32 +++++++++++++++++++++++++++++---
>  drivers/pci/hotplug/acpiphp_glue.c |    4 ++--
>  drivers/pci/hotplug/sgi_hotplug.c  |    2 +-
>  include/acpi/acpi_bus.h            |    4 +++-
>  6 files changed, 57 insertions(+), 11 deletions(-)
> 

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