Re: A udev rule to serve the change event of ACPI container?

[joeyli]

On Fri, Aug 04, 2017 at 05:06:19PM +0200, Michal Hocko wrote:
> On Thu 03-08-17 11:37:37, YASUAKI ISHIMATSU wrote:
> > 
> > 
> > On 08/02/2017 01:49 AM, joeyli wrote:
> > > Hi YASUAKI,
> > > 
> > > On Tue, Aug 01, 2017 at 03:21:38PM -0400, YASUAKI ISHIMATSU wrote:
> > >> Hi Joey,
> > >>
> > >> On 07/23/2017 05:18 AM, joeyli wrote:
> > > [...snip]
> > >>>>>
> > >>>>
> > >>>> At least Yasuaki raised similar behavior for container in 2013.
> > >>>> It's similar to the DVD player case, user space application needs
> > >>>> to do something then trigger children offline and ejection of
> > >>>> container.
> > >>>>
> > >>>> Base on Yasuaki's explanation, the reason of that he requested the
> > >>>> userland ejection approach is that he got memory hot-remove problem
> > >>>> in 2013. Maybe his problem is already fixed by your patches in current
> > >>>> mainline.
> > >>>>
> > >>>> Hi Yasuaki, could you please check that your memory hot-remove problem
> > >>>> is fixed on mainline kernel?  
> > >>
> > >> I cannot remember what I mentioned in 2013. Could you tell me url of lkml archive.
> > >>
> > > 
> > 
> > > Here: https://lkml.org/lkml/2013/11/28/520
> > 
> > Thank you for specifying the URL. In the URL, I wrote the following problems:
> > 
> > >   1. easily fail
> > >      My container device has CPU device and Memory device, and maximum size of
> > >      memory is 3Tbyte. In my environment, hot removing container device fails
> > >      on offlining memory if memory is used by application.
> > >      I think if offlininig memory, we must retly to offline memory several
> > >      times.
> > 
> > I think the issue still remains. If process keeps accessing memory, offlining
> > the memory easily fails with EBUSY.
> 
> Yes and the only way how to deal with it is to retry the offline. In
> order to do that userspace has to be notified to try again.

Looks that kernel still needs to rely on userspace to trigger offline
for each child device. 

My plan is to impelement a _EJECTING_ flag on acpi_device struct.
It indicates that the acpi device under ejection process. The flag
will be changed in the following situations:

- EJECTING flag 0 -> 1
    - After acpi_scan_hot_remove() sends KOBJ_CHANGE for all children

- EJECTING flag 1 -> 0 
    - After acpi_scan_hot_remove() calls _EJ0
    - Any child device was set online again

And, according to the order, any EJECTING flag changing work must be
pushed to kacpi_hotplug_wq work queue.

Thanks a lot!
Joey Lee