Prev: Removing dead ARCH_GUMSTIX_ORIG
Next: What's the relationship between Linux driver running priority and FIFO policy?
From: Srikar Dronamraju on 1 Jul 2010 01:10
Hi Ingo,

I have addressed all comments to the uprobes patchset. We have few
todos (most of them are features over the current code) which I plan
to work in the immediate future.

So would it be possible for this patchset to be picked into the tip
tree. Getting these patches merged into the tip tree would help in
getting more comments/feedback and testing.

--
Thanks and Regards
Srikar

> Uprobes Patches
>
> Changelog from V6:
> - Addressed comments from Masami on function names in common
> trace event code.
> - Addressed comments from Arnaldo on perf adjust symbol patch.
>
> Changelog from V5:
> - Merged user_bkpt and user_bkpt_xol into uprobes.
> - Addressed comments till now.
>
> Changelog from V4:
> - Rebased to tip tree. (2.6.35-rc3-tip)
>
> Changelog from v3:
> - Reverted to background page replacement as suggested by Peter Zijlstra.
> - Dso in 'perf probe' can be either be a short name or a absolute path.
> - Addressed comments from Masami, Frederic, Steven on traceevents and perf
>
> Changelog from v2:
> - Addressed comments from Oleg, including removal of interrupt context
> handlers, reverting background page replacement in favour of
> access_process_vm().
>
> - Provides perf interface for uprobes.
>
> Changelog from v1:
> - Added trace_event interface for uprobes.
> - Addressed comments from Andrew Morton and Randy Dunlap.
>
> For previous posting: please refer: http://lkml.org/lkml/2010/6/14/41
> http://lkml.org/lkml/2010/3/20/107 and http://lkml.org/lkml/2010/5/18/307
>
>

[ Snipped ... ]

> Here is the list of TODO Items.
>
> - Allowing probes across fork.
> - Allowing probes per-executable/per dso.
> - Allow multiple probes to share a probepoint.
> - Return probes.
> - Support for other architectures.
> - Uprobes booster.
> - Merge uprobes and kprobes trace_event.
> - replace macro W with bits in inat table.
>
> Please do provide your valuable comments.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 1 Jul 2010 04:30

* Srikar Dronamraju <srikar(a)linux.vnet.ibm.com> wrote:

> Hi Ingo,
>
> I have addressed all comments to the uprobes patchset. We have few todos
> (most of them are features over the current code) which I plan to work in
> the immediate future.
>
> So would it be possible for this patchset to be picked into the tip tree.
> Getting these patches merged into the tip tree would help in getting more
> comments/feedback and testing.

If Masami-san, PeterZ and Arnaldo is happy with it being tried in its current
form then we could try it.

Assuming everyone is reasonably happy about the code, here are some open areas
as i see them, before we can think about pushing things from -tip towards
upstream:

- One thing i havent seen is the ability to 'list' potential probe points:
i.e. function names. Often the user will not know precisely where to look
and what to type. This leaves our probe capability under-utilized in
practice.

- On a similar note, it might also make sense to extend the Newt interface to
perf report to integrate probes: if a function looks high-overhead, then a
probe point could be inserted and the app could be traced straight away. We
already allow per function actions in the Newt interface, such as assembly
annotation - the adding of a probe point would be quite useful.

- [ Optional: Another interesting area to look at would be the scripting
engine: allow trace scripts to insert probes if they are not present yet. ]

- Plus the security model is an open question as well. Right now it's
root-only, but it would make sense to allow users to insert probes into
their own apps. This brings up the next point:

- Proper syscall integration and more unification with kprobes and with the
TRACE_EVENT() universe. As far as API design goes,
/sys/kernel/debug/tracing/uprobe_events is quite sucky as a concept.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Masami Hiramatsu on 1 Jul 2010 05:20
Ingo Molnar wrote:
> * Srikar Dronamraju <srikar(a)linux.vnet.ibm.com> wrote:
>
>> Hi Ingo,
>>
>> I have addressed all comments to the uprobes patchset. We have few todos
>> (most of them are features over the current code) which I plan to work in
>> the immediate future.
>>
>> So would it be possible for this patchset to be picked into the tip tree.
>> Getting these patches merged into the tip tree would help in getting more
>> comments/feedback and testing.
>
> If Masami-san, PeterZ and Arnaldo is happy with it being tried in its current
> form then we could try it.

At least ftrace/perf side, it's almost good for me. (but I need time to test it)

> Assuming everyone is reasonably happy about the code, here are some open areas
> as i see them, before we can think about pushing things from -tip towards
> upstream:
>
> - One thing i havent seen is the ability to 'list' potential probe points:
> i.e. function names. Often the user will not know precisely where to look
> and what to type. This leaves our probe capability under-utilized in
> practice.

