Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1684877 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: A udev rule to serve the change event of ACPI container? Michal Hocko <mhocko@kernel.org> - 2017-07-11 10:30 +0200
    Re: A udev rule to serve the change event of ACPI container? joeyli <jlee@suse.com> - 2017-07-13 09:00 +0200
      Re: A udev rule to serve the change event of ACPI container? Michal Hocko <mhocko@kernel.org> - 2017-07-13 09:10 +0200
        Re: A udev rule to serve the change event of ACPI container? joeyli <jlee@suse.com> - 2017-07-13 14:50 +0200
          Re: A udev rule to serve the change event of ACPI container? Michal Hocko <mhocko@kernel.org> - 2017-07-14 10:40 +0200
            Re: A udev rule to serve the change event of ACPI container? joeyli <jlee@suse.com> - 2017-07-14 16:50 +0200
              Re: A udev rule to serve the change event of ACPI container? Michal Hocko <mhocko@kernel.org> - 2017-07-17 11:10 +0200

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

On Mon 26-06-17 10:59:07, Michal Hocko wrote:
> On Mon 26-06-17 14:26:57, Joey Lee wrote:
> > Hi all,
> > 
> > If ACPI received ejection request for a ACPI container, kernel
> > emits KOBJ_CHANGE uevent when it found online children devices
> > below the acpi container.
> > 
> > Base on the description of caa73ea15 kernel patch, user space
> > is expected to offline all devices below the container and the
> > container itself. Then, user space can finalize the removal of
> > the container with the help of its ACPI device object's eject
> > attribute in sysfs.
> > 
> > That means that kernel relies on users space to peform the offline
> > and ejection jobs to acpi container and children devices. The
> > discussion is here:
> > 	https://lkml.org/lkml/2013/11/28/520
> > 
> > The mail loop didn't explain why the userspace is responsible for
> > the whole container offlining. Is it possible to do that transparently
> > from the kernel? What's the difference between offlining memory and
> > processors which happends without any cleanup and container which
> > does essentially the same except it happens at once? 
> >  
> >  - After a couple of years, can we let the container hot-remove
> >    process transparently?
> >  - Except udev rule, does there have any other mechanism to trigger
> >    auto offline/ejection?
> 
> I would be also interested whether the kernel can simply send an udev event
> to all devices in the container.

Any opinion on this?
-- 
Michal Hocko
SUSE Labs

[toc] | [next] | [standalone]

#1686297

Hi Michal, 

Sorry for my delay.

On Tue, Jul 11, 2017 at 10:25:32AM +0200, Michal Hocko wrote:
> On Mon 26-06-17 10:59:07, Michal Hocko wrote:
> > On Mon 26-06-17 14:26:57, Joey Lee wrote:
> > > Hi all,
> > > 
> > > If ACPI received ejection request for a ACPI container, kernel
> > > emits KOBJ_CHANGE uevent when it found online children devices
> > > below the acpi container.
> > > 
> > > Base on the description of caa73ea15 kernel patch, user space
> > > is expected to offline all devices below the container and the
> > > container itself. Then, user space can finalize the removal of
> > > the container with the help of its ACPI device object's eject
> > > attribute in sysfs.
> > > 
> > > That means that kernel relies on users space to peform the offline
> > > and ejection jobs to acpi container and children devices. The
> > > discussion is here:
> > > 	https://lkml.org/lkml/2013/11/28/520
> > > 
> > > The mail loop didn't explain why the userspace is responsible for
> > > the whole container offlining. Is it possible to do that transparently
> > > from the kernel? What's the difference between offlining memory and
> > > processors which happends without any cleanup and container which
> > > does essentially the same except it happens at once? 
> > >  
> > >  - After a couple of years, can we let the container hot-remove
> > >    process transparently?
> > >  - Except udev rule, does there have any other mechanism to trigger
> > >    auto offline/ejection?
> > 
> > I would be also interested whether the kernel can simply send an udev event
> > to all devices in the container.
> 
> Any opinion on this?

If BIOS emits ejection event for a ACPI0004 container, someone needs
to handle the offline/eject jobs of container. Either kernel or user
space.

