Thread (92 messages) 92 messages, 9 authors, 2012-12-15

Re: [RFC PATCH v3 3/3] acpi_memhotplug: Allow eject to proceed on rebind scenario

From: Rafael J. Wysocki <hidden>
Date: 2012-11-28 22:34:39
Also in: linux-mm, lkml

On Wednesday, November 28, 2012 03:16:22 PM Toshi Kani wrote:
quoted
quoted
quoted
quoted
quoted
quoted
I see.  I do not think whether or not the device is removed on eject
makes any difference here.  The issue is that after driver_unbind() is
done, acpi_bus_hot_remove_device() no longer calls the ACPI memory
driver (hence, it cannot fail in prepare_remove), and goes ahead to call
_EJ0.  If driver_unbind() did off-line the memory, this is OK.  However,
it cannot off-line kernel memory ranges.  So, we basically need to
either 1) serialize acpi_bus_hot_remove_device() and driver_unbind(), or
2) make acpi_bus_hot_remove_device() to fail if driver_unbind() is run
during the operation.
OK, I see the problem now.

What exactly is triggering the driver_unbind() in this scenario?
User can request driver_unbind() from sysfs as follows.  I do not see
much reason why user has to do for memory, though.

echo "PNP0C80:XX" > /sys/bus/acpi/drivers/acpi_memhotplug/unbind
This is wrong.  Even if we want to permit user space to forcibly unbind
drivers from anything like this, we should at least check for some
situations in which it is plain dangerous.  Like in this case.  So I think
the above should fail unless we know that the driver won't be necessary
to handle hot-removal of memory.
Well, we tried twice already... :)
https://lkml.org/lkml/2012/11/16/649
I didn't mean driver_unbind() should fail.  The code path that executes
driver_unbind() eventually should fail _before_ executing it.
driver_unbind() is the handler, so it is called directly from this
unbind interface.
Yes, sorry for the confusion.

So, it looks like the driver core wants us to handle driver unbinding no
matter what.

This pretty much means that it is a bad idea to have a driver that is
exposed as a "device driver" in sysfs for memory hotplugging.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help