答复: [PATCH] malloc: Fix ABBA deadlock in fork handlers

[Cuishuangjin]

Hi Florian,

Thank you for your feedback. I apologize for the earlier garbled patch summary — let me clarify the actual issue and how it differs from bug 34021.

Summary of the Issue
This is not the same as bug 34021. While both involve allocator locks during fork(), the lock inversion occurs in a different code path and involves different locks.

Lock Order Difference
ScenarioLocks InvolvedOrder in Thread AOrder in Thread B
Bug 34021allocator_lock ↔ _IO_proc_file_chain_lockallocator_lock → _IO_proc_file_chain_lock_IO_proc_file_chain_lock → allocator_lock
This Issueatfork_lock ↔ malloc_lockatfork_lock → malloc_lockmalloc_lock → atfork_lock
Code Path Analysis
Bug 34021 occurs when:

Thread A (fork()): __run_prefork_handlers() → allocator_lock → _IO_proc_file_chain_lock
Thread B (popen()): _IO_proc_file_chain_lock → malloc() → allocator_lock
This issue occurs in the atfork handler registration/execution path:

Thread A (__run_prefork_handlers):

Holds atfork_lock
Releases atfork_lock to execute prepare handlers
Calls ptmalloc_lock_all() → acquires malloc_lock
Attempts to re-acquire atfork_lock (blocked)
Thread B (__register_atfork):

Acquires atfork_lock
Calls fork_handler_list_emplace()
Calls malloc() → attempts to acquire malloc_lock (blocked)
Visual Timeline
Timeline │ Thread A (__run_prefork_handlers)      │ Thread B (__register_atfork)
─────────┼────────────────────────────────────────┼─────────────────────────────
 T1      │ Holds atfork_lock                      │
 T2      │   lll_unlock(atfork_lock) ───────────► │
 T3      │ Executes prepare_handler()             │   lll_lock(atfork_lock)
 T4      │ └─► ptmalloc_lock_all()                │ Holds atfork_lock
 T5      │ Holds malloc_lock                      │   fork_handler_list_emplace()
 T6      │   lll_lock(atfork_lock) ◄─ Blocked ─── │ └─► malloc() ◄─ Blocked ─┐
复制
Timeline │ Thread A (__run_prefork_handlers)      │ Thread B (__register_atfork)
─────────┼────────────────────────────────────────┼─────────────────────────────
 T1      │ Holds atfork_lock                      │
 T2      │   lll_unlock(atfork_lock) ───────────► │
 T3      │ Executes prepare_handler()             │   lll_lock(atfork_lock)
 T4      │ └─► ptmalloc_lock_all()                │ Holds atfork_lock
 T5      │ Holds malloc_lock                      │   fork_handler_list_emplace()
 T6      │   lll_lock(atfork_lock) ◄─ Blocked ─── │ └─► malloc() ◄─ Blocked ─┐
​
Why This Matters
This deadlock affects any custom malloc implementation that:

Uses pthread_atfork for fork-safety
Registers handlers dynamically during runtime
Has prepare handlers that acquire malloc locks
The fix requires ensuring consistent lock ordering between atfork_lock and allocator locks in both the execution path (__run_prefork_handlers) and registration path (__register_atfork).

Proposed Approach
Weaken the strong definitions of __malloc_fork_lock_parent and related symbols in glibc
Strengthen malloc_lock management in __register_atfork prepare handlers
Document the requirements for custom malloc implementations
As you noted, we'll need to:

Clearly mention custom malloc implications in commit messages
Update the "Replacing malloc" documentation
Add appropriate symbol versioning (GLIBC_2.44) if new interfaces are introduced
Please let me know if this clarifies the distinction from bug 34021.

Best regards,
ShuangJin Cui


-----邮件原件-----
发件人: Florian Weimer [mailto:fweimer@redhat.com]
发送时间: 2026年5月11日 14:42
收件人: cuishuangjin ys43405(CW, RD) <YS.cuishuangjin@h3c.com>
抄送: libc-alpha@sourceware.org; zhangchun (操作系统开发部/内核开发部, RD) <zhang.chunA@h3c.com>
主题: Re: [PATCH] malloc: Fix ABBA deadlock in fork handlers


温馨提示： 此邮件来自公司外部，请核实发件人信息，慎点链接与附件。This is an external email. Please verify the sender's information and proceed with caution when clicking links or downloading attachments.



* Cuishuangjin:

> - Solution: Weaken definitions of __malloc_fork_lock_parent,
> __malloc_fork_unlock_parent, and _ _malloc_fork_unlock_child in glibc
> 2.38-50 to prevent hard-linking inconsistencies. Strengthen
> malloc_lock management in __register_atfork prepare_handler functions
> for ptmalloc and tcmalloc libraries.

The patch was garbled, but according to the diff summary, it did not contain changes like that.

Is this for bug 34021?

The key part is that this involves a custom malloc.  The commit message must mention that.  The “Replacing malloc” section in the manual needs to document the new interface.  Depending on how this is implemented, you need to add GLIBC_2.44 symbol versions for the new interfaces and update the *.abilist files.

Thanks,
Florian

-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。
禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。
如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above.
Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited.
If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!