Only sending uevent to individual child device can simplify udev rule,
but it also means that the kernel needs to offline/eject container
after all children devices are offlined. Maybe adding a ejection flag
on the ACPI0004 object to indicate the container state. But, if userland
doesn't do his job, then the timing to reset the flag will be the problem. 

Thanks a lot!
Joey Lee 

[toc] | [prev] | [next] | [standalone]

#1686306

On Thu 13-07-17 14:58:06, Joey Lee wrote:
> Hi Michal, 
> 
> Sorry for my delay.
> 
> On Tue, Jul 11, 2017 at 10:25:32AM +0200, Michal Hocko wrote:
> > On Mon 26-06-17 10:59:07, Michal Hocko wrote:
> > > On Mon 26-06-17 14:26:57, Joey Lee wrote:
> > > > Hi all,
> > > > 
> > > > If ACPI received ejection request for a ACPI container, kernel
> > > > emits KOBJ_CHANGE uevent when it found online children devices
> > > > below the acpi container.
> > > > 
> > > > Base on the description of caa73ea15 kernel patch, user space
> > > > is expected to offline all devices below the container and the
> > > > container itself. Then, user space can finalize the removal of
> > > > the container with the help of its ACPI device object's eject
> > > > attribute in sysfs.
> > > > 
> > > > That means that kernel relies on users space to peform the offline
> > > > and ejection jobs to acpi container and children devices. The
> > > > discussion is here:
> > > > 	https://lkml.org/lkml/2013/11/28/520
> > > > 
> > > > The mail loop didn't explain why the userspace is responsible for
> > > > the whole container offlining. Is it possible to do that transparently
> > > > from the kernel? What's the difference between offlining memory and
> > > > processors which happends without any cleanup and container which
> > > > does essentially the same except it happens at once? 
> > > >  
> > > >  - After a couple of years, can we let the container hot-remove
> > > >    process transparently?
> > > >  - Except udev rule, does there have any other mechanism to trigger
> > > >    auto offline/ejection?
> > > 
> > > I would be also interested whether the kernel can simply send an udev event
> > > to all devices in the container.
> > 
> > Any opinion on this?
> 
> If BIOS emits ejection event for a ACPI0004 container, someone needs
> to handle the offline/eject jobs of container. Either kernel or user
> space.
> 
> Only sending uevent to individual child device can simplify udev rule,
> but it also means that the kernel needs to offline/eject container
> after all children devices are offlined.

Why cannot kernel send this eject command to the BIOS if the whole
container is offline? If it is not then the kernel would send EBUSY to
the BIOS and BIOS would have to retry after some timeout. Or is it a
problem that currently implemented BIOS firmwares do not implement this
retry?
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1686507

On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote:
> On Thu 13-07-17 14:58:06, Joey Lee wrote:
> > Hi Michal, 
> > 
> > Sorry for my delay.
> > 
> > On Tue, Jul 11, 2017 at 10:25:32AM +0200, Michal Hocko wrote:
> > > On Mon 26-06-17 10:59:07, Michal Hocko wrote:
> > > > On Mon 26-06-17 14:26:57, Joey Lee wrote:
> > > > > Hi all,
> > > > > 
> > > > > If ACPI received ejection request for a ACPI container, kernel
> > > > > emits KOBJ_CHANGE uevent when it found online children devices
> > > > > below the acpi container.
> > > > > 
> > > > > Base on the description of caa73ea15 kernel patch, user space
> > > > > is expected to offline all devices below the container and the
> > > > > container itself. Then, user space can finalize the removal of
> > > > > the container with the help of its ACPI device object's eject
> > > > > attribute in sysfs.
> > > > > 
> > > > > That means that kernel relies on users space to peform the offline
> > > > > and ejection jobs to acpi container and children devices. The
> > > > > discussion is here:
> > > > > 	https://lkml.org/lkml/2013/11/28/520
> > > > > 
> > > > > The mail loop didn't explain why the userspace is responsible for
> > > > > the whole container offlining. Is it possible to do that transparently
> > > > > from the kernel? What's the difference between offlining memory and
> > > > > processors which happends without any cleanup and container which
> > > > > does essentially the same except it happens at once? 
> > > > >  
> > > > >  - After a couple of years, can we let the container hot-remove
> > > > >    process transparently?
> > > > >  - Except udev rule, does there have any other mechanism to trigger
> > > > >    auto offline/ejection?
> > > > 
> > > > I would be also interested whether the kernel can simply send an udev event
> > > > to all devices in the container.
> > > 
> > > Any opinion on this?
> > 
> > If BIOS emits ejection event for a ACPI0004 container, someone needs
> > to handle the offline/eject jobs of container. Either kernel or user
> > space.
> > 
> > Only sending uevent to individual child device can simplify udev rule,
> > but it also means that the kernel needs to offline/eject container
> > after all children devices are offlined.
> 
> Why cannot kernel send this eject command to the BIOS if the whole
> container is offline? If it is not then the kernel would send EBUSY to

