Re: [PATCH v14 11/19] unwind_user/sframe: Show file name in debug output

[Jens Remus <jremus@linux.ibm.com>]

On 5/12/2026 4:52 PM, Jens Remus wrote:
> On 5/5/2026 8:46 PM, sashiko-bot@kernel.org wrote:
> 
>> [ ... ]
>>> @@ -496,7 +501,7 @@ static int __sframe_remove_section(struct mm_struct *mm,
>>>  				   struct sframe_section *sec)
>>>  {
>>>  	if (!mtree_erase(&mm->sframe_mt, sec->text_start)) {
>>> -		dbg("mtree_erase failed: text=%lx\n", sec->text_start);
>>> +		dbg_sec("mtree_erase failed: text=%lx\n", sec->text_start);
>>
>> Does accessing sec->filename in dbg_sec() risk a use-after-free here? If
>> mtree_erase() fails, it indicates the section might have been concurrently
>> removed. The SRCU grace period could expire, causing sec to be freed before
>> dbg_sec() is called.
> 
> IIUC this is a valid concern.  Should this change be simply be reverted
> or should __sframe_remove_section() create a temporary copy of the
> filename and use dbg() for this rather unlikely case?

On my way home it occurred to me that adding guard(srcu)(&sframe_srcu);
to sframe_remove_section() (see my feedback on "[PATCH v14 03/19]
unwind_user/sframe: Store .sframe section data in per-mm maple tree")
should also resolve this use-after-free without any need for changes.

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/