fs_mgr_overlayfs: Support remounting submounts
The move mount motions logic are built on top of heuristics and allow
non-fatal failures.
If the overlay was setup and mounted without reboot (this could happen
if AVB is disabled), the mount state (especially the MS_SHARED and
MS_PRIVATE flags) can still get skewed somehow, due to unforeseen errors
or resource race.
It is always advised to reboot after initial overlay setup, as the
overlay mount logic is less likely to require moving submounts when
executed by `init`, this provides the greatest chance of success.
Below is an example of the expected outcome of remounting submounts:
[precondition]
* AVB is already disabled, so overlay is setup and mounted w/o reboot
* No existing overlay; is initial overlay setup
0. /proc/self/mountinfo would contain something like:
<id> <parent id> <mountpoint> <shared/private> <filesystem>
2 1 /product shared:2 erofs
3 2 /product/app shared:3 erofs
1. adb remount /product/app
(note how the mount flag of <3> changes to private so <30> can be
MS_MOVE later)
2 1 /product shared:2 erofs
3 2 /product/app private erofs
30 3 /product/app shared:30 overlay
2. adb remount /product
(note how the parent of <30> changes to <40> as the result of MS_MOVE)
(note that <3> is _not_ moved)
2 1 /product private erofs
3 2 /product/app private erofs
30 40 /product/app shared:30 overlay
40 2 /product shared:40 overlay
Bug: 306124139
Test: adb-remount-test
Test: Verified with a remount submount scenario by editing the fstab.
Test: remount /system/bin then /system and verify the submount overlay
(/system/bin) is moved under the parent mount overlay (/system).
Change-Id: I6cdbe8c52d826a6f03fd363c909ebb0005446b96
2 files changed
