On Wed 19-07-17 17:09:10, Joey Lee wrote: > On Mon, Jul 17, 2017 at 11:05:25AM +0200, Michal Hocko wrote: [...] > > 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 > > I agreed! > > Even a userspace application can handle part of offline jobs. It's > still possible that other kernel/userland compenents are using the > resource in container. > > > 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. > > The thing that we didn't align is how does kernel maintains the flag > of ejection state on container. Why it cannot be an attribute of the container? The flag would be set when the eject operation is requested and cleared when either the operation is successful (all parts offline and eject operation acked by the BIOS) or it is terminated. [...] > Base on the above figure, if userspace didn't do anything or it > just performs part of offline jobs. Then the container's [eject] > state will be always _SET_ there, and kernel will always check > the the latest child offline state when any child be offlined > by userspace. What is a problem about that? The eject is simply in progress until all is set. Or maybe I just misunderstood. > > On the other hand, for retry BIOS, we will apply the same > _eject_ flag approach on retry BIOS. If the OS performs > offline/ejection jobs too long then the retry BIOS is finally > time out. There doesn't have way for OS to aware the timeout. Doesn't BIOS notify the OS that the eject has timed out? > So the _eject_ flag is set forever. > > Thanks a lot! > Joey Lee -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