Current kernel container hot-remove process:

  BIOS -> SCI event -> Kernel ACPI -> uevent -> userland
              
Then, kernel just calls _OST to expose state to BIOS, then process is
stopped. Kernel doesn't wait there for userland to offline each child
devices. Either BIOS or userland needs to trigger the container
ejection.

> container is offline? If it is not then the kernel would send EBUSY to
> the BIOS and BIOS would have to retry after some timeout. Or is it a

The d429e5c122 patch is merged to mainline. So kernel will send
DEVICE_BUSY to BIOS after it emits uevent to userland. BIOS can choice
to apply the retry approach until OS returns process failure exactly or
BIOS timeout.

> problem that currently implemented BIOS firmwares do not implement this
> retry?

Yes, we should consider the behavior of old BIOS. Old BIOS doesn't
retry/resend the ejection event. So kernel or userland need to take the
retry job. Obviously userland runs the retry since the caa73ea15 patch
is merged.

IMHO there have two different expectation from user space application.

Applications like DVD player or Burner expect that kernel should
info userspace for the ejection, then application can do their cleaning
job and re-trigger ejection from userland.

But, some other applications like database don't want that their service
be stopped when the devices offline/eject. The hot-remove sholud be done by
kernel transparently.

We need a way for fill two situations.

Thanks a lot!
Joey Lee

[toc] | [prev] | [next] | [standalone]

#1687161

On Thu 13-07-17 20:45:21, Joey Lee wrote:
> On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote:
> > On Thu 13-07-17 14:58:06, Joey Lee wrote:
[...]
> > > If BIOS emits ejection event for a ACPI0004 container, someone needs
> > > to handle the offline/eject jobs of container. Either kernel or user
> > > space.
> > > 
> > > Only sending uevent to individual child device can simplify udev rule,
> > > but it also means that the kernel needs to offline/eject container
> > > after all children devices are offlined.
> > 
> > Why cannot kernel send this eject command to the BIOS if the whole
> > container is offline? If it is not then the kernel would send EBUSY to
> 
> Current kernel container hot-remove process:
> 
>   BIOS -> SCI event -> Kernel ACPI -> uevent -> userland
>               
> Then, kernel just calls _OST to expose state to BIOS, then process is
> stopped. Kernel doesn't wait there for userland to offline each child
> devices. Either BIOS or userland needs to trigger the container
> ejection.
> 
> > container is offline? If it is not then the kernel would send EBUSY to
> > the BIOS and BIOS would have to retry after some timeout. Or is it a
> 
> The d429e5c122 patch is merged to mainline. So kernel will send
> DEVICE_BUSY to BIOS after it emits uevent to userland. BIOS can choice
> to apply the retry approach until OS returns process failure exactly or
> BIOS timeout.
> 
> > problem that currently implemented BIOS firmwares do not implement this
> > retry?
> 
> Yes, we should consider the behavior of old BIOS. Old BIOS doesn't
> retry/resend the ejection event. So kernel or userland need to take the
> retry job. Obviously userland runs the retry since the caa73ea15 patch
> is merged.
> 
> IMHO there have two different expectation from user space application.
> 
> Applications like DVD player or Burner expect that kernel should
> info userspace for the ejection, then application can do their cleaning
> job and re-trigger ejection from userland.

