2018-02-14 00:36:14 +01:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2018 The Android Open Source Project
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "action_manager.h"
|
|
|
|
|
|
|
|
#include <android-base/logging.h>
|
|
|
|
|
|
|
|
namespace android {
|
|
|
|
namespace init {
|
|
|
|
|
|
|
|
ActionManager::ActionManager() : current_command_(0) {}
|
|
|
|
|
2019-07-30 18:34:41 +02:00
|
|
|
size_t ActionManager::CheckAllCommands() {
|
|
|
|
size_t failures = 0;
|
|
|
|
for (const auto& action : actions_) {
|
|
|
|
failures += action->CheckAllCommands();
|
|
|
|
}
|
|
|
|
return failures;
|
|
|
|
}
|
|
|
|
|
2018-02-14 00:36:14 +01:00
|
|
|
ActionManager& ActionManager::GetInstance() {
|
|
|
|
static ActionManager instance;
|
|
|
|
return instance;
|
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::AddAction(std::unique_ptr<Action> action) {
|
|
|
|
actions_.emplace_back(std::move(action));
|
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::QueueEventTrigger(const std::string& trigger) {
|
init: handle property service callbacks asynchronously
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Merged-In: I84108e54217866205a48c45e8b59355012c32ea8
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
(cherry picked from commit 7205c6293341c82701e849fa29cfab66916d1052)
2020-01-29 23:09:24 +01:00
|
|
|
auto lock = std::lock_guard{event_queue_lock_};
|
2018-02-14 00:36:14 +01:00
|
|
|
event_queue_.emplace(trigger);
|
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::QueuePropertyChange(const std::string& name, const std::string& value) {
|
init: handle property service callbacks asynchronously
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Merged-In: I84108e54217866205a48c45e8b59355012c32ea8
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
(cherry picked from commit 7205c6293341c82701e849fa29cfab66916d1052)
2020-01-29 23:09:24 +01:00
|
|
|
auto lock = std::lock_guard{event_queue_lock_};
|
2018-02-14 00:36:14 +01:00
|
|
|
event_queue_.emplace(std::make_pair(name, value));
|
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::QueueAllPropertyActions() {
|
|
|
|
QueuePropertyChange("", "");
|
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::QueueBuiltinAction(BuiltinFunction func, const std::string& name) {
|
init: handle property service callbacks asynchronously
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Merged-In: I84108e54217866205a48c45e8b59355012c32ea8
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
(cherry picked from commit 7205c6293341c82701e849fa29cfab66916d1052)
2020-01-29 23:09:24 +01:00
|
|
|
auto lock = std::lock_guard{event_queue_lock_};
|
2018-02-14 01:24:51 +01:00
|
|
|
auto action = std::make_unique<Action>(true, nullptr, "<Builtin Action>", 0, name,
|
|
|
|
std::map<std::string, std::string>{});
|
2019-07-10 20:18:24 +02:00
|
|
|
action->AddCommand(std::move(func), {name}, 0);
|
2018-02-14 00:36:14 +01:00
|
|
|
|
|
|
|
event_queue_.emplace(action.get());
|
|
|
|
actions_.emplace_back(std::move(action));
|
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::ExecuteOneCommand() {
|
init: handle property service callbacks asynchronously
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Merged-In: I84108e54217866205a48c45e8b59355012c32ea8
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
(cherry picked from commit 7205c6293341c82701e849fa29cfab66916d1052)
2020-01-29 23:09:24 +01:00
|
|
|
{
|
|
|
|
auto lock = std::lock_guard{event_queue_lock_};
|
|
|
|
// Loop through the event queue until we have an action to execute
|
|
|
|
while (current_executing_actions_.empty() && !event_queue_.empty()) {
|
|
|
|
for (const auto& action : actions_) {
|
|
|
|
if (std::visit([&action](const auto& event) { return action->CheckEvent(event); },
|
|
|
|
event_queue_.front())) {
|
|
|
|
current_executing_actions_.emplace(action.get());
|
|
|
|
}
|
2018-02-14 00:36:14 +01:00
|
|
|
}
|
init: handle property service callbacks asynchronously
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Merged-In: I84108e54217866205a48c45e8b59355012c32ea8
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
(cherry picked from commit 7205c6293341c82701e849fa29cfab66916d1052)
2020-01-29 23:09:24 +01:00
|
|
|
event_queue_.pop();
|
2018-02-14 00:36:14 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (current_executing_actions_.empty()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto action = current_executing_actions_.front();
|
|
|
|
|
|
|
|
if (current_command_ == 0) {
|
|
|
|
std::string trigger_name = action->BuildTriggersString();
|
|
|
|
LOG(INFO) << "processing action (" << trigger_name << ") from (" << action->filename()
|
|
|
|
<< ":" << action->line() << ")";
|
|
|
|
}
|
|
|
|
|
|
|
|
action->ExecuteOneCommand(current_command_);
|
|
|
|
|
|
|
|
// If this was the last command in the current action, then remove
|
|
|
|
// the action from the executing list.
|
|
|
|
// If this action was oneshot, then also remove it from actions_.
|
|
|
|
++current_command_;
|
|
|
|
if (current_command_ == action->NumCommands()) {
|
|
|
|
current_executing_actions_.pop();
|
|
|
|
current_command_ = 0;
|
|
|
|
if (action->oneshot()) {
|
|
|
|
auto eraser = [&action](std::unique_ptr<Action>& a) { return a.get() == action; };
|
2019-07-09 00:09:36 +02:00
|
|
|
actions_.erase(std::remove_if(actions_.begin(), actions_.end(), eraser),
|
|
|
|
actions_.end());
|
2018-02-14 00:36:14 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool ActionManager::HasMoreCommands() const {
|
init: handle property service callbacks asynchronously
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Merged-In: I84108e54217866205a48c45e8b59355012c32ea8
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
(cherry picked from commit 7205c6293341c82701e849fa29cfab66916d1052)
2020-01-29 23:09:24 +01:00
|
|
|
auto lock = std::lock_guard{event_queue_lock_};
|
2018-02-14 00:36:14 +01:00
|
|
|
return !current_executing_actions_.empty() || !event_queue_.empty();
|
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::DumpState() const {
|
|
|
|
for (const auto& a : actions_) {
|
|
|
|
a->DumpState();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void ActionManager::ClearQueue() {
|
init: handle property service callbacks asynchronously
A previous change moved property_service into its own thread, since
there was otherwise a deadlock whenever a process called by init would
try to set a property. This new thread, however, would send a message
via a blocking socket to init for each property that it received,
since init may need to take action depending on which property it is.
Unfortunately, this means that the deadlock is still possible, the
only difference is the socket's buffer must be filled before init deadlocks.
There are possible partial solutions here: the socket's buffer may be
increased or property_service may only send messages for the
properties that init will take action on, however all of these
solutions still lead to eventual deadlock. The only complete solution
is to handle these messages asynchronously.
This change, therefore, adds the following:
1) A lock for instructing init to reboot
2) A lock for waiting on properties
3) A lock for queueing new properties
4) A lock for any actions with ServiceList or any Services, enforced
through thread annotations, particularly since this code was not
designed with the intention of being multi-threaded.
Bug: 146877356
Bug: 148236233
Test: boot
Test: kill hwservicemanager without deadlock
Merged-In: I84108e54217866205a48c45e8b59355012c32ea8
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
(cherry picked from commit 7205c6293341c82701e849fa29cfab66916d1052)
2020-01-29 23:09:24 +01:00
|
|
|
auto lock = std::lock_guard{event_queue_lock_};
|
2018-02-14 00:36:14 +01:00
|
|
|
// We are shutting down so don't claim the oneshot builtin actions back
|
|
|
|
current_executing_actions_ = {};
|
|
|
|
event_queue_ = {};
|
|
|
|
current_command_ = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace init
|
|
|
|
} // namespace android
|