[shaxntanu]

Summary

• Add a shutdown-only first finaliser pass for VFS file wrappers and FAT directory iterators, so they close while their backing storage and buses are available.
• Keep normal garbage collection and all remaining finalisers in their existing order; the shutdown ordering does not depend on heap addresses.
• Extend the manual SD-card soft-reload test to free and reuse heap blocks below the SDCard before opening a file.

Fixes #11562

Testing

• Build CI: all 690 jobs completed; 689 passed and the docs job was skipped.
• Unix test jobs: passed.
• Zephyr simulation jobs: passed, including native_sim.
• Pre-commit and Read the Docs: passed.
• The SD-card reload scenario has not been run on physical hardware.

[dhalbert]

EDIT: my previous comment wasn't quite right, but the principle stands.

The finaliser table is a bitmap indexed by heap block. So the reverse sweep only works if the SDCardobject is lower in in the heap than the file object. But a gc could free blocks below the SDCard and then a file object could be lower in the heap.

[shaxntanu]

Thanks for catching this. I removed the reverse bitmap sweep. Shutdown now has an explicit first pass for finalizer types that must close before their backing resources; FAT, LittleFS, POSIX file wrappers, and the FAT directory iterator finalizer are marked for that pass. Other finalizers stay on the normal teardown path.

I also updated the manual regression test to allocate and free heap space below the SDCard before opening the file, so it exercises the lower-address reuse case you described. The earlier broad pre-reset finalizer pass caused Zephyr PWM trace failures; this narrower pass avoids those. The updated Build CI matrix has finished: all 690 jobs completed (689 passed; docs skipped). Unix, Zephyr simulation (including native_sim), pre-commit, and Read the Docs checks are green.

[dhalbert]

This problem has come up in other contexts, like #11108, and is a general problem that would be solved by a topological sort (#11108 (comment)), but it's not easy.

The MP_TYPE_FLAG_FINALISER_FIRST flag you propose is a manual way to solve the problem, and maybe it's good enough for single-level ordering. I'll discuss this with the other core developers - thanks.

[shaxntanu]

Thanks for the context. I agree that MP_TYPE_FLAG_FINALISER_FIRST is a scoped, manual ordering mechanism, while a topological sort would address the broader problem. I’ll wait for the core developers’ discussion and adjust this PR based on the team’s direction.