linux-kernel - Re: [PATCH 1/9] perf, tools: Support handling complete branch stacks as histograms v6

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: <20140523213503.GD29957@tassilo.jf.intel.com>
Date:	Fri, 23 May 2014 14:35:03 -0700
From:	Andi Kleen <ak@...ux.intel.com>
To:	Namhyung Kim <namhyung@...il.com>
Cc:	Andi Kleen <andi@...stfloor.org>, jolsa@...hat.com,
	linux-kernel@...r.kernel.org, acme@...radead.org
Subject: Re: [PATCH 1/9] perf, tools: Support handling complete branch stacks
 as histograms v6

On Mon, May 19, 2014 at 05:21:15PM +0900, Namhyung Kim wrote:
> This is gone with 540476de74c9 ("perf tools: Remove
> symbol_conf.use_callchain check").

The patchkit applies to tip/perf/core.

> > +				 * Check for overlap into the callchain.
> > +				 * The return address is one off compared to
> > +				 * the branch entry. To adjust for this
> > +				 * assume the calling instruction is not longer
> > +				 * than 8 bytes.
> > +				 */
> > +				if (be[i].from < chain->ips[first_call] &&
> > +				    be[i].from >= chain->ips[first_call] - 8)
> > +					first_call++;
> 
> It seems that you need to check chain->ips[first_call] is greater than
> PERF_CONTEXT_MAX and use such value as the cpumode...

I don't understand the comment. The only IP that gets resolved is the from/to.
And add_callchain_ip does it own resolution.

Wouldn't make any sense to get it from first_call

> 
> 
> > +			} else
> > +				be[i] = branch->entries[branch->nr - i - 1];
> > +		}
> > +
> > +		nr = remove_loops(be, nr);
> > +
> > +		for (i = 0; i < nr; i++) {
> > +			err = add_callchain_ip(machine, thread, parent,
> > +					       root_al,
> > +					       -1, be[i].to);
> > +			if (!err)
> > +				err = add_callchain_ip(machine, thread,
> > +						       parent, root_al,
> > +						       -1, be[i].from);
> 
> ... for here.
> 
> 
> > +			if (err == -EINVAL)
> > +				break;
> > +			if (err)
> > +				return err;
> > +		}
> > +		chain_nr -= nr;
> 
> It seems it could make some callchain nodes being ignored.  What if a
> case like small callchains with matches to only 2 nodes in the LBR?
> 
>   nr = 16, chain_nr = 10 and first_call = 2

The chain_nr variable is just to handle it when the user
specified a max_stack value. nr is always capped to max_stack too.
If lbr size is >= max_stack it will end up being 0 or negative and the 
following loop to add normal call stack entries will do nothing.

I think that's the correct behavior.

-Andi
--
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/