Re: [RFC PATCH v1 15/25] unwind_user/eh_frame: Duplicate registered .eh_frame[_hdr] section data on clone/fork

On 8/18/2026 5:11 PM, sashiko-bot@kernel.org 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.

quoted

diff --git a/kernel/unwind/eh_frame.c b/kernel/unwind/eh_frame.c

quoted

+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)
jremus@de.ibm.com / jremus@linux.ibm.com

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/