linux-kernel - Re: [RFC/PATCH 17/38] perf tools: Maintain map groups list in a leader thread

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]

Date:	Fri, 9 Oct 2015 15:58:49 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	LKML <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Stephane Eranian <eranian@...gle.com>,
	David Ahern <dsahern@...il.com>,
	Andi Kleen <andi@...stfloor.org>
Subject: Re: [RFC/PATCH 17/38] perf tools: Maintain map groups list in a
 leader thread

On Thu, Oct 08, 2015 at 02:58:00PM +0200, Jiri Olsa wrote:
> On Fri, Oct 02, 2015 at 02:18:58PM +0900, Namhyung Kim wrote:
> 
> SNIP
> 
> >  int __thread__set_comm(struct thread *thread, const char *str, u64 timestamp,
> >  		       bool exec)
> >  {
> > @@ -182,6 +257,40 @@ int __thread__set_comm(struct thread *thread, const char *str, u64 timestamp,
> >  			unwind__flush_access(thread);
> >  	}
> >  
> > +	if (exec) {
> > +		struct machine *machine;
> > +
> > +		BUG_ON(thread->mg == NULL || thread->mg->machine == NULL);
> > +
> > +		machine = thread->mg->machine;
> > +
> > +		if (thread->tid != thread->pid_) {
> > +			struct map_groups *old = thread->mg;
> > +			struct thread *leader;
> > +
> > +			leader = machine__findnew_thread(machine, thread->pid_,
> > +							 thread->pid_);
> > +
> > +			/* now it'll be a new leader */
> > +			thread->pid_ = thread->tid;
> > +
> > +			thread->mg = map_groups__new(old->machine);
> > +			if (thread->mg == NULL)
> > +				return -ENOMEM;
> > +
> > +			/* save current mg in the new leader */
> > +			thread__clone_map_groups(thread, leader);
> > +
> > +			/* current mg of leader thread needs one more refcnt */
> > +			map_groups__get(thread->mg);
> > +
> > +			thread__set_map_groups(thread, thread->mg, old->timestamp);
> > +		}
> > +
> > +		/* create a new mg for newly executed binary */
> > +		thread__set_map_groups(thread, map_groups__new(machine), timestamp);
> 
> should this     ^^^^ be in the else case of above condition?

Nop.  Above condition is to make the thread a new leader thread and
for that purpose, it clones old thread->mg and add into the mg_list.
Because a non-leader thread don't have mg_list.

After that, we can add a new mg to the now-available mg_list.

> 
> also thread__fork calls thread__clone_map_groups once again,
> I have some difficulty to sort this out ATM.. is that correct?

In fork case, above code will not be called since it's only for exec path.

> 
> some comment on how we treat map groups in general (for fork/clone/exit)
> would be awesome ;-)

I admit that this code is subtle and confusing..  How about this?

Managing map groups is subtle in that we basically want to share a map
groups between threads in a process.  When a new process is created
(forked), the child clones (current) map groups from the parent.  But
if a new thread is called it only gets a reference of the leader's mg.

Complication comes from the exec as we also want to keep the history
of a thread's execution, so the map groups are now managed by mg_list.
This mg_list is maintained by leader threads only, and non-leader
threads have a reference a mg at the time in the mg_list.  It uses a
timestamp at the event to find out the correct mg in the mg_list.

One corner case is when exec is called from a non-leader thread.  We
want to add a new mg to the mg_list in the thread.  But it doesn't
have a mg_list since it was not a leader.  So it sets up a mg_list and
insert a cloned mg from the old leader.  Now it can handle exec as
usual - create a new mg and insert it to the mg_list.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/