linux-kernel - Re: [PATCH 2/2] perf unwind: fix libunwind when tid != pid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190804124434.204da4ac.john@metanate.com>
Date:   Sun, 4 Aug 2019 12:44:34 +0100
From:   John Keeping <john@...anate.com>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Namhyung Kim <namhyung@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] perf unwind: fix libunwind when tid != pid

On Fri, 2 Aug 2019 15:30:39 +0200
Jiri Olsa <jolsa@...hat.com> wrote:

> On Mon, Jul 29, 2019 at 06:24:30PM +0100, John Keeping wrote:
> > Commit e5adfc3e7e77 ("perf map: Synthesize maps only for thread group
> > leader") changed the recording side so that we no longer get mmap events
> > for threads other than the thread group leader.
> > 
> > When a file recorded after this change is loaded, the lack of mmap
> > records mean that unwinding is not set up for any other threads.  
> 
> sry I dont' follow what's the problem here, could you please
> describe the scenrio where the current code is failing in
> more details

With perf compiled to use libunwind, run:

	perf record --call-graph=dwarf -t $TID -- sleep 5
	perf report

If $TID is a process, then the output has the call graph, but if it's a
secondary thread then it is as if --no-call-graph was specified.

> > 
> > Following the rationale in that commit, move the libunwind fields into
> > struct map_groups and update the libunwind functions to take this
> > instead of the struct thread.  This is only required for
> > unwind__finish_access which must now be called from map_groups__delete
> > and the others are changed for symmetry.
> > 
> > Note that unwind__get_entries keeps the thread argument since it is
> > required for symbol lookup and the libdw unwind provider uses the thread
> > ID.  
> 
> SNIP
> 
> > @@ -59,37 +59,31 @@ int unwind__prepare_access(struct thread *thread, struct map *map,
> >  		return 0;
> >  	}
> >  out_register:
> > -	unwind__register_ops(thread, ops);
> > +	unwind__register_ops(mg, ops);
> >  
> > -	err = thread->unwind_libunwind_ops->prepare_access(thread);
> > +	err = mg->unwind_libunwind_ops->prepare_access(mg);
> >  	if (initialized)
> >  		*initialized = err ? false : true;
> >  	return err;
> >  }
> >  
> > -void unwind__flush_access(struct thread *thread)
> > +void unwind__flush_access(struct map_groups *mg)
> >  {
> > -	if (!dwarf_callchain_users)
> > -		return;  
> 
> why did you remove this check?

I don't think there is any way for unwind_libunwind_ops to be set if
!dwarf_callchain_users so this is redundant given the following
condition.

But this should probably be a separate patch.

> > -
> > -	if (thread->unwind_libunwind_ops)
> > -		thread->unwind_libunwind_ops->flush_access(thread);
> > +	if (mg->unwind_libunwind_ops)
> > +		mg->unwind_libunwind_ops->flush_access(mg);
> >  }
> >  
> > -void unwind__finish_access(struct thread *thread)
> > +void unwind__finish_access(struct map_groups *mg)
> >  {
> > -	if (!dwarf_callchain_users)
> > -		return;  
> 
> why did you remove this check?

Likewise.


Regards,
John