linux-kernel - Re: [PATCH] perf-probe: make "perf-probe -L <function>" display the absolute path and absolute line number

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, 14 Jan 2011 19:08:11 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Franck Bui-Huu <vagabon.xyz@...il.com>
Cc:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	lkml <linux-kernel@...r.kernel.org>,
	2nddept-manager@....hitachi.co.jp
Subject: Re: [PATCH] perf-probe: make "perf-probe -L <function>" display the
 absolute path and absolute line number

(2011/01/14 18:03), Franck Bui-Huu wrote:
> Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> writes:
> 
>> (2011/01/14 4:42), Franck Bui-Huu wrote:
> 
> [...]
> 
>>> Well, for consistency, I thought that the additional information
>>> (given inside angle brackets) should always be the same: a full path
>>> and an absolute line number which clearly identify which source file
>>> perf-probe is listing.
>>
>> No, that is NOT an additional information. That indicates from where
>> those lines are started
> 
> But this indication is currently not enough, it's too ambiguous to be
> usefull:
> 
>         <schedule:10>
> 
> there might be several 'schedule()' functions inside the kernel, also we
> don't know which kernel tree is used.

Right, so I didn't decline your idea itself.
I've just commented on the output format of the path information.


> BTW, if there're several 'do_something' functions defined inside the
> kernel, what is the behaviour of:
> 
>   $ perf probe do_something
> 
> Does it set a probe to all 'do_something' functions ? I don't think it's
> documented.

If do_something is an inline function, it tries to find all
functions. If it (the first one) is a normal function, it
just stopped after finding the first one.

If someone wants to put a probe on the specific function,
he can add some additional path information, like

 $ perf probe do_something@...h/to/source.c


>> , and also gives you a hint how you can specify the actual probe
>> point. For example,
>>
>> $ perf probe -L schedule:10
>> <schedule:10>
>>      10         rq = cpu_rq(cpu);
>>      11         rcu_note_context_switch(cpu);
>>      12         prev = rq->curr;
>>
>> this indicates the lines started from 10th line of schedule(), and
> 
> but I'm not sure it's really usefull since you've asked for it when
> invoking perf-probe so it seems to be redundant.

If you list the lines of enough long function, the output will be
passed to pager and it flushes out the command line.

In that case, user will see only below output.

   </usr/src/debug/kernel-2.6.35.fc14/linux-2.6.35.x86_64/kernel/sched.c:3823>
        10         rq = cpu_rq(cpu);
        11         rcu_note_context_switch(cpu);
        12         prev = rq->curr;
        13         switch_count = &prev->nivcsw;

        15         release_kernel_lock(prev);

Hmm, how can he find the probe point from this? :)
Yeah, I know user must know what he has given. However, I'd like to
show users what actually he has given.

Thanks,

-- 
Masami HIRAMATSU
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: masami.hiramatsu.pt@...achi.com
--
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/