Commit graph

8 commits

Author SHA1 Message Date
Tom Cherry
832f9f1dbd Revert "init: handle property service callbacks asynchronously"
This is apparently causing problems with reboot.

This reverts commit 7205c62933.

Bug: 150863651
Test: build
Change-Id: Ib8a4835cdc8358a54c7acdebc5c95038963a0419
2020-03-10 11:53:11 -07:00
Tom Cherry
7205c62933 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
Change-Id: I84108e54217866205a48c45e8b59355012c32ea8
2020-02-20 14:58:06 -08:00
Nikita Ioffe
ba6968e636 Add a skeleton of userspace reboot
This CL only draws boundaries between userspace and full reboots, and
adds some functionality that will be required for userspace reboot:

* Whenever device is shutting down is now controlled in reboot.cpp,
  since during userspace reboot this state can change.
* Now it's also possible to restart handling of control messages inside
  property service. In case of userspace reboot, init will restart it
  after stopping post-data services.
* New userspace-reboot-requested trigger is added similar to shutdown
  one for full reboot.

Test: adb reboot
Test: adb reboot userspace
Bug: 135984674
Change-Id: Id55a53ba781d2b90ce40449037b6d8d47e72c476
2019-10-08 12:16:06 +01:00
Tom Cherry
1ab3dfcab4 Reland^2: "init: run property service in a thread"
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command.  This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.

This change has init run property service in a thread, which
eliminates the above issue.

This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.

Reland: during reboot, init stops processing property_changed messages
from property service, since it will not act on these anyway.  This
had an unexpected effect of causing future property_set calls to block
indefinitely, since the buffer between init and property_service was
filling up and the send() call from property_service would then
block.  This change has init tell property_service to stop sending it
property_changed messages once reboot begins.

Test: CF boots, walleye boots, properties are set appropriately
Change-Id: I26902708e8be788caa6dbcf4b6d2968d90962785
2019-09-05 14:42:58 -07:00
Tom Cherry
3da2ba6d4a Revert "Reland: "init: run property service in a thread""
This reverts commit 8efca4bbb3.

Reason for revert: Still broken

Change-Id: I3b37b1b00ff4b19f2eec2d8bd72042463d47cee3
2019-08-28 17:47:49 +00:00
Tom Cherry
8efca4bbb3 Reland: "init: run property service in a thread"
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command.  This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.

This change has init run property service in a thread, which
eliminates the above issue.

This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.

Test: CF boots, walleye boots, properties are set appropriately
Change-Id: I13b8bf240c9fcb1d2d5890a8be2f0ef74efd4adf
2019-08-26 17:08:41 -07:00
Tom Cherry
f451426205 Revert "init: run property service in a thread"
This reverts commit 26f5e7da3a.

Reason for revert: bluecross boot stability issue

Bug: 140009641
Change-Id: I7ddb9509dfb2c6f644037129aa9d3fb9ff1740aa
2019-08-26 16:33:40 +00:00
Tom Cherry
26f5e7da3a init: run property service in a thread
It's been a long standing issue that init cannot respond to property
set messages when it is running a builtin command.  This is
particularly problematic when the commands involve IPC to vold or
other daemons, as it prevents them from being able to set properties.

This change has init run property service in a thread, which
eliminates the above issue.

This change may also serve as a starting block to running property
service in an entirely different process to better isolate init from
handling property requests.

Test: CF boots, walleye boots, properties are set appropriately
Change-Id: Id9534a5916abb2f7d2a49cda54e33c1b69c50c2f
2019-08-21 08:26:09 -07:00