lkml.org 
[lkml]   [2012]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH v3 3/3] acpi_memhotplug: Allow eject to proceed on rebind scenario
Date
On Wednesday, November 28, 2012 03:16:22 PM Toshi Kani wrote:
> > > > > > > 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.


\
 
 \ /
  Last update: 2012-11-29 00:01    [W:0.773 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site