Bug report
In the free threading build, _PyMem_mi_page_maybe_free is called on mimalloc pages when they're about to be freed. We delay freeing of some pages in case another thread may be concurrently accessing it. In the meantime, they're stored on the tstate->mimalloc.page_list linked list.
_PyMem_mi_page_maybe_free inserts the page into the current thread's list. However, during GC and other stop-the-world pauses, we may traverse the heaps of other threads. That traversal does some processing of free lists, which can end up calling _PyMem_mi_page_maybe_free. In that case, we should insert the page into the owning thread's list, not the current thread's list. Otherwise, we can end up with a data race later on.
For more background see:
https://github.com/python/cpython/blob/main/InternalDocs/qsbr.md
Bug report
In the free threading build,
_PyMem_mi_page_maybe_freeis called on mimalloc pages when they're about to be freed. We delay freeing of some pages in case another thread may be concurrently accessing it. In the meantime, they're stored on thetstate->mimalloc.page_listlinked list._PyMem_mi_page_maybe_freeinserts the page into the current thread's list. However, during GC and other stop-the-world pauses, we may traverse the heaps of other threads. That traversal does some processing of free lists, which can end up calling_PyMem_mi_page_maybe_free. In that case, we should insert the page into the owning thread's list, not the current thread's list. Otherwise, we can end up with a data race later on.For more background see:
https://github.com/python/cpython/blob/main/InternalDocs/qsbr.md