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:	Mon, 31 Mar 2014 22:58:12 -0400
From:	Don Zickus <dzickus@...hat.com>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	acme@...stprotocols.net, LKML <linux-kernel@...r.kernel.org>,
	jmario@...hat.com, fowles@...each.com, peterz@...radead.org,
	eranian@...gle.com, andi.kleen@...el.com
Subject: Re: [PATCH 4/6 V2] perf, sort:  Add physid sorting based on mmap2
 data

On Sat, Mar 29, 2014 at 06:11:52PM +0100, Jiri Olsa wrote:
> On Mon, Mar 24, 2014 at 04:57:18PM -0400, Don Zickus wrote:
> > In order for the c2c tool to work correctly, it needs to properly
> > sort all the records on uniquely identifiable data addresses.  These
> > unique addresses are converted from virtual addresses provided by the
> > hardware into a kernel address using an mmap2 record as the decoder.
> > 
> > Once a unique address is converted, we can sort on them based on
> > various rules.  Then it becomes clear which address are overlapping
> > with each other across mmap regions or pid spaces.
> > 
> > This patch just creates the rules and inserts the records into a
> > sort entry for safe keeping until later patches process them.
> > 
> > The general sorting rule is:
> 
> SNIP
> 
> > +
> > +static int64_t
> > +sort__physid_major_cmp(struct hist_entry *left, struct hist_entry *right)
> > +{
> > +	struct map *l = left->mem_info->daddr.map;
> > +	struct map *r = right->mem_info->daddr.map;
> > +
> > +	return r->maj - l->maj;
> 
> I got segfault here, and consequently in all other sorting
> functions, because it failed to resolve map earlier in
> ip__resolve_data
> 
> we need to check it here, or before adding to the tree

Crap.  I checked it before, when I had one big function.  I forgot to
carry that though.  Honestly I would love to block these before they made
it to the sort routine but don't know a good way without adding checks to
all the builtins.

Cheers,
Don
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