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

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170714083713.GB2618@dhcp22.suse.cz>
Date:   Fri, 14 Jul 2017 10:37:13 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     joeyli <jlee@...e.com>
Cc:     linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>
Subject: Re: A udev rule to serve the change event of ACPI container?

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