Revert "Implement cpuinfo_deinitialize() to free heap-allocated globals" - #411
Merged
Merged
Conversation
crvineeth97
added a commit
to microsoft/onnxruntime
that referenced
this pull request
Sep 2, 2026
### Description <!-- Describe your changes. --> - Update `pytorch/cpuinfo` from `4628dc060ce4e82345dc166bbac875609db4ff69` to `66ee79c038d70dad9f08705b2c9b3e58f6d8f512`, the latest commit on cpuinfo `main` as of August 27, 2026. - Carry the thread-safe, reference-counted initialization and deinitialization changes from [pytorch/cpuinfo#400](pytorch/cpuinfo#400) as one shared ORT patch used by both FetchContent and vcpkg. - Reset Windows ARM64 cache-population state on each initialization so repeated DLL load/unload cycles cannot reuse stale cache indices. - Scope XNNPACK's cpuinfo references to hardware discovery so XNNPACK-enabled ORT builds do not retain unmatched references during DLL unload. The cpuinfo patch can be removed after pytorch/cpuinfo#400, including the ARM64 reinitialization fix, is merged and ORT updates to a revision containing it. The XNNPACK compatibility patch can be removed after the corresponding lifecycle fix is available upstream. ### Motivation and Context <!-- - Why is this change required? What problem does it solve? - If it fixes an open issue, please link to the issue here. --> [#28245](#28245) integrated `cpuinfo_deinitialize()` after [pytorch/cpuinfo#387](pytorch/cpuinfo#387) added it upstream. That implementation was later reverted by [pytorch/cpuinfo#411](pytorch/cpuinfo#411) because initialization and deinitialization were not safe for multiple consumers. Pinning the latest cpuinfo `main` without an ORT-side patch would therefore make `cpuinfo_deinitialize()` a no-op again. Carrying the corrected implementation keeps ORT independent of the pending upstream review while preserving safe cleanup during dynamic DLL unload. ### Testing - `onnxruntime_cpuinfo_refcount_test` covers sequential consumers, concurrent consumers, and reinitialization after final release. - Verified this test fails against ORT `main`'s pinned cpuinfo revision (`4628dc060ce4e82345dc166bbac875609db4ff69`) and passes against the patched revision (`66ee79c038d70dad9f08705b2c9b3e58f6d8f512`). - In XNNPACK-enabled builds, the refcount test initializes XNNPACK and verifies hardware discovery does not retain a cpuinfo reference. - `onnxruntime_shared_lib_cpuinfo_dlopen_test` loads a small DLL containing ORT's `CPUIDInfo` and cpuinfo, captures a cpuinfo process-heap allocation, unloads the DLL, and verifies that allocation was released. - Verified the FetchContent patch sequences for the default, Linux, and Windows ARM64/ARM64EC paths, plus the vcpkg patch sequence, apply with zero rejected hunks. --------- Co-authored-by: Vineeth Chelur <vchelur@microsoft.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reverts #387 because it breaks a lots of the existing clients, as both
cpuinfo_initialize()andcpuinfo_deinitialize()should be reentrant and thread safe, but proposed implementation is not like that