linux-kernel - Re: [PATCH v4 2/2] perf: report/annotate: fix segfault problem.

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:	Thu, 9 Apr 2015 13:40:42 +0200
From:	Jiri Olsa <jolsa@...hat.com>
To:	Wang Nan <wangnan0@...wei.com>
Cc:	acme@...nel.org, jolsa@...nel.org, namhyung@...nel.org,
	mingo@...hat.com, lizefan@...wei.com, pi3orama@....com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/2] perf: report/annotate: fix segfault problem.

On Thu, Apr 09, 2015 at 03:05:27PM +0800, Wang Nan wrote:

SNIP

> When mmap event at kernel address space occures, it distinguishes kernel and kernel module
> according to the name in mmap event. Unfortunately, '[test_module]' won't be regarded as kernel
> at this time, so according map__kmap(map)->kmaps won't get initialized.
> 
> If we don't have buildid-cache for [test_module], machine__process_kernel_mmap_event -->
> machine__new_module --> machine__module_dso --> dsos__find will return failuer, and a new
> struct dso is created using dsos__addnew, its default dso->kernel is DSO_TYPE_USER.
> 
> Step 3: process_sample_event -> map__load: a sample with kernel IP is arise, perf
>         tries to load DSO of such address.
> 
> Step 4: map__load -> dso__load: in dso__load():
> 
> int dso__load(struct dso *dso, struct map *map, symbol_filter_t filter)
> {
> 	...
> 	if (dso->kernel == DSO_TYPE_KERNEL)
>                 return dso__load_kernel_sym(dso, map, filter);
> 	...
> }
> 
> Because dso->kernel of "[test_module]" is incorrectly set to DSO_TYPE_KERNEL, it goes to
> dso__load_kernel_sym. Where, since we use --kallsyms explicitly, dso__load_kallsyms() will
> be called.
> 
> Step 5: dso__load_kallsyms -> dso__load_kcore:
> 
> dso__load_kallsyms tries to call dso__load_kcore. In my case it should fail because I don't have
> /proc/kcore at all. However,
> 
> static int dso__load_kcore(struct dso *dso, struct map *map,
>                            const char *kallsyms_filename)
> {
>         struct map_groups *kmaps = map__kmap(map)->kmaps;
>         struct machine *machine = kmaps->machine;
>         ...

ok, here it is.. I've got 'lucky' and hit the '!kmap->kmaps'
check in the map__kmaps function.. so I've got pr_err
output instead which I succesfully ignored ;-)

I'll comment in the patch v4

nice explanation! thanks 


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