It will be the next step for perf-(u)probe, debuginfo support. Since
the perf-(k)probe already support in which function the probe is put,
I think if perf-(u)probe support debuginfo, it's easy to be implemented.

> - On a similar note, it might also make sense to extend the Newt interface to
> perf report to integrate probes: if a function looks high-overhead, then a
> probe point could be inserted and the app could be traced straight away. We
> already allow per function actions in the Newt interface, such as assembly
> annotation - the adding of a probe point would be quite useful.

Hmm, does that mean that user puts a new probe point from Newt interface?
That's a good idea:)

> - [ Optional: Another interesting area to look at would be the scripting
> engine: allow trace scripts to insert probes if they are not present yet. ]

Sure, that's what I hope. :)

> - Plus the security model is an open question as well. Right now it's
> root-only, but it would make sense to allow users to insert probes into
> their own apps. This brings up the next point:

Hmm, put a probe in user-space(by owner) may be good. But
inside the kernel, there are more sensitive informations...

> - Proper syscall integration and more unification with kprobes and with the
> TRACE_EVENT() universe. As far as API design goes,
> /sys/kernel/debug/tracing/uprobe_events is quite sucky as a concept.

Yeah, we can extend the interface and merge it. But removing all
debugfs interfaces should be discussed.

Thank you,

>
> Thanks,
>
> Ingo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Ingo Molnar on 1 Jul 2010 06:00

* Masami Hiramatsu <masami.hiramatsu.pt(a)hitachi.com> wrote:

> > - Plus the security model is an open question as well. Right now it's
> > root-only, but it would make sense to allow users to insert probes into
> > their own apps. This brings up the next point:
>
> Hmm, put a probe in user-space(by owner) may be good. But
> inside the kernel, there are more sensitive informations...

Yeah, clearly. Nevertheless this should not limit user-space probes.

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Christoph Hellwig on 8 Jul 2010 16:20
I can't actually get perf to build with these patches applied ontop
of the -tip tree master branch:

CC util/probe-finder.o
til/probe-finder.c: In function 'alloc_trace_arg_ref':
util/probe-finder.c:412: error: invalid application of 'sizeof' to incomplete type 'struct kprobe_trace_arg_ref'
util/probe-finder.c:414: error: dereferencing pointer to incomplete type
cc1: warnings being treated as errors
util/probe-finder.c: In function 'convert_variable_location':
util/probe-finder.c:428: error: initialization from incompatible pointertype
util/probe-finder.c:444: error: dereferencing pointer to incomplete type
util/probe-finder.c:445: error: dereferencing pointer to incomplete type
util/probe-finder.c:447: error: dereferencing pointer to incomplete type
util/probe-finder.c:448: error: dereferencing pointer to incomplete type
util/probe-finder.c:449: error: dereferencing pointer to incomplete type
util/probe-finder.c:489: error: dereferencing pointer to incomplete type
util/probe-finder.c:490: error: dereferencing pointer to incomplete type
util/probe-finder.c:494: error: dereferencing pointer to incomplete type
util/probe-finder.c:495: error: dereferencing pointer to incomplete type
util/probe-finder.c: At top level:
util/probe-finder.c:503: error: 'struct kprobe_trace_arg' declared inside parameter list
util/probe-finder.c:503: error: its scope is only this definition or declaration, which is probably not what you want
util/probe-finder.c: In function 'convert_variable_type':
util/probe-finder.c:505: error: dereferencing pointer to incomplete type
util/probe-finder.c:513: error: dereferencing pointer to incomplete type
util/probe-finder.c:514: error: dereferencing pointer to incomplete type
util/probe-finder.c:541: error: dereferencing pointer to incomplete type
util/probe-finder.c:543: error: invalid application of 'sizeof' to incomplete type 'struct kprobe_trace_arg_ref'
util/probe-finder.c:556: error: dereferencing pointer to incomplete type
util/probe-finder.c:557: error: dereferencing pointer to incomplete type
util/probe-finder.c:579: error: dereferencing pointer to incomplete type
util/probe-finder.c:580: error: dereferencing pointer to incomplete type
util/probe-finder.c: In function 'convert_variable_fields':
util/probe-finder.c:617: error: invalid application of 'sizeof' to incomplete type 'struct kprobe_trace_arg_ref'
util/probe-finder.c: In function 'convert_variable':
util/probe-finder.c:718: error: passing argument 2 of 'convert_variable_type' from incompatible pointer type
util/probe-finder.c:501: note: expected 'struct kprobe_trace_arg *' but
argument is of type 'struct probe_trace_arg *'
make: *** [util/probe-finder.o] Error 1
hch(a)brick:~/work/linux-2.6-tip/tools/perf$

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3 4
Prev: Removing dead ARCH_GUMSTIX_ORIG
Next: What's the relationship between Linux driver running priority and FIFO policy?