linux-kernel - Re: [RFC PATCH] acpi: indicate to platform when hot remove returns busy

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] [day] [month] [year] [list]
Date:   Wed, 7 Jun 2017 23:24:17 +0800
From:   joeyli <jlee@...e.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     "Lee, Chun-Yi" <joeyli.kernel@...il.com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Len Brown <lenb@...nel.org>
Subject: Re: [RFC PATCH] acpi: indicate to platform when hot remove returns
 busy

On Wed, Jun 07, 2017 at 11:50:13AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 7, 2017 at 9:07 AM, Lee, Chun-Yi <joeyli.kernel@...il.com> wrote:
> > In hotplug logic, it always indicates non-specific failure to
> > platform through _OST when handing acpi hot-remove event failed. Then
> > platform terminates the hot-remove process but it can not identify
> > the reason.
> >
> > Base on current hot-remove code, there have two situations that it
> > returns busy:
> >  - OSPM try to offline an individual device, but the device offline
> >    function returns busy.
> >  - When the ejection event is applied to an "not offlined yet" container.
> >    OSPM send kobject change event to userspace and returns busy.
> >
> > Both of them will returns -EBUSY to acpi device hotplug function then
> > hotplug function indicates non-specific failure to platform just like
> > any other error, e.g. -ENODEV or -EIO.
> >
> > The benefit to platform for identifying the OS busy state is that
> > platform can be applied different approach to handle the busy but
> > not just terminate the hot-remove process by unknow reason. For
> > example, platform can wait for a while then triggers hot-remove
> > again.
> >
> > This RFC patch adds one more parameter to the handler function of
> > acpi generic hotplug event to give the function a chance to propose
> > the return code of _OST. In this case, it sets ost return code to
> > ACPI_OST_SC_DEVICE_BUSY when the acpi hot remove function returns
> > -EBUSY.
> 
> > -static int acpi_generic_hotplug_event(struct acpi_device *adev, u32 type)
> > +static int acpi_generic_hotplug_event(struct acpi_device *adev, u32 type,
> > +                                     u32 *ost_code)
> >  {
> > +       int error = -EINVAL;
> > +
> >         switch (type) {
> >         case ACPI_NOTIFY_BUS_CHECK:
> >                 return acpi_scan_bus_check(adev);
> > @@ -389,9 +392,11 @@ static int acpi_generic_hotplug_event(struct acpi_device *adev, u32 type)
> >                 }
> >                 acpi_evaluate_ost(adev->handle, ACPI_NOTIFY_EJECT_REQUEST,
> >                                   ACPI_OST_SC_EJECT_IN_PROGRESS, NULL);
> > -               return acpi_scan_hot_remove(adev);
> > +               error = acpi_scan_hot_remove(adev);
> > +               if (error == -EBUSY && ost_code)
> > +                       *ost_code = ACPI_OST_SC_DEVICE_BUSY;
> >         }
> > -       return -EINVAL;
> > +       return error;
> >  }
> >
> >  void acpi_device_hotplug(struct acpi_device *adev, u32 src)
> > @@ -413,7 +418,7 @@ void acpi_device_hotplug(struct acpi_device *adev, u32 src)
> >         if (adev->flags.is_dock_station) {
> >                 error = dock_notify(adev, src);
> >         } else if (adev->flags.hotplug_notify) {
> > -               error = acpi_generic_hotplug_event(adev, src);
> > +               error = acpi_generic_hotplug_event(adev, src, &ost_code);
> >                 if (error == -EPERM) {
> >                         ost_code = ACPI_OST_SC_EJECT_NOT_SUPPORTED;
> 
> Looking again to the code I still think you may easily do all stuff
> here in shorter and cleaner manner.
> Do we anticipate that there will be more callers that would like to
> get ost_code for one specific type of event?
> Above intrusion to the acpi_generic_hotplug_event() looks to me like
> non-generic hack.
>

Thanks for your suggestion, I will use switch-case to handle it in
next version.

I checked the ACPI spec and code path of other events:

 - For the standard nodification, the possible return value:
	- ACPI_NOTIFY_BUS_CHECK: acpi_scan_bus_check() returns 0 or -ENODEV
	- ACPI_NOTIFY_DEVICE_CHECK: acpi_scan_device_check() returns 0, -ENODEV or -EALREADY 
   So, standard notification needs only Success(0) or Non-specific failure(1)
 
 - For docker, currently the dock_notify() only returns 0 or -ENODEV.
	But, actually the handle_eject_request() may returns 0 or -EBUSY, but
	dock_notify() ignored it.
	If there have any machines that it has _OST for dock device, we should
	consider to return ACPI_OST_SC_DEVICE_BUSY to dock. Currently I didn't
	see benefit on this.

 - For additional notify handlers
	I only found acpi_pci_root_scan_dependent() that it always returns 0.

 - There have ACPI_OST_EC_OSPM_INSERTION(0x200) that OSPM didn't support
   It's definded in "Insertion Processing (Source Event: 0x200) Status Codes"
   in spec. It will use specific _OST event.

The event types are used by different acpi devices type. And, there have
the insertion event may shows in the future. I will use a switch-case to
handle the change in acpi_generic_hotplug_event().

Thanks a lot!
Joey Lee