I am not sure I understand the DVD example because I do not see how it
fits into the container and online/offline scenario.

> But, some other applications like database don't want that their service
> be stopped when the devices offline/eject. The hot-remove sholud be done by
> kernel transparently.
> 
> We need a way for fill two situations.

Hmm, so can we trigger the eject from the _kernel_ when the last child
is offlined?
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1687485

On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote:
> On Thu 13-07-17 20:45:21, Joey Lee wrote:
> > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote:
> > > On Thu 13-07-17 14:58:06, Joey Lee wrote:
> [...]
> > > > If BIOS emits ejection event for a ACPI0004 container, someone needs
> > > > to handle the offline/eject jobs of container. Either kernel or user
> > > > space.
> > > > 
> > > > Only sending uevent to individual child device can simplify udev rule,
> > > > but it also means that the kernel needs to offline/eject container
> > > > after all children devices are offlined.
> > > 
> > > Why cannot kernel send this eject command to the BIOS if the whole
> > > container is offline? If it is not then the kernel would send EBUSY to
> > 
> > Current kernel container hot-remove process:
> > 
> >   BIOS -> SCI event -> Kernel ACPI -> uevent -> userland
> >               
> > Then, kernel just calls _OST to expose state to BIOS, then process is
> > stopped. Kernel doesn't wait there for userland to offline each child
> > devices. Either BIOS or userland needs to trigger the container
> > ejection.
> > 
> > > container is offline? If it is not then the kernel would send EBUSY to
> > > the BIOS and BIOS would have to retry after some timeout. Or is it a
> > 
> > The d429e5c122 patch is merged to mainline. So kernel will send
> > DEVICE_BUSY to BIOS after it emits uevent to userland. BIOS can choice
> > to apply the retry approach until OS returns process failure exactly or
> > BIOS timeout.
> > 
> > > problem that currently implemented BIOS firmwares do not implement this
> > > retry?
> > 
> > Yes, we should consider the behavior of old BIOS. Old BIOS doesn't
> > retry/resend the ejection event. So kernel or userland need to take the
> > retry job. Obviously userland runs the retry since the caa73ea15 patch
> > is merged.
> > 
> > IMHO there have two different expectation from user space application.
> > 
> > Applications like DVD player or Burner expect that kernel should
> > info userspace for the ejection, then application can do their cleaning
> > job and re-trigger ejection from userland.
> 
> I am not sure I understand the DVD example because I do not see how it
> fits into the container and online/offline scenario.
>

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?  

If Yasuaki's issue is already fixed, then we should consider to let
kernel does the container hot-remove transparently. 

> > But, some other applications like database don't want that their service
> > be stopped when the devices offline/eject. The hot-remove sholud be done by
> > kernel transparently.
> > 
> > We need a way for fill two situations.
> 
> Hmm, so can we trigger the eject from the _kernel_ when the last child
> is offlined?

Kernel needs to remember that the container is under a _EJECTION_ state
that it should waits all children be offlined. Then kernel checks the
container offline state when each individual device is offlined. If
kernel found a container offlined (means that all children are offlined),
and the container is under ejection state, then kernel runs ejection
jobs (removing objects and calls _EJ0). 

To achieve this, I think that the container object needs a _EJECTION_
flag. It helps kernel to remember the state that it set by BIOS's
ejection event.

This approach has some problems: If userland doesn't finish his offline
jobs or userland doesn't do anything, when should kernel clears the 
ejection flag and responses failure by _OST to BIOS?

And, for new BIOS that it has time out mechanism. Currently there have
no way for BIOS to tell kernel that it gives up. It's hard to sync the
kernel container's ejection flag with BIOS. 

Of course the better is that Yasuaki's problem got fixed. Kernel does
the hot-removes container transparently (again). Then we don't need
to worry how to maintain a ejection state in kernel.  

Thanks a lot!
Joey Lee 

[toc] | [prev] | [next] | [standalone]

#1688790

On Fri 14-07-17 22:44:14, Joey Lee wrote:
> On Fri, Jul 14, 2017 at 10:37:13AM +0200, Michal Hocko wrote:
> > On Thu 13-07-17 20:45:21, Joey Lee wrote:
> > > On Thu, Jul 13, 2017 at 09:06:19AM +0200, Michal Hocko wrote:
> > > > On Thu 13-07-17 14:58:06, Joey Lee wrote:
> > [...]
> > > > > If BIOS emits ejection event for a ACPI0004 container, someone needs
> > > > > to handle the offline/eject jobs of container. Either kernel or user
> > > > > space.
> > > > > 
> > > > > Only sending uevent to individual child device can simplify udev rule,
> > > > > but it also means that the kernel needs to offline/eject container
> > > > > after all children devices are offlined.
> > > > 
> > > > Why cannot kernel send this eject command to the BIOS if the whole
> > > > container is offline? If it is not then the kernel would send EBUSY to
> > > 
> > > Current kernel container hot-remove process:
> > > 
> > >   BIOS -> SCI event -> Kernel ACPI -> uevent -> userland
> > >               
> > > Then, kernel just calls _OST to expose state to BIOS, then process is
> > > stopped. Kernel doesn't wait there for userland to offline each child
> > > devices. Either BIOS or userland needs to trigger the container
> > > ejection.
> > > 
> > > > container is offline? If it is not then the kernel would send EBUSY to
> > > > the BIOS and BIOS would have to retry after some timeout. Or is it a
> > > 
> > > The d429e5c122 patch is merged to mainline. So kernel will send
> > > DEVICE_BUSY to BIOS after it emits uevent to userland. BIOS can choice
> > > to apply the retry approach until OS returns process failure exactly or
> > > BIOS timeout.
> > > 
> > > > problem that currently implemented BIOS firmwares do not implement this
> > > > retry?
> > > 
> > > Yes, we should consider the behavior of old BIOS. Old BIOS doesn't
> > > retry/resend the ejection event. So kernel or userland need to take the
> > > retry job. Obviously userland runs the retry since the caa73ea15 patch
> > > is merged.
> > > 
> > > IMHO there have two different expectation from user space application.
> > > 
> > > Applications like DVD player or Burner expect that kernel should
> > > info userspace for the ejection, then application can do their cleaning
> > > job and re-trigger ejection from userland.
> > 
> > I am not sure I understand the DVD example because I do not see how it
> > fits into the container and online/offline scenario.
> >
> 
> 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.

The problem I have with this expectation is that userspace will never
have a good atomic view of the whole container. So it can only try to
eject and then hope that nobody has onlined part of the container.
If you emit offline event to the userspace the cleanup can be done and
after the last component goes offline then the eject can be done
atomically.

[...]
> > Hmm, so can we trigger the eject from the _kernel_ when the last child
> > is offlined?
> 
> Kernel needs to remember that the container is under a _EJECTION_ state
> that it should waits all children be offlined. Then kernel checks the
> container offline state when each individual device is offlined. If
> kernel found a container offlined (means that all children are offlined),
> and the container is under ejection state, then kernel runs ejection
> jobs (removing objects and calls _EJ0). 

yes, that is what I meant.

> To achieve this, I think that the container object needs a _EJECTION_
> flag. It helps kernel to remember the state that it set by BIOS's
> ejection event.

yes something like that.
 
> This approach has some problems: If userland doesn't finish his offline
> jobs or userland doesn't do anything, when should kernel clears the 
> ejection flag and responses failure by _OST to BIOS?

I do not see how is that any different from the current approach. You
still cannot do the eject if some component is online and we rely on the
userspace to do the offline.
 
> And, for new BIOS that it has time out mechanism. Currently there have
> no way for BIOS to tell kernel that it gives up. It's hard to sync the
> kernel container's ejection flag with BIOS. 

I am not sure I understand. The kernel/BIOS synchronization happens on
the up/down calls between the platform and the kernel...
-- 
Michal Hocko
SUSE Labs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web