On 8/18/2026 5:11 PM, [email protected] wrote:
> This commit ensures that a process's registered .eh_frame_hdr sections are
> duplicated in the per-mm maple tree during virtual memory duplication. This
> enables stack tracing for child processes using eh_frame.
>> diff --git a/kernel/unwind/eh_frame.c b/kernel/unwind/eh_frame.c
>> +int eh_frame_dup_mm(struct mm_struct *mm, struct mm_struct *oldmm)
>> +{
>> + struct eh_frame_section *sec, *oldsec;
>> + unsigned long index = 0;
>> + int ret;
>> +
>> + guard(srcu)(&eh_frame_srcu);
>> +
>> + mt_for_each(&oldmm->eh_frame_mt, oldsec, index, ULONG_MAX) {
>> + sec = kzalloc(sizeof(*sec), GFP_KERNEL_ACCOUNT);
>> + if (!sec)
>> + return -ENOMEM;
>> +
>> + __eh_frame_dup_section(sec, oldsec);
>> +
>> + ret = mtree_insert_range(&mm->eh_frame_mt,
>> + sec->text_start,
>> + sec->text_end - 1,
>> + sec, GFP_KERNEL_ACCOUNT);
>> + if (ret)
>> + goto err_free;
>> + }
>> +
>> + return 0;
>> +
>> +err_free:
>> + free_section(sec);
>> + return ret;
>> +}
>
> [Severity: Low]
> This isn't a bug, but does this function mix scope-based cleanup with
> traditional goto-based error handling?
No. The guard(srcu)(&eh_frame_srcu) is for read access of the oldsec
obtained from the oldmm->eh_frame_mt. The goto-based error handling
is for the new copy sec, in case inserting into mm->eh_frame_mt failed.
>
> The kernel's cleanup guidelines specify that usage of goto and cleanup
> helpers like guard() should not be mixed in the same function. Could this
> be converted to use scope-based cleanup entirely, or avoid guard() to keep
> the style consistent?
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
[email protected] / [email protected]
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats:
Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft:
Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
