Re: [PATCH v14 03/19] unwind_user/sframe: Store .sframe section data in per-mm maple tree

On 5/6/2026 5:21 PM, Steven Rostedt wrote:
> On Wed, 6 May 2026 15:50:45 +0200
> Jens Remus <[email protected]> wrote:

>>> [ ... ]  
>>>> @@ -1100,6 +1109,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p,
>>>>  	mm->pmd_huge_pte = NULL;
>>>>  #endif
>>>>  	mm_init_uprobes_state(mm);
>>>> +	mm_init_sframe(mm);
>>>>  	hugetlb_count_init(mm);
>>>>  
>>>>  	mm_flags_clear_all(mm);  
>>>
>>> When a process forks, this initializes an empty sframe_mt for the child's
>>> mm_struct. While dup_mmap() duplicates the parent's VMAs, it doesn't appear
>>> that the registered .sframe entries are propagated to the child's maple tree.
>>> Will child processes silently lose their .sframe unwind data for shared
>>> libraries registered prior to the fork?  
>>
>> Does this ring any bell, Steven?  I ran into it with my signal frame
>> stacktracing test on s390.  I think we discussed this during one of the
>> SFrame calls and it got lost.  
> 
> Oh, this is a good point. I think we need to copy the sframe mt on
> fork, not initialize it.

I'll send a patch with my next version very soon.  Hopefully you did not
spend too much time on that yet.  Review will be much appreciated!

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/