Re: [PATCH] perf: add sanity check on addr insymbol__inc_addr_samples()

[Arnaldo Carvalho de Melo]

Em Thu, Feb 09, 2012 at 05:06:57PM +0200, Sorin Dumitru escreveu:
> On Thu, Feb 9, 2012 at 4:53 PM, Stephane Eranian <eranian@xxxxxxxxxx> wrote:
> > On Thu, Feb 9, 2012 at 3:48 PM, Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
> >> Em Thu, Feb 09, 2012 at 11:30:16AM +0100, Stephane Eranian escreveu:

> >>> Check the value of addr against the bounds of the symbol.
> >>> This is needed given we compute an offset:
> >>>       offset = addr - sym->start

> >>> And we don't want the offset to become negative.

> >> I'll try and add a debug option to show the backtrace and values of
> >> addr, sym, etc, so that we can fix the real problem.

> >> I.e. this function shouldn't be receiving any such invalid addresses, as
> >> the symbol lookup was done, the symbol was found to be this one, then
> >> why it would be out of bounds at this point?!

> > I tend to agree with you on this. But then I don't see why the first test
> > was there.
 
> I reported the same problem a couple of weeks ago. From what i can
> tell the problem is in perf_event__process_sample.

> When calling perf_event__process_sample, we set al->sym based on
> al->address.

> The symbol in the hist_entry is set to the one from al but in the call
> to perf_top__record_precise_ip we pass in the address from the event
> struct which is sometimes different than the one in the al structure.

> When this situation occurs, when calculating the offset in
> symbol__inc_addr_samples, because addr is not in the symbol
> [start,end] range, we get a very big value which causes the segfault
> when we use it to index something. I've sent a patch that works for
> me, but i don't know if it's the right solution at [1].
 
> [1] https://lkml.org/lkml/2012/1/29/59

Sorry for not having followed up on that one, now I'm trying to check if
it is valid but:

1. addr_location is set by perf_event__preprocess_sample that will call
   several routines that will figure out if the DSO symtab is loaded,
   load it if not, deal with prelinking, etc.

2. so at the end of this symbol resolution al.addr will point to the
   result of:

	al->map->map_ip(al->map, event->ip.ip)

3. in perf_top__record_precise_ip we'll use:

        he->ms.map->map_ip(he->ms.map, event->ip.ip)

And:

	he->ms.map == al->map

	So yeah, we can, as a worthwhile simplification, just pass
al.addr to perf_top__record_precise_ip as in your patch, but then we
need to remove the call to he->ms.map->map_ip.

	This extra call is harmless for identity mapped DSOs, as it
boils down to:

u64 identity__map_ip(struct map *map __used, u64 ip)
{               
        return ip;
} 

	But if the DSO uses:

u64 map__map_ip(struct map *map, u64 ip)
{                    
        return ip - map->start + map->pgoff;
} 

	Then we would be mapping the IP possibly to a negative one.

	So we need to revisit the details of your case and the one
Stephane (or Roberto) experienced, i.e. what kind of DSO? Prelinked?
etc.

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