Current behavior:
Assume not checkpointing
cp_startCheckpoint creates the file in metadata
cp_needsCheckpoint will now set isCheckpointing to true
cp_commitCheckpoint will now think there is a checkpoint, and try to
commit it. This will fail on ext4 and it will return false, leading to
bad things.
cp_startCheckpoint is called when staging an apex module for update.
After this point, several things could go wrong:
If a keystore key is deleted, it calls cp_needsCheckpoint to see if the
delete should be deferred until cp_commitCheckpoint. The delete will now
be deferred, meaning that this key will never be deleted, using up the
key sots in trustzone
If a trim is scheduled through idle maintenance, this also calls
cp_needsCheckpoint, so the trims will not occur.
If either of these happens before a system crash, the device will not
recover since the system calls commitCheckpoint which will now crash.
When the system then goes on to reboot, the checkpoint will not be
triggered, since the commitCheckpoint call will have deleted the
checkpoint flag file before crashing.
Bug: 138952436
Test: vdc checkpoint startCheckpoint 5
vdc checkpoint needsCheckpoint
vdc checkpoint commitChanges
stop;start
commitChanges fails, then device loops
After applying this test, commitChanges succeeds and device does
not loop
Change-Id: I135099625f77344d1f8d2e8688735871c44ef2f5
If cp_commitCheckpoint is called twice at the same time, the second call
to setBowState will fail.
Add lock to remove possibility, and protect all uses of isCheckpointing
Bug: 138952436
Test: Boots after flashing in checkpoint mode
Change-Id: I131298adc506c3c176774d15e642b13d5f991087
Don't make stale zero'ing IO in block device after unlink, since filesystem
can reuse the block addresses and issue some IOs. If block layer reordered
two IOs, filesystem will see zero data, which crashes filesystem consistency.
Bug: 136964285
Test: run cts -m CtsDevicePolicyManagerTestCases -t com.android.cts.devicepolicy.CrossProfileAppsHostSideTest
Change-Id: I43c13622d094cecda1c53468adc240002111d605
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
am: 39a0ecec18 -s ours
am skip reason: change_id I8365a40298b752af4bb10d00d9ff58ce04beab1f with SHA1 236e5e800e is in history
Change-Id: I2596b55b73e6eb969fa9b8c596acf0329c36ac52
am: 7d43cb0ae9 -s ours
am skip reason: change_id I8365a40298b752af4bb10d00d9ff58ce04beab1f with SHA1 236e5e800e is in history
Change-Id: I2b29a01279fcd03f35a17156d5eafc42ce510980
am: d233d202ba -s ours
am skip reason: change_id I20441964dbc7b6ad5b445fa17a1374c1282bbbd8 with SHA1 3f1ce062d5 is in history
Change-Id: I54fdd0db5490c80810aac4dca04b42d18b9b44ee
am: d5fe5cfcb5 -s ours
am skip reason: change_id I20441964dbc7b6ad5b445fa17a1374c1282bbbd8 with SHA1 3f1ce062d5 is in history
Change-Id: Iab7f9bf4e3d7968384b2a35ae398e60e84bf0664
am: 125e79e344 -s ours
am skip reason: change_id I8365a40298b752af4bb10d00d9ff58ce04beab1f with SHA1 236e5e800e is in history
Change-Id: I27f743c943364f372261d7a6aa93d9dfbf2ae634
am: 3507d68556 -s ours
am skip reason: change_id I20441964dbc7b6ad5b445fa17a1374c1282bbbd8 with SHA1 3f1ce062d5 is in history
Change-Id: I2a5fe3fc7bbf3af55facde1ab07bd0559d8e7d87
am: 13539f79f5 -s ours
am skip reason: change_id I8365a40298b752af4bb10d00d9ff58ce04beab1f with SHA1 236e5e800e is in history
Change-Id: I0ed87e8107d4007c42545397d2cb03628527671a
Paul Lawrence
Treehugger Robot
android-build-team Robot
Jaegeuk Kim
David Anderson
Xin Li