Re: [PATCH v4 25/39] unwind_user/sframe: Show file name in debug output

Josh Poimboeuf <[email protected]>
Newsgroups org.kernel.vger.linux-toolchains,org.kernel.vger.linux-kernel,org.kernel.vger.linux-perf-users,org.kernel.vger.linux-trace-kernel
Message-ID <20250204191017.iqrew5zgxg7eh4s2@jpoimboe>
On Thu, Jan 30, 2025 at 05:17:33PM +0100, Jens Remus wrote:
> On 22.01.2025 03:31, Josh Poimboeuf wrote:
> > When debugging sframe issues, the error messages aren't all that helpful
> > without knowing what file a corresponding .sframe section belongs to.
> > Prefix debug output strings with the file name.
> > 
> > Signed-off-by: Josh Poimboeuf <[email protected]>
> 
> > diff --git a/kernel/unwind/sframe_debug.h b/kernel/unwind/sframe_debug.h
> 
> > +static inline void dbg_init(struct sframe_section *sec)
> > +{
> > +	struct mm_struct *mm = current->mm;
> > +	struct vm_area_struct *vma;
> > +
> > +	guard(mmap_read_lock)(mm);
> > +	vma = vma_lookup(mm, sec->sframe_start);
> > +	if (!vma)
> > +		sec->filename = kstrdup("(vma gone???)", GFP_KERNEL);
> > +	else if (vma->vm_file)
> > +		sec->filename = kstrdup_quotable_file(vma->vm_file, GFP_KERNEL);
> > +	else if (!vma->vm_mm)
> 
> This condition does not appear to work for vdso on s390.

I had a fix for this which somehow got dropped:

diff --git a/kernel/unwind/sframe_debug.h b/kernel/unwind/sframe_debug.h
index 3bb3c5574aee..045e9c0b16c9 100644
--- a/kernel/unwind/sframe_debug.h
+++ b/kernel/unwind/sframe_debug.h
@@ -67,6 +67,10 @@ static inline void dbg_init(struct sframe_section *sec)
 		sec->filename = kstrdup("(vma gone???)", GFP_KERNEL);
 	else if (vma->vm_file)
 		sec->filename = kstrdup_quotable_file(vma->vm_file, GFP_KERNEL);
+	else if (vma->vm_ops && vma->vm_ops->name)
+		sec->filename = kstrdup(vma->vm_ops->name(vma), GFP_KERNEL);
+	else if (arch_vma_name(vma))
+		sec->filename = kstrdup(arch_vma_name(vma), GFP_KERNEL);
 	else if (!vma->vm_mm)
 		sec->filename = kstrdup("(vdso)", GFP_KERNEL);
 	else
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.