[roll] Roll fuchsia [kernel][phys] Avoid mappings and allocations after VM handoff This fixes the problem of new mappings in the kernel address space, and/or new physical page allocations, being made in the course of the handoff work after the VM handoff data structures have been populated. This consolidates HandoffPrep::FinishVmObjects() and HandoffPrep::SetMemory() into a single method FinishVm(). It must reify all the VM handoff other than that of the temporary handoff mappings themselves first, and then preallocate handoff space for the temporary handoff mappings such that nothing more will change in populating that part of the VM handoff or the physical memory range handoff. To catch bugs like this creeping back in, make sure an assertion failure will trip if the handoff allocators try to make new mappings after their mapping lists have already been collected for VM handoff. Also, use ktl::optional wrappers to mark the HandoffPrep and PhysPages members as off limits after their data has been collected in FinishVm() and use assertions to ensure any attempts to make new mappings too late will be caught. Run-All-Tests: true Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1485736 Original-Revision: 1e7698e0c7ac585e765f4f6689157813d5c5ded3 GitOrigin-RevId: d38ac32a87a863b882e54dc0f7d109b07bb39654 Change-Id: Ie30ec6a95e5b0ce3b5df0f5c12e7e7e7d915cdba
This repository contains Fuchsia's Global Integration manifest files.
All changes should be made to the internal version of this repository. Our infrastructure automatically updates this version when the internal one changes.
Currently all changes must be made by a Google employee. Non-Google employees wishing to make a change can ask for assistance in one of the communication channels documented at get involved.
First install Jiri.
Next run:
$ jiri init $ jiri import minimal https://fuchsia.googlesource.com/integration $ jiri update
Third party projects should have their own subdirectory in ./third_party.