[PATCH] malloc: Fix ABBA deadlock in fork handlers

[Adhemerval Zanella Netto]

On 18/06/26 01:26, H.J. Lu wrote:
> On Thu, Jun 18, 2026 at 11:04 AM Cuishuangjin <YS.cuishuangjin@h3c.com> wrote:
>>
>> Dear H.J. and glibc maintainers,
>>
>> Thank you for reviewing our findings on the ABBA deadlock issue. Based on your suggestion, I have opened a glibc Bugzilla report with all relevant details:
>>
>> Summary of Provided Materials
>> The report includes:
>>
>> Complete Test Case - Demonstrates the deadlock under two different allocator environments
>> Reproduction Steps - Clear instructions to reproduce the issue
>> GDB Backtraces - Showing the deadlock call stacks
>> Lock Ordering Analysis - Detailed analysis of the lock inversion
>> Two Independent Reproductions:
>> Using ptmalloc standalone allocator
>> Using a minimal allocator interposer (independent of ptmalloc internals)
>> Key Technical Insights
>> The analysis confirms that the issue is not implementation-specific but rather a design-level lock ordering problem affecting any malloc implementation that:
>>
>> Uses pthread_atfork() for fork-safety
>> Dynamically registers handlers at runtime
>> Has prepare handlers that acquire malloc locks
>> Request for Guidance
>> Could you please help review whether:
>>
>> The analysis is accurate - Does our understanding of the lock inversion match glibc's internal design?
>> The fix direction is appropriate - Is the proposed approach of ensuring consistent lock ordering between atfork_lock and allocator locks suitable for glibc?
>> There are additional considerations - Are there other aspects we should address in the patch?
>> Next Steps Suggestion
>> If the analysis is deemed correct, we would appreciate guidance on:
> 
> Do you have a glibc bug?
I have opened BZ 34321 [1], and I think is a real issue that only occurs with
interposable mallocs (I write an analysis on the bug report). The easiest fix
would to revert back to a linked list (we moved to a dynamic array with
27761a1042daf01987e7d79636d0c41511c6df3c), but I do not see the need to use a
lock-free algorithm (so a simpler code).

Also, I think this is the missing spot where we can allocate while holding
the lock, we fixed the missing one with 52a103e237329b9f88a28513fe7506ffc3bd8ced.

I will send a patch to fix this, the original proposal of weak functions
is not applicable and does not fully fix the issue.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=